Jeff Morriss
changed
bug 12597
| What |
Removed |
Added |
| Summary |
Export filtered displayed packets not saving SCTP fragmented packets
|
Export filtered displayed packets won't save IP fragments of SCTP fragments needed to reassemble a displayed frame
|
Comment # 6
on bug 12597
from Jeff Morriss
(In reply to sshark from comment #5)
> (In reply to Jeff Morriss from comment #4)
> > Just as a side note: this trace also indicates that there's something weird
> > going on with the source of the frames I listed: it's not setting the IP DF
> > (Don't Fragment) bit on any of its packets--even the small ones like
> > HB_ACK's.
> >
> > It would seem that the implementation is not trying to do path MTU
> > discovery. IIRC there was an ETSI specification that required turning off
> > path MTU discovery but of course doing so requires setting the path MTU
> > appropriately--IP fragmentation really shouldn't be used.
> >
> > All that to say you might want to investigate that host. It's not behaving
> > well.
>
> IP DF bit has anything to do with what we are seeing in wireshark ?
Only in the sense that if the host were well-behaved (if it was setting the IP
DF bit) then it would have learned the path MTU and as a result it would not be
using both IP *and* SCTP fragmentation. It's that combination of using both IP
and SCTP fragmentation that's breaking Wireshark's ability to save all the
required packets.
That host isn't breaking anything in the network but it's behaving
sub-optimally and is opening itself up to, among other problems, IP
fragmentation attacks (there are reasons the IETF recommends not using IP
fragmentation).
> What I get from you earlier comment, is that recursively wireshark cannot
> find out if any "depend upon" packet is there ?
Correct. There are ways to make Wireshark do it but at least the ones I've
thought of so far would use way too much memory.
You are receiving this mail because:
- You are watching all bug changes.