Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3256] New dissector: gadu-gadu protocol

Date: Sun, 1 Mar 2009 20:42:18 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3256





--- Comment #8 from Stephen Fisher <steve@xxxxxxxxxxxxxxxxxx>  2009-03-01 20:42:16 PDT ---
(In reply to comment #7)

> About gadu-gadu traffic on port 443, it's not gg-over-ssl, it's still
> unencrypted. It's just hack to make Gadu-Gadu connection more firewall-friendly
> (some admins block connection on high-ports, 443 is low, and used by https, so
> they won't close it)
>
> Anyway it's hard to determinate if it's gadu-gadu port or not. 

It may be best then to just let the Wireshark user select such a packet and
choose Decode As -> Gadu-Gadu.

> By the way about len of packet and fragmentation (get_gg_pdu_len())
> Known clients ignores packet with len (in header) above 65KB, (orginal
> Gadu-Gadu client AFAIK ignores packet with len above ~3KB)
> 
> What should we do with such packet in wireshark? I'd like to ignore it like
> normals client do. Any ideas how?

Check the len to see if it is more than 65535 and if so, "return" from the
function you're in to pass control back to Wireshark so it can move on to the
next packet.  Since that's a function called from the main dissection function,
have it return something that can indicate to the caller to skip the packet.

> And second question (if I leave code as it is) if some evil person send packet
> with some weird len (like 0xffffff) it's safe for wireshark?

It's safe for Wireshark as long as your code doesn't do something like a buffer
overrun when it receives such a packet :).


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.