On Tue, Oct 29, 2019 at 08:12:04PM +0100, Otto Moerbeek wrote: > On Tue, Oct 29, 2019 at 08:09:59PM +0100, Otto Moerbeek wrote: > > > On Tue, Oct 29, 2019 at 09:58:08AM -0600, Theo de Raadt wrote: > > > > > I've been reporting this since the dawn of the architecture. I > > > saw it as a network hickup. I didn't notice an earlier copy > > > of the packet that was corrupted. > > > > > > > So it *is* size related and can be reproduced with ping: > > > > [otto@wand:61]$ ping -c 1 -s 31 10.1.1.3 > > PING 10.1.1.3 (10.1.1.3): 31 data bytes > > > > Outgoing: > > # tcpdump -Xn -i fec0 -s 1500 -vvv icmp > > tcpdump: listening on fec0, link-type EN10MB > > 20:07:09.231929 10.1.1.9 > 10.1.1.3: icmp: echo request (id:9678 > > seq:0) [icmp cksum ok] (ttl 255, id 27755, len 59) > > 0000: 4500 003b 6c6b 0000 ff01 3949 0a01 0109 E..;lk....9I.... > > 0010: 0a01 0103 0800 eb11 9678 0000 aabf 55f1 .........x....U. > > 0020: 3356 ef18 87a0 ca13 74a6 c8ea 995c 4475 3V......t....\Du > > 0030: 90dc e90f 1819 1a1b 1c1d 1e ........... > > > > Incoming: > > # tcpdump -Xn -i em1 -s 1500 -vvv icmp > > tcpdump: listening on em1, link-type EN10MB > > 20:07:09.231896 10.1.1.9 > 10.1.1.3: icmp: echo request (id:9678 > > seq:0) [bad icmp cksum eb11! -> b11] (ttl 255, id 27755, len 59) > > 0000: 4500 003b 6c6b 0000 ff01 3949 0a01 0109 E..;lk....9I.... > > 0010: 0a01 0103 0800 eb11 9678 0000 aabf 55f1 .........x....U. > > 0020: 3356 ef18 87a0 ca13 74a6 c8ea 995c 4475 3V......t....\Du > > 0030: 90dc e90f 1819 1a1b 1c1d fe ........... > > > > I did not mention that any other size I tried works ok. > > -Otto >
This is not true; a little script their are more sizes failing. With -p 00: 31 nok 95 nok 151 nok 247 nok 311 nok 375 nok 407 nok 471 nok 503 nok 759 nok 791 nok 823 nok 855 nok 983 nok 1015 nok With other -p arguments this varies a bit, but only odd packet lengths are reported. This is the script: #!/bin/ksh for i in $(jot 1025); do if ! ping -w 1 -c 1 -s $i -p00 10.1.1.3 > /dev/null; then echo $i nok fi done
