On Wed, 2008-06-18 at 17:42 +0200, Johannes Berg wrote: > On Wed, 2008-06-18 at 15:55 +0100, Andrew Price wrote: > > On 18/06/08 08:22, Johannes Berg wrote: > > >> This also affects some http requests such as loading slashdot but not > > >> others (perhaps small ones?) such as twitter API http requests. It does > > >> not seem to affect connections to other machines on my LAN, only ones > > >> over the internet. > > >> > > >> I've tried tcpdumping to get more info but when I run tcpdump the > > >> connections work again (if a tiny bit slower). > > > > > > Can you try tcpdump with the -p flag? promisc mode might affect things. > > > > I tried using -p and it made the bug go away again. However, I have some > > packet captures from running tcpdump on the router while the bug was > > occuring and from loading them into wireshark it seems there are some > > (suspected) retransmissions with bad checksums. I've posted my packet > > captures here: > > > > http://sucs.org/~welshbyte/lw/tcpdump_bad0.pcap > > http://sucs.org/~welshbyte/lw/tcpdump_bad1.pcap > > http://sucs.org/~welshbyte/lw/tcpdump_good0.pcap > > > > The two 'bad' ones were captured on the router while the bug was > > occuring. The 'good' one is for comparison and was captured on the > > router like the others but while running tcpdump on my laptop made the > > bug go away (I hope that makes sense). > > > > In all cases, the test was to ssh to a remote server. The two bad cases > > were closed before the password prompt was reached and the good case was > > ^C'd at the password prompt. > > > > I hope this helps, > > Thanks. Unfortunately, it's very hard to tell what is causing the bug, No, that was worded wrong, I mean, we know what is causing the bug and we know what the bug is, but due to encryption being used it's hard to confirm from the tcpdump you posted. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
