Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 23471:/trunk/epan/dissectors/ /trunk
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Mon, 19 Nov 2007 17:16:09 -0500


Michael Tuexen wrote:

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

Michael Tuexen wrote:

On Nov 16, 2007, at 11:04 PM, morriss@xxxxxxxxxxxxx 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.
Ah, OK, that makes some sense. (In my world both paths always have the same MTU.) 


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.
I would read that as "over bundling" past the MTU (to the point where it forces fragmentation) but I guess that it's true that it's not really illegal. Hmmm... 


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.
The change that started this thread puts [Unreassembled packet] in the info column (in between chunks). Other exceptions would presumably also put something there.
I usually just ignore the upper layer stuff instead of turning it off--but I discovered the hard way that doing so can trick you.