Modify

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#1080 closed bug (wontfix)

F2.0g Wifi-Bridge Mode .Absolutely no response

Reported by: decodecoding@… Owned by:
Priority: normal Milestone: Firmware 2.3.7.0
Component: fon-base-firmware Version: 2.3.7.0 beta1
Severity: major
Cc: Hardware: 2.0g (FON2202)

Description

Hi, I built and flashed succesfully SVN 1999. I wanted to test WiFi?-bridge mode. I set up connection to my 2.0n Fonera (192.168.10.1). For 2.0g I set up 192.168.10.20/255.255.255.0 , Gateway and DNS.

Well, here comes the problem. I've lost all connectivity to the fonera. Neither LAN, WAN o Wifi connection is possible now. Only way to solve this was failsafe mode and then reflash.

Why is Wifi-bridge mode causing this?

Attachments (0)

Change History (6)

comment:1 Changed 6 years ago by matthijs

  • Resolution set to wontfix
  • Severity changed from unknown to major
  • Status changed from new to closed

More people have been complaining about wifi-bridge mode not working in 2.0g. I suspect I've just not tested this particular configuration: wifi mode worked on 2.0g, wifi-bridge mode worked on 2.0n, so I assumed wifi-bridge mode would work on 2.0n as well.not working in wifi-bridge mode.

Turns out there is a fundamental problems with wifi-bridge mode. Imagine the following configuration:

Internet <--ethernet--> Fonera1 <--wifi--> Fonera2 <--ethernet--> PC

Fonera2 is connected to Fonera1 with wifi-brid

As for losing all connectivity: I suspect that the cause of this is that the wifi-client does not work in wifi-bridge mode. This means it can't connect to the internet, disabling the FON_FREE_INTERNET. MyPlace is probably broken because the 2.0g is constantly scanning and switching channels trying to connect the wifi client.

Connecting through LAN only seems not to work, since no DHCP server can be reached (the DHCP server lives at the other end of the wifi link, which is not working). I suspect that if you had tried a wired LAN connection and a static IP on your computer, you would have been able to reach the Fonera still.

Anyway, let's focus on why the wifi client is not working in wifi-bridge mode.

Turns out there is a fundamental problems with wifi-bridge mode. Imagine the following configuration:

Internet <--ethernet--> Fonera1 <--wifi--> Fonera2 <--ethernet--> PC

Fonera2 is connected to Fonera1 with wifi-bridge mode. The PC is connected to the Fonera2 using ethernet and wants to send a packet (say, a DHCP request) to Fonera1. This packet is sent by PC to Fonera2 first. Now, it has a source MAC address pointing to PC. The Fonera2 sees the packet and forwards it to Fonera1.

Now, there is a problem: In the wifi packet format, Fonera2 has to list its own MAC address as the source address for the wifi packet. But if it does so, Fonera1 will not know where the packet really came from (and more importantly, Fonera2 will not know it must forward the reply to PC, thinking the reply is meant for itself).

Fonera2 cannot keep the MAC address of PC in the source address, since Fonera1 will drop the packet because the source address is not one of the authenticated clients and Fonera1 will also not know where to send the reply (since it doesn't know PC is behind Fonera2).

The 2.0n Fonera solves this problem in the wifi driver: It applies some scary form of NAT, but for MAC addresses. The Fonera2 would forward the packet to Fonera1 using its own source MAC address, but keep track of this translation so the destination address of replies can be rewritten again to the MAC address of PC. I've not figured out how this works exactly, but it seems to Just Work.

Implementing something similar for 2.0g would be tricky and a lot of work (even though there are existing pieces of software to do this).

The "official" solution for this problem, is WDS. This enhances the wifi packet by switching on a few bits and adding both the orginal MAC address of PC as well as the sender address of Fonera2 into the packet. This sounds easy, but it is hard to get right. It doesn't work out of the box: It would require configuring a list of WDS clients on Fonera1, containing the MAC address of Fonera2. Also, WDS isn't an official standard, so it's known to not work in a lot of hardware combinations. For these reasons, I'll not be implementing this (at least not now, probably not ever...).

So, I'll be disabling wifi-bridge support on 2.0g. It's a pity, but it turns out this is a more complex feature than I had expected (I was actually sortof surprised it worked when I tried it, turns out the complex Ralink driver was responsible for that...).

comment:2 Changed 6 years ago by matthijs

Btw, see http://wiki.linux.edu/80211/frame for more info on the WDS parts of the frame (the "To DS" and "From DS" parts).

comment:3 Changed 6 years ago by decodecoding@…

Thanks for your time explaining this. I agree it is better to disable this in 2.0g.

Wifi mode works fine on 2.0g so I guess it'll do the trick.

comment:4 Changed 6 years ago by matthijs

  • Milestone set to Firmware 2.3.7.0

comment:5 Changed 6 years ago by matthijs

(In [2013]) luci: Only offer wifi-bridge mode on 2.0n.

The 2.0n driver contains a workaround to make wifi-bridge mode work without WDS. Other drivers (e.g., 2.0g) need WDS to work, which is not supported currently. This makes sure wifi-bridge mode is not offered when it would not work.

References: #1080, #654

comment:6 Changed 6 years ago by matthijs

(In [2020]) Make sure wifi-bridge mode is available on 2.0n.

In r2013, a check was added to make wifi-bridge mode available only on 2.0n. However, the check used the wrong device string, so effectively wifi-bridge mode was made unavailable on all devices. This fixes that.

References: #1080

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.