http://web.archive.org/web/20080308233204/http://dev.aol.com/aim/oscar/#SNAC
"In general strings are not NULL terminated and are encoded using UTF8."
It also says
Authentication
Over the years, the AIM backend has supported several different
methods for authentication. ...
When a client collects the loginId and password for the user it
should not normalize them in any manner. It also should not
prevent the user from entering certain characters as the AIM
name space is constantly changing. For example, currently the
AIM name space is ASCII based, but in the future that may
change. In general, the client should not perform input
checking and instead allow the backend to reject bad values.
which also suggests not assuming ASCII.
So use ENC_UTF_8 in most cases.
For actual messages, it says:
An IM can be encoded in the following different forms:
Name Value Notes
ASCII 0 ANSI ASCII -- ISO 646
UNICODE 2 ISO 10646.USC-2 Unicode
LATIN_1 3 ISO 8859-1
so, if that's the case, the dissector should choose beween
ENC_ASCII|ENC_NA, ENC_UCS_2|ENC_appropriate_ENDIAN, and
ENC_ISO_8859_1|ENC_NA.
Use tvb_get_string_enc() with an encoding rather than tvb_get_string().
svn path=/trunk/; revision=54908
favor of the AIM dissector having its own private way of handing off to
subdissectors. Get rid of the subdissector table.
svn path=/trunk/; revision=53989
Now that "bytes consumed" can be determined, should tcp_dissect_pdus() take advantage of that?
Should tcp_dissect_pdus return length (bytes consumed)? There are many dissectors that just call tcp_dissect_pdus() then return tvb_length(tvb). Seems like that could all be rolled into one.
svn path=/trunk/; revision=53198
2) Use proto_item_append_text instead of proto_item_set_text, since this is
called within a loop.
3) Increment the offset correctly using blocklen-4 instead of
tvb_length_remaining, which makes no sense.
svn path=/trunk/; revision=45657
1. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
2. For all but FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN).
svn path=/trunk/; revision=39426
In the AgentX dissector, make the "flags" arguments guint8, to match
what's passed in.
In the AIM dissector, use val_to_str() in col_add_str() calls - it gives
the same result if there's a match, and puts a note in the Info column
if there isn't, and is less complicated.
In the AJP13 dissector:
update the URL for the protocol documentation;
add #defines for message types, and use them;
for "enumerated data type" fields, make the fields numerical
rather than strings and give them the value_string tables;
get rid of col_check() calls;
make a Boolean item an FT_BOOLEAN.
svn path=/trunk/; revision=39085
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
Expose the FNAC family and subtype via a hf_ value so you can filter for
specific messages.
From me:
Re-arrange the code a bit: put dissect_aim() at the bottom near the
registration functions. Remove unnecessary forward declarations.
Reindent a bunch.
Remove a couple check_col() calls; leave one in since it protects several
other calls.
svn path=/trunk/; revision=30243
(1) Trailing/leading spaces are removed from 'name's/'blurb's
(2) Duplicate 'blurb's are replaced with NULL
(3) Empty ("") 'blurb's are replaced with NULL
(4) BASE_NONE, NULL, 0x0 are used for 'display', 'strings' and 'bitmask' fields
for FT_NONE, FT_BYTES, FT_IPv4, FT_IPv6, FT_ABSOLUTE_TIME, FT_RELATIVE_TIME,
FT_PROTOCOL, FT_STRING and FT_STRINGZ field types
(5) Only allow non-zero value for 'display' if 'bitmask' is non-zero
svn path=/trunk/; revision=28770
I've extended the AIM dissector with the information available from http://dev.aol.com/aim/oscar .
I've verified most of the additions by sniffing my iChat (OSX 10.4) data traffic.
svn path=/trunk/; revision=26813
there are many reasons why some protocols actually need to be able to access the pinfo structure while determining the pdu size
svn path=/trunk/; revision=19751
while this should improve performance by unmeasurably little it does have the sideeffect that once we finish the rewrite tcp analysis might actually work and work well even for tcp over tcp tunnelling.
this also means that if you include packet-tcp.h you also need to include emem.h .
svn path=/trunk/; revision=17681