Dear Kenneth, So here's the output of "tcpdump -nni lo0 port 22" for "telnet localhost 22", per the previously attached screenshot, with newlines doubled for clarity:
20:01:00.682177 127.0.0.1.46329 > 127.0.0.1.22: S 801468238(0) win 16384 <mss 33112,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2349583298 0> (DF) [tos 0x10] 20:01:00.682194 127.0.0.1.22 > 127.0.0.1.46329: S 479550093:479550093(0) ack 801468239 win 16384 <mss 33112,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 949228642 2349583298> (DF) 20:01:00.682204 127.0.0.1.46329 > 127.0.0.1.22: . ack 1 win 2048 <nop,nop,timestamp 2349583298 949228642> (DF) [tos 0x10] tcpdump: WARNING: compensating for unaligned libpcap packets 20:01:00.682209 127.0.0.1.22 > 127.0.0.1.46329: R 47955094:479550094(0) win 0(DF) tcpdump: WARNING: compensating for unaligned libpcap packets 20:01:00.682417 ::1.17180 > ::1.22: S 509945791:509945791(0) win 16384 <mss 33092,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 3188291996 0> flowlabel 0x8123e] 20:01:00.682417 ::1.22 > ::1.1780: S 2378631609:2378631609(0) ack 509945792 win 16384 <mss 33092,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 910240013 3188291996> 20:01:00.682423 ::1.17180 > ::1.22: . ack 1 win 2048 <nop,nop,timestamp 3188291996 910240013> [flowlabel 0x8123e] 20:01:00.682427 ::1.22 > ::1.17180: R 2378631610:2378631610(0) win 0 This looks like a quite traditional 'connection refused by peer', does it not - initiator sends SYN, gets SYN, responds with ACK, and gets RST? Did I miss anything? If I remember right, Frostypants saw something erratic here. 2013/7/7 Kenneth R Westerback <[email protected]> > > > The PNG file is uploaded here: > > > http://s000.tinyupload.com/download.php?file_id=28266514139859296465&t=2826651413985929646525648 > > , > > please have a look! > > Please transcribe the text and include in the email. Following links to > download files to somehow display to read some text is a waste of time. Or > capture the output in a useful format. i.e. text. > (above) > > Thank you for the reference to http://openbsd.org/report.html - read > > through it again once more now. > > And yet you don't actually provide any of the information requested on > the page. > Please let me know what specific information or line of thought you're having on your mind, for me to express this particular case as it is until now here more completely. > > What I have encountered is measurably a bug since what's happening is not > > OBSD's intended behavior, so addressing it here makes sense. > > Not knowing what causes the behaviour I would not be so quick to decide > what OBSD's intended behaviour in that circumstance is. I can imagine > circumstances where your described behaviour would be a good thing. > Yeah, to stretch it a bit - or not - , it could be anything really. > No such tools as you describe exist as far as I know. Nor, unless > you write them, are they likely to exist. > I suspected they don't. Kind of interesting perhaps, if so, that such a huge piece of complex code was written without anyone implementing a state inrospection facility for it. > Reproducing the problem, preferably with an absolute minimum of > irrelevant activity, would be best. Then providing the captured information > requested in report.html, plus any captured text output you think > relevant could start a useful diagnostic process. > Yeah I know. In this moment I see it happen once every 2 months, so at the current pace it would take maybe 10 years to figure out how to reproduce it - am trying to figure out some way to make this process Much faster, max another 2 months. > .... Ken Thanks, Mikael
