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, [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.
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. _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
