how do you manage wifi cards nowadays?

[legacy]

so I have recently bought a couple of supercool Atheros9K miniPCI-wifi cards (300Mbps); they are PCI_MEM_ONLY, my routers is compliant with them, and this is very very good 

There is just a little problem: the ath9k kernel module doesn't support the bridged-mode, so you cannot add the wlan0 to the bridge 

Code: [Select]

  192.168.1.4       |
   mybridge --------|
                    |---------- Eth0
                    |---------- Eth1
                    |---------- Eth2
                    |---------- wlan0
                    |


so, currently I have two subnet, 192.168.1.4 for the bridged wired lan (three ethernet cards are bridged), and 192.168.2.4 for the wireless.

Code: [Select]

  192.168.1.4       |
   mybridge --------|
                    |---------- Eth0
                    |---------- Eth1
                    |---------- Eth2

  192.168.2.4       |
   wlan0 -----------|

I would like to add the wlan0 physical interface to the bridge, and this worked with intel-2200 wifi cards (54Mbps) by using the old (and dead) MadWifi driver, whereas the new ath9K kernel module is a completely different story.


So, how do you manage this, guys?

[legacy]

(Linux v4.9.91-Roaring-Lionus)

[magic]

 

It works out of the box in OpenWRT on a bazillion of Atheros chipset routers.

[legacy]

It works out of the box in OpenWRT on a bazillion of Atheros chipset routers.

I am not using OpenWRT, everything is *litteraly* made from the scratch.

Besides, bridging the Wlan0 worked on routers like Fonera2 was about dealing with Atheros5, driven by MadWifi + patch + hacks. Ath9K is another plannet for perfomances, specifications, and drivers.

[legacy]

I haven't yet looked at a modern OpenWRT's stuff for understanding *HOW* it's currently managed nowadays.

Anyway, this doesn't work as it worked time ago.

Code: [Select]

# brctl addif mybridge wlan0
can't add wlan0 to bridge mybridge: Operation not supported


[legacy]

Code: [Select]

uc-rb532 wifi # iw dev wlan0 interface add wlan1 type managed 4addr on
uc-rb532 wifi # brctl addif mybridge wlan1

this looks a compromise, but I am not 100% sure I want to use it.

[Monkeh]

Code: [Select]

uc-rb532 wifi # iw dev wlan0 interface add wlan1 type managed 4addr on
uc-rb532 wifi # brctl addif mybridge wlan1

this looks a compromise, but I am not 100% sure I want to use it.

I am 100% sure if you want to bridge a station you want to use 4addr. It is not a compromise, it is a solution. Examine an 802.11 frame and the reason should be obvious.

[extide]

Do you need layer 2 stuff to work between the lan/wifi? You could just route between the subnets. I suppose that's what you're probably already doing, though.

[legacy]

Another irritating thing is that modern wifi cards cannot change the MAC-address like it was possible with old adapters. My fonera2 was using ath5k on the AHB bus and it didn't require any binary-blob built-in compiled within the kernel and it stored the MAC-address inside the flash, so you can literally change it by reprogramming a couple of cells. Both Redboot and uBoot do support it. My Ath9k refuses to change the MAC-address, and does not support the bridge, unless you accept to manage the device in "4-address mode", which is a non-standard extension to the IEEE 802.11 standard to allow transparent Ethernet bridging. So, if you enable it, you can bridge the WLAN, but then your router cannot be used as a hotspot because a lot of clients simply do not work.

So, I am thinking about making a userspace-bridge daemon by forwarding at the L2 level all the packets to a destination TUNTAP (offered by the Linux kernel) because this way it can be bridged.

Something like this (yes, with devices in promisc mode)

Code: [Select]

        wlan = getrawsocket("wlan0", SOCK_DGRAM);
        tap  = getrawsocket("tap0", SOCK_RAW);

            select(tap + wlan + 1, ...);
            if (FD_ISSET(wlan, ...))
            {
                forward_to_wlan();
            }
            if (FD_ISSET(tap, ...))
            {
                forward_to_tap();
            }


It ought to be working, but it's not a neat solution, anyway 

[legacy]

Do you need layer 2 stuff to work between the lan/wifi? You could just route between the subnets. I suppose that's what you're probably already doing, though.

no! I do not want two subnets, I want one subnet, with all the ethernet NICs and wlan0 bridged together!
Besides, the wlan0 is requeried to operate with hostapd, so it cannot be set in 4addr-mode.

The old fonera2 (2003) was able to do it 

[Monkeh]

My Ath9k refuses to change the MAC-address, and does not support the bridge, unless you accept to manage the device in "4-address mode", which is a non-standard extension to the IEEE 802.11 standard to allow transparent Ethernet bridging.

And how else would you like it to work? There are some disgusting hacky solutions available already, but why would you want to use them when you have the correct solution available and working?

So, if you enable it, you can bridge the WLAN, but then your router cannot be used as a hotspot because a lot of clients simply do not work.

Nonsense.

[extide]

Quote from: extide on Today at 04:09:27 pm

Do you need layer 2 stuff to work between the lan/wifi? You could just route between the subnets. I suppose that's what you're probably already doing, though.

no! I do not want two subnets, I want one subnet, with all the ethernet NICs and wlan0 bridged together!
Besides, the wlan0 is requeried to operate with hostapd, so it cannot be set in 4addr-mode.

The old fonera2 (2003) was able to do it 

Ok, sounds like you've got it then

[legacy]

Nonsense.

Precisely! With 4addr enabled you're likely to get completely ignored by the AP: association succeeds but all data frames disappear into the ether. This could be for security reasons.

[Monkeh]

Nonsense.

Precisely! With 4addr enabled you're likely to get completely ignored by the AP: association succeeds but all data frames disappear into the ether. This could be for security reasons.

4addr enabled on which end?

There is no problem with clients connecting to a 4addr AP. Any client which fails is broken - stop using it.

Alternatively, set up a normal AP (you can use the same radio..) for broken trash.

[legacy]

4addr enabled on which end?

In this working scenario, the rb532 board is the client of my home AP: and, as I worte, the association succeeds but all data frames disappear into the ether.

There is no problem with clients connecting to a 4addr AP. Any client which fails is broken - stop using it.

Not sure it fully works. e.g. using my rb532 board as hotspot, and my Windows XP as client: it perfectly works, but my MacOSX doesn't like the 4-addr mode, 100% packets lost, but, even weird still, this doesn't happen when the wifi card is not bridged.

So I an not really sure it works with all the clients: e.g. what about mobile phones? I have to test them.

[Monkeh]

4addr enabled on which end?

In working scenario, the rb532 board is the client of my home AP. I wanted to try both the ends.

You will need support enabled on both ends, how else could it work?

There is no problem with clients connecting to a 4addr AP. Any client which fails is broken - stop using it.

Not sure it fully works. e.g. ysing my rb532 board as hotspot, and my Windows XP as client: it perfectly works, but my MacOSX doesn't like the 4-addr mode, 100% packets lost, but, even weird still, this doesn't happen when the wifi card is not bridged.

So I an not really sure it works with all the clients: e.g. what about mobile phones? I have to test them.

There's a lot more to it than 'MacOSX' - they've used many chipsets and many drivers over the years. Most of them fundamentally broken, being Broadcom, so there's that.

I have no and have encountered no devices with issues with 4addr APs - again, set up an AP for faulty devices, or just one for your bridge, if you must. Do not resort to silly userspace hacks.

[legacy]

You will need support enabled on both ends, how else could it work?

Precisely: and I cannot touch a Fastweb AP! This configuration needs to operate even with AP that you cannot reconfigure.

Otherwise it would be a piece of cake 

[Monkeh]

You will need support enabled on both ends, how else could it work?

Precisely: and I cannot touch a Fastweb AP! This configuration needs to operate even with AP that you cannot reconfigure.

Otherwise it would be a piece of cake 

So don't use their crippled AP.

You can use relayd to bodge things if you must, but APs are cheap.

[magic]

modern wifi cards cannot change the MAC-address like it was possible with old adapters

It's probably still some external EEPROM somewhere, if you really are desperate to do it that way.
I think they blocked it becaue IIRC the same EEPROM also contained some radio calibration data which shouldn't be changed.

You can change MAC at runtime with ifconfig.

relayd

How does that thing work and how does it deal with an AP which doesn't accept 4 address frames? I can find millions of identical tutorials on how to set it up but not a word of explanation.
Does it just associate every ethernet-side MAC with the AP and send 3 address frames on behalf of it? That's an idea I came up with many years ago when I didn't even know that WDS exists but never implemented it nor really expected anyone else to do.

[legacy]

It's probably still some external EEPROM somewhere, if you really are desperate to do it that way.
I think they blocked it becaue IIRC the same EEPROM also contained some radio calibration data which shouldn't be changed.

On Ath5 the EEPROM is simply memory mapped and it's exposed on the Ahb bus, so you can easily access if for reprogramming. It contains the PLL scale for setting the CPU clock, the MAC-address as well as all the stuff required for the regulatory domain of wireless networks (don't know what it is, I know it's there); Of course I know where all the bytes for MAC-address are located, so I can easily hex-edit the whole image without ruining the calibration data.
 
On Ath9k the EEPROM seems not directly accessible from the PCI, and things are getting more complex.

You can change MAC at runtime with ifconfig.

Of course yes, but for other reasons I need to change it permanently and before Linux takes control.

[legacy]

I can find millions of identical tutorials on how to set it up but not a word of explanation.

Googling about this stuff has given me a lot of confusion and wrong things. Besides, it seems that things have changed a lot.

Let's ask in OpenWRT forum, and let's check by myself how OpenWRT does manage it.

[legacy]

So, I have installed three wireless card in my RS/PRO (the rb532 only has 2 miniPCI slots, the RS/PRO has 3 slots)

- one as AP @ 2.4Ghz <--- this requires hostapd
- one as ad-hoc @ 2.4Ghz
- one as ad-hoc @ 5Ghz

both the two ad-hoc radio link are bridged, and they are working without any issue! I like it! ad-hoc networks lack the complexities of infrastructure setup and administration, which is good because it enables devices to create and join networks "on the fly" 

This is good for what these two ad-hok links have to do.

[Monkeh]

relayd

How does that thing work and how does it deal with an AP which doesn't accept 4 address frames? I can find millions of identical tutorials on how to set it up but not a word of explanation.
Does it just associate every ethernet-side MAC with the AP and send 3 address frames on behalf of it? That's an idea I came up with many years ago when I didn't even know that WDS exists but never implemented it nor really expected anyone else to do.

I have never needed to use it, so..

It is used for this purpose, that's all I can tell you. I just use functional APs.

[magic]

Okay, I tracked it down.
https://git.openwrt.org/?p=project/relayd.git;a=tree

The secret solution is that it doesn't work in layer 2, only with IPv4.

It forwards ARP between the "bridged" networks and, when forwarding a response, changes the MAC address to its own. As a result, hosts send IP packets destined to the other side of the bridge to the bridge's MAC and the bridge's kernel IP stack forwards them to their actual destination. Static rules are set up by relayd for that. The source MAC of forwarded packets is the bridge's own so dumb APs are happy.

That's indeed one ugly kludge.

[macboy]

I use OpenWRT and my routers have no trouble bridging a pair of Atheros9k mini-PCI cards (2.4 and 5 GHz) to my LAN. Maybe they have made some driver changes that haven't been picked up elsewhere? I don't know what OpenWRT does under the hood, but configuration is dead simple and it has worked for me for nearly 7 years.