it aborts - even if we don't make it abort, we should make it throw an
assertion, so we abort the dissection of the packet and let the user
know that we ran out of memory).
svn path=/trunk/; revision=25069
*reported* length, so that if the packet was cut short by a snapshot
length, we get an exception because we run past the end, and the packet
is marked as having been cut short.
Do not use DISSECTOR_ASSERT() to check for the validity of packet data;
dissectors should try to handle even malformed packets, they shouldn't
report malformed packets as dissector bugs (if DISSECTOR_ASSERT(), that
is *ipso facto* evidence of a dissector bug, *even if the packet is
malformed*).
Update the offset when scanning the packet even if we *aren't* building
the protocol tree.
svn path=/trunk/; revision=25068
can see which fields belong to which bit.
Also make sure that we can filter on the fields in the rfc2190 dissector
by actually parsing them even when tree=NULL.
svn path=/trunk/; revision=25046
Added support for RFC4207 (SONET/SDH encoding for LMP test messages);
added support for (provisional) oif-p0040.010.006 (OIF interoperability demo
during ECOC2007).
svn path=/trunk/; revision=25038
Added support for Ethernet SENDER_TSPEC and FLOWSPEC objects according to
draft-ietf-ccamp-ethernet-traffic-parameters-02.
Added support for enhancements in the LSP_TUNNEL_INTERFACE_ID object according
to draft-ietf-ccamp-lsp-hierarchy-bis-02.
Added support for NOTIFY_REQUEST and RECOVERY_LABEL objects.
Added display filters for some fields of the GENERALIZED_UNI and CALL_ID
objects.
svn path=/trunk/; revision=25023
Within the packet-diameter_3gpp.c module, the call to proto_register_protocol()
comes AFTER the proto_register_field_array() call.
While the delayed call to proto_register_protocol() does not appear to impair the use
of the display filters, it DOES effect the generation of the wireshark-filter man page.
svn path=/trunk/; revision=25014
and a new data source for displaying unaligned octet strings, because the
user cannot easily see where in the data package the values are from.
Maybe we should implement a "Packet Bits" pane for bit protocols?
Or just an option to turn the Bytes pane to a Bits pane?
Another problem is that the generated pdml (from the bug report) does not
generate correct data for these fields, as the "pos" value is always zero
(because we use a new tvb with offset 0). But I suppose it's difficult to
fix this with byte values...
svn path=/trunk/; revision=24992
The client can send multiple requests before waiting for responses.
Multiple requests/responses are delimited in the info column using " | ".
Also changed to using "C:" (client) and "S:" (server) to save space in the info column and align with examples in RFC 2821.
Lack of support for PIPELINING was shown up during Sake's session at SharkFest08!
svn path=/trunk/; revision=24989
