Daniel Eischen wrote: >> >>Could you post a tcpdump for each case? I wonder if this is related to a >>fragmentation issue I've seen in the past. > > 22:46:43.513038 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52198:1480_at_0+) > 22:46:48.522475 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52199:1480_at_0+) > 22:46:53.532018 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52200:1480_at_0+) > 22:46:58.541178 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52201:1480_at_0+) > 22:47:03.553048 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52202:1480_at_0+) > 22:47:08.568862 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52203:1480_at_0+) > 22:47:13.583328 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52204:1480_at_0+) > 22:47:18.578512 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52205:1480_at_0+) > 22:47:23.609098 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52206:1480_at_0+) > 22:47:28.597680 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52207:1480_at_0+) > 22:47:33.607059 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52208:1480_at_0+) It's not what I've seen in the past - but also pretty strange! Only the first fragment seems to be received. Wonder what happened to the other fragments... If you tcpdump on gpz, does the output look the same? Also, you may want to run the tcpdump without a filter (if you don't do this already) to see if the other fragments show up as corrputed frames or something. (As an aside, fragmentation on a lossy link compounds throughput issues, but of course you know that already.) Lars -- Lars Eggert <larse_at_isi.edu> USC Information Sciences Institute
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:27 UTC