On Mon, Jul 08, 2013 at 04:18:10AM +0300, Mikael wrote: > Kenneth, can you please be more clear about what info you mean? > > ( > Looking at http://openbsd.org/report.html , > > Released versions problem reports - I don't see any patches listed for 5.3 > or current that would change this > Current version problem reports - it's not about current so does not apply > How to create a problem report - tell the sequence up to when the error > occurred, the output and kernel output, and list any thirdparty software in > use - check, as far as it appeared relevant.
Please let us determine what is relevant. If you already know what is relevant you need no help from us. e.g. no dmesg that I ever saw. > Sending in bug reports - I should not use the 'sendbug' tool as the error > is too diffuse. This error currently categorizes as an 'Non-repeatable > problems -- or problems you do not wish to repeat.' error. So it's at the bottom of the list. Does it say don't use sendbug if the problem is of type N or higher? Either it's a bug you want to report or it's a story you want to discuss on icb somewhere. In the meantime you might want to explore ddb.console=1, and ddb(4). .... Ken > > So I've reported in line with http://openbsd.org/report.html as far as I > can see. > ) > > Thanks, > Mikael > > 2013/7/8 Kenneth R Westerback <[email protected]> > > > On Mon, Jul 08, 2013 at 03:10:31AM +0300, Mikael wrote: > > > 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. > > > > OK, I asked twice and you seem unwilling to provide the info. So I look > > forward to your next report sometime in September. Good luck. > > > > .... Ken
