Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 23471:/trunk/epan/dissectors/ /trunk
From: Michael Tuexen <[email protected]>
Date: Mon, 19 Nov 2007 22:28:56 +0100
Hi Jeff,

see my comments in-line.

Best regards
Michael

On Nov 19, 2007, at 4:50 PM, Jeff Morriss wrote:


Michael Tuexen wrote:
On Nov 16, 2007, at 11:04 PM, [email protected] wrote:
(One could rightfully argue that you should only see a fragmented
chunk
bundled with another chunk when retransmitting but, well, I'm
staring at
traces of an implementation--to remain nameless to protect the
guilty--which
is sometimes fragmenting and then bundling the fragments into one
packet.)
That is completely valid... Implementations are free to fragment user
data and bundle the fragments in one packet. There are even conditions
where
this is required behaviour.
Hmmm, like when (besides retransmission)?  It certainly is ugly to  
look at.
If you have for example one path with an MTU of 1500 bytes and another
path of an MTU of 9000 byte. If you now send a message of 200 bytes,
you have to fragment it such that it can be sent over the 1500 byte path,
even you you send it on the other.
Also if you have a path of 1500 bytes MTU and you are sending packets
of size 800 bytes, only one user message fits into one packet.
Some implementations optimize this (Solaris comes into my mind),
by splitting the messages such that the packets are almost full.
There is nothing wrong with this.

When dissecting you might want to enable reassembly.

BTW, I also mean to check if the SCTP dissector should be catching
exceptions whenever calling a subdissector.  What I fixed above was
causing me massive confusion because the peer was SACKing TSNs I
couldn't see in the trace (because M3UA exception'd out).  Of course
exceptions may occur for other reasons and we should never forgot to
display all the DATA chunks.
But we should also see the exceptions in the upper layer if there
are problems... If I'm looking at the SCTP layer, I normally disable
the upper layer dissection.

_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev