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