Bridging with wireless

[jserink]

Hi All;

I just spent the morning trying to get bridging working via my wireless (ath5K) and my ethernet port. The other end of the bridge is a Compex access point. I had another compex AP at this end setup in what compex calls "transparent cleint mode" and compex used linux inside so figured I should be able to do the same with my laptop.

Was unsuccessful however. My steps were:
run this:
wpa_supplicant -i wlan1 -c /etc/wpa_supplicant.conf -D wext &

after which my laptop would associate with the compex AP.

I then setup my bridge:
ip link set dev eth0 up
ip addr add dev wlan1 0.0.0.0/32
ip addr add dev eth0 0.0.0.0/32
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 wlan1
ip addr add dev br0 192.168.1.99/24 brd 192.168.1.255
ip addr add dev br0 10.3.36.77/24 brd 10.3.36.255
ip link set dev br0 up

as soon as the last command is entered, that is, I bring the bridge interface up, I get this:
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:80:48:5c:80:c3 (SSID='MSK' freq=2457 MHz)
Associated with 00:80:48:5c:80:c3
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:80:48:5c:80:c3 (SSID='MSK' freq=2457 MHz)
Associated with 00:80:48:5c:80:c3
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:80:48:5c:80:c3 (SSID='MSK' freq=2457 MHz)
Associated with 00:80:48:5c:80:c3
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:80:48:5c:80:c3 (SSID='MSK' freq=2457 MHz)
Associated with 00:80:48:5c:80:c3

And it can never associate again. I'm concluding that wpa_supplicant cannot be used in bridged configuration. The only references I can find are people that have used hostapd on APs to do bridging but no one using wpa_supplicant on the lcient side to do the same.

A few questions for any experts:
1. Can hostapd be used on a client to associate with an AP?
2. Are there any known tweaks for wpa_supplicant to get it to work when wlan1 is used in a bridge?

My work around meant I had to change the DNS entry on the hosts in the segment I was bridging to (I could have used DNSmas but that's enough playing for today) and just did this:
ip addr add deb eth0 192.168.29.1 brd 192.168.29.255
ip link set dev eth0 up
iptables -t nat -I POSTROUTING -o wlan1 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

So, its working but, would really like to see if bridging would work.

Cheers,
john

[Ant P.]

You need to add the wifi port to the bridge first so it inherits the same MAC address. It's a hardware limitation in the wifi card.

[jserink]

[Ant P.]

Add it before eth0.

[Mad Merlin]

IIRC, most wireless cards cannot be (usefully) bridged as the hardware refuses to emit more than one MAC address. Wired cards do not have this limitation.
_________________
Game! - Where the stick is mightier than the sword!

[jserink]

[jserink]

Hi Guys:

Ok, I have decided to go back to the Madwifi drivers, specifically the madwifi-hal-0.10.5.6-r4126-20100324.tar and NOT the ones in portage as they are horribly dated. The madwifi drivers can be used in transparent bridging as they have a WDS option that when set to 1 sets the packets to 4 address frames for Etherent bridging to work (http://madwifi-project.org/wiki/UserDocs/TransparentBridge). However, this makes things messy with portage:
-if I wnabled the madwifi USE flag for wpa_supplicant, portage will try and pull in the obsolete madwifi in portage,

How can I prevent portage from doing this without having to manually supply the madwifi USE flag everything I emerge wpa-supplicant? Does any one have a work around?

On way is if I could find an overlay with the latest madwifi development build.

Looking for suggestions here.

Cheers,
john

[Mad Merlin]

It appears there's quite a bit of noise about newer versions (and cooresponding ebuilds) of madwifi in Gentoo's bug tracker. It looks like a long story, but try starting here: https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+madwifi, then sort by bug id descending. If you don't care about the whole story, you could probably safely just drop one of the attached ebuilds into a local overlay and hope for the best.

If it's not already obvious, I would suggest you finding (or creating) a newer ebuild and using that.
_________________
Game! - Where the stick is mightier than the sword!