On 1/13/2016 1:31 PM, Olivier Cochard-Labbé wrote:
On Wed, Jan 13, 2016 at 9:45 AM, Alexander V. Chernikov <melif...@ipfw.ru>
wrote:
I suspect the reason here is link state bridge handling.
ix0 does not seem to have IFCAP_LINKSTATE option but re(4) does. Probably
wlan0 doesn't have LINKSTATE option.
Code in bridge_linkcheck() doesn't handle the case with both "has link
state" and "no link state" interfaces well:
if reX is the only interface w/ IFCAP_LINKSTATE and it goes down, bridge
will also change its link state to down.
(However, bridge does not seem to have link state option itself, so
RT_LINK_IS_UP() macro should return true...)
For validating your "IFCAP_LINKSTATE" hypothesis, I've plug an USB
ethernet adapter ue(4) that didn't support IFCAP_LINKSTATE.
And I've setup the bridge0 with wlan0 and ue0 (in place of re1): same bug
triggered. I need to plug a cable for correct routing.
root@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 0xff00 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: ue0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 7 priority 128 path cost 55
member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 5 priority 128 path cost 3
root@fbsd-router:~ # ifconfig ue0
ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
mtu 1500
options=80008<VLAN_MTU,LINKSTATE>
ether 00:19:fd:4e:77:4d
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (none)
status: no carrier
Regards,
___
freebsd-wirel...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
IMHO, this situation happens because if_bridge applies link state logic
with the (wrong) assumption that it is _only_ responsible to forward
packets between member interfaces. In this special setup, the packet
comes from IP layer (not from another member interface) and should be
forwarded on an up and active member interface w/o problem.
It seems to me that the correct behavior for if_bridge it to check
link state after it has determined outgoing interface and is
about to forward the packet on that interface (however, I am not sure if
returning unreachables, which is a good troubleshooting signal, is then
possible or not).
--
Best regards
Hooman Fazaeli
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
