Bugzilla – Bug 11150
Wireless Bridging
Last modified: 2011-01-14 00:24:45 UTC
Implement bridging between ethernet and wireless.
Added simple setup applet allowing enabling/disabling of Wireless Bridging. r6013
Felix, is this done?
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code. Feel free to move it back if it's specific to the original product.
Short answer: no Long answer: Bridging between a _wireless_ and _wired_ interface is not trivial and cannot be done with the standard bridging capabilities already included in the kernel, i.e. brctrl. Kernel bridging requires an interface to be capable (or to allow) packets being sent with source mac address that are not its own, but the one from the client behind the bridge. This allows to route the answer back to the real client rather than the bridge interface. (BTW: The bridge interface is in promiscuous mode to be able to 'see' these packets.) Unfortunately _wireless_ interfaces (drivers) do not allow packets being sent containing not its own mac address. The driver silently drops packets with a manipulated mac address. Apart from that it seems that wpa_supplicant is confused about the situation and I've seen the wireless connection going up and down. Possible solution: A solution - which is what is currently implemented - is the use of proxy arp together with a DHCP forwarding daemon. Proxy arp adds a route for the client behind the bridge which singles out that one IP address to the other side of the bridge. The bridge then answers to arp requests regarding the client so packets gets sent to the bridge and are then forwarded to the client. To allow a client to get an IP address via DHCP an additional daemon is needed which listens for DHCP requests and relays them. This daemon currently is also responsible to add the proper route depending on what IP address the client gets. Know issues: a) Dynamically added routes for clients are lost when Fab4 is power-cycled b) If a client is removed, the route isn't removed automatically c) A client cannot use a static IP address as the route is then missing d) Network setup changes, i.e. using wired instead of wireless does not disable bridging Possible solutions: a) Save routes and re-establish them after reboot b) Monitor arp cache and if client isn't in there anymore, remove route c) UI which allows to enter IP address of client which then adds the route d) Hook into the network setup process and disable bridging if wired is used Or, find another solution altogether which does a better job than arp proxying and works with wireless interfaces.
moving current p2 bugs to p3 to make room for moving p1.5 bugs to p2
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Additional known issue of the current implementation: e) UDP packets are not bridged / forwarded Possible solution: e) Add yet another daemon taking care of UDP packets
Do you have a good idea what customers use bridging for, and what % of use cases would be satisfied with simple iptables NAT "IP masquerading"? While some things like bidirectional BitTorrent traffic don't work with NAT, could you satisfy 80-90% of the users with simple IP masquerading that would be easy to implement?
A new forum thread illustrates another use case for simple NAT/IP Masquerading: Squeezebox Radio In Hotel? http://forums.slimdevices.com/showthread.php?t=73156 "As long as the hotel room has free wi-fi I should be able to use the radio there no problem right?" If the customer used Radio to access the WLAN and SNATed a laptop/netbook through Radio's ethernet port, the WLAN portal would see both as having Radio's MAC, and the customer could use Radio in the hotel (assuming the hotel infrastructure allowed this, etc.)
Moving lower-priority bugs to next target
Unfortunately there is no simple solution (i.e. using kernel bridging capabilities) if the wireless interface doesn't allow for packets being sent that do not use its own MAC address which is the case with Marvells wireless chipset used in Fab4. The proxy-arp way I looked at in the past is not user very friendly (see known issues in comment #4) and far from being done. Removing the target since it will not be fixed in the next release.