After weeks of troubleshooting, at last I found how to reproduce this problem ;-) Here is the setup: LAN0 <--> [(re0) fbsd router (bridge0 addm re1 addm wlan0)] <--> Wireless LAN If interface re1 (bridge0 member with wlan0) is in "active" status (=ethernet cable plugged to something): I don't have any problem, all is working great for my wireless clients connected to wlan0: They can ping devices in LAN0. But once I've unplug the ethernet cable connected to re1 (bridge member with wlan0) and re1 state switch to "no carrier", Wireless LAN clients are not able to reach LAN0. Here is my rc.conf with simple subnetting for Adrian ;-) wlans_ath0="wlan0" ifconfig_wlan0="hostap channel 6" create_args_wlan0="wlanmode hostap" cloned_interfaces="bridge0" ifconfig_re0="inet 1.0.0.1/24" ifconfig_re1="up" ifconfig_bridge0="inet 1.1.1.1/24 addm re1 addm wlan0 up" gateway_enable="YES" And an example with re1 in "no carrier" status: root_at_fbsd-router:~ # ifconfig bridge0 bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 02:6b:c0:de:b8:00 inet 1.1.1.1 netmask 0xffffff00 broadcast 1.1.1.255 nd6 options=9<PERFORMNUD,IFDISABLED> groups: bridge id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 5 priority 128 path cost 33333 member: re1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 2 priority 128 path cost 55 root_at_fbsd-router:~ # ifconfig re1 re1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=82099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether 00:0d:b9:3c:ae:25 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (none) status: no carrier => from a wireless LAN client (1.1.1.2) I'm trying to ping a host on LAN0 (1.0.0.2): root_at_fbsd-router:~ # tcpdump -pni re0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes 23:38:04.466866 ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 28 23:38:04.467052 ARP, Reply 1.0.0.2 is-at 00:08:a2:09:c4:a2, length 46 23:38:04.467090 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 1, length 64 23:38:04.467226 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 1, length 64 23:38:04.467300 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length 36 23:38:05.483053 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 2, length 64 23:38:05.483259 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 2, length 64 23:38:05.483318 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length 36 23:38:06.387304 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 3, length 64 23:38:06.387466 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 3, length 64 23:38:06.387514 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length 36 ^C 11 packets captured 11 packets received by filter 0 packets dropped by kernel root_at_fbsd-router:~ # arp -na ? (1.1.1.1) at 02:6b:c0:de:b8:00 on bridge0 permanent [bridge] ? (1.1.1.2) at fc:64:ba:97:c0:ff on bridge0 expires in 1168 seconds [bridge] ? (1.0.0.1) at 00:0d:b9:3c:ae:24 on re0 permanent [ethernet] => The FreeBSD router answers "unreacheable" to the host: My wireless LAN client never get the ICMP reply. => Now I plug eth1 to a dummy machine (just for changing its status): root_at_fbsd-router:~ # ifconfig re1 re1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=82099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether 00:0d:b9:3c:ae:25 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active => and I restart the same ping from the wireless LAN client: root_at_fbsd-router:~ # tcpdump -pni re0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes 23:44:08.597429 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 1, length 64 23:44:08.597660 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 1, length 64 23:44:09.604447 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 2, length 64 23:44:09.604683 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 2, length 64 23:44:10.609711 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 3, length 64 23:44:10.609874 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 3, length 64 => It's works :-) How the status of a member of the bridge can impact the routing behavior of other interfaces ? How to fix this problem ? ThanksReceived on Mon Jan 11 2016 - 21:53:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC