When I try to do ordinary ping for local address in interface em0, ping shows 100% lost master:[root] 102>ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss When I do the same, but with hardly specified IP address, all OK: master:[root] 109>ping -S 192.168.1.1 192.168.1.1 PING 192.168.1.1 (192.168.1.1) from 192.168.1.1: 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.019 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.030 ms ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.019/0.025/0.030/0.005 ms When I try to looking, what's wrong, I see, that first time source address is 0.0.0.0! master:[root] 113>tcpdump -i lo0 -n icmp and host 192.168.1.1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes 15:08:37.278462 IP 0.0.0.0 > 192.168.1.1: ICMP echo request, id 29301, seq 3, length 64 15:08:38.277404 IP 0.0.0.0 > 192.168.1.1: ICMP echo request, id 29301, seq 4, length 64 15:08:43.163123 IP 0.0.0.0 > 192.168.1.1: ICMP echo request, id 41845, seq 0, length 64 ^C 3 packets captured 109 packets received by filter 0 packets dropped by kernel Same way at FreeBSD 7.3-RELEASE all OK: (192.168.1.94 is their address) to-594:[root] 139>ping 192.168.1.94 PING 192.168.1.94 (192.168.1.94): 56 data bytes 64 bytes from 192.168.1.94: icmp_seq=0 ttl=64 time=0.031 ms 64 bytes from 192.168.1.94: icmp_seq=1 ttl=64 time=0.041 ms ^C --- 192.168.1.94 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.031/0.036/0.041/0.005 ms Fix: None How-To-Repeat: Install FreeBSD 8.x. Configure any local interface. Try to ping it. You failed.
There are some revisions for this bug First. Tio obtain bug you should place "lo0" as latest member of network interfaces set, i.e: network_interfaces="xl0 lo0" - bug will occured network_interfaces="lo0 xl0" - bug will not occured network_interfaces="xl0" - bug also will not occured Second. To eliminate bug you must down interface and configure it manually again So, I'd like to ask - WHY? Why an initialisation order takes so great and wild importance? (I had have tried boot with rc_debug="YES" and had have seed, that ANY difference between "worked" and "non-worked" boot is network inrterfaces initialization order - in "worked" lo0, next xl0, in "non-worked" - xl0, next lo0! -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), JID: citycat4@jabber.infos.ru OOO "ACK" telecommunications administrator, e-mail: achilov-rn [at] askd.ru PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A
I've got the same problem on 8.2 and 9.0. I thank that's serious problem and must be fixed before 9.0 release. -- Andrey Zonov
Running into this bug on 9.0 diskless boot clients. Cannot ping primary = IP address of the NIC the server boots from, source address observed via = TCP dump is 0.0.0.0, same as initial PR report. Any status on a fix/update for this? --=20 Robert Blayzor INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/
On Saturday 28 July 2012, Robert Blayzor wrote: > Running into this bug on 9.0 diskless boot clients. Cannot ping primary IP address of the NIC the server boots from, source address observed via TCP dump is 0.0.0.0, same as initial PR report. > > Any status on a fix/update for this? I do not know nothing about updates. I had have detected a *workaround* - when lo0 is FIRST interface name in network_interfaces or missed in it (this way it will init by default) - bug does not occured. When it is non-first in network_interfaces - bug occured. But this is only *workaround*, this bug need real fix. -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), JID: citycat4@jabber.infos.ru OOO "ACK" telecommunications administrator, e-mail: achilov-rn [at] askd.ru PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A
On Jul 29, 2012, at 10:51 PM, "Rashid N. Achilov" <achilov-rn@askd.ru> = wrote: > I do not know nothing about updates. I had have detected a = *workaround* - when=20 > lo0 is FIRST interface name in network_interfaces or missed in it = (this way=20 > it will init by default) - bug does not occured. When it is non-first = in=20 > network_interfaces - bug occured. But this is only *workaround*, this = bug=20 > need real fix. Unfortunately this workaround does not work for a diskless client since = the first interface initialized is the NIC the kernel has booted from. = I tried your workaround in the diskless boot, and the result is the = same. This bug occurs. --=20 Robert Blayzor INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/
Is this still valid/reproducible?
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.