wpa_supplicant bridging problems

wpa_supplicant bridging problems

[J Mo]

Hello everyone

I am having a very difficult time with a wireless bridging problem.

My objective is to use a Debian GNU/Linux host as a wireless ethernet 
bridge between itself, some hosts connected through a switch on it's 
eth0 port, and an OpenWRT router.

I have a test setup consisting of a laptop, a small PC (802.11 client), 
and the OpenWRT AP/router.

The wifi client system is an amd64(intel) with one 802.11 interface and 
a 1000BASE-T interface. The 802.11 hardware here is an Intel 3160. The 
OS is Debian GNU/Linux unstable with kernel 4.3.0-1-amd64 and 
wpasupplicant package version 2.3-2.3.

The 802.11 AP is a TP-Link TL-WR710N which is based off the Atheros ar9331.



My problem is the moment I bridge the wlan0 interface on the 802.11 PC 
client, wpa_supplicant stops doing it's job. It stops responding to any 
EAPOL frames from the AP, even though it seems to be receiving them.

It is noteworthy that the bridging works. I am able to get a DHCP lease 
on the laptop from the OpenWRT AP/router via bridging though the PC. 
Traffic passes both way and everything works great until the next WPA 
rekey event comes along (every 10 minutes by default for OpenWRT), and 
then the client gets deauth'ed from the AP because it fails to respond.

The only way I can get this to work is to first bring up my wlan0 
interface on the PC so that wpa_supplicant authenticates itself 
correctly. Once the 802.11 layer 2 is up, I manually use brctl to bridge 
in the eth0 and wlan0 ports on the PC. Everything works fine until the 
AP wants to rekey or the client needs to re-auth for some reason.



Here is what my setup looks like:

The OpenWRT device setup is pretty standard. The only thing required for 
the bridging is the addition of the "option wds 1" parameter under the 
wifi-iface in the "wireless" config file. The wds parameter enables 
4-address frames to allow the bridging. In case it's relevant, I'm doing 
WPA2 PSK AES/CCMP.

My PC/client /etc/network/interfaces file looks kind of like this:

allow-hotplug eth0
iface eth0 inet manual

auto wlan0
iface wlan0 inet manual
     wpa-debug-level 2
     wpa-ssid POTATONET
     wpa-psk XXXXXXXXX
     pre-up iw dev wlan0 set 4addr on
     pre-up iw dev wlan0 set power_save off

allow-auto br0
# iface br0 inet dhcp
iface br0 inet manual
     # bridge_ports wlan0
     bridge_ports none
     bridge_stp off
     bridge_waitport 0
     bridge_fd 0
     # wpa-iface wlan0
     # wpa-bridge br0


I bring up wlan0 and br0:

sudo ifup wlan0
sudo ifup br0

At this point, the wlan0 port should be associated to the AP, even 
though I don't have any layer 3 interfaces on the PC yet. If I force a 
re-authentication from the AP it works fine. WPA rekey works fine.

I do this to bridge up the interfaces:
     sudo brctl addif br0 eth0
     sudo brctl addif br0 wlan0

 From this point on, wpa_supplicant stops working correctly. However, 
the bridge works and ethernet frames are being passed between the laptop 
off of PC port eth0 and the OpenWRT AP. Everything is fine until the WPA 
rekey happens and then the wlan0 interface goes down and stops working.

I did a tcpdump to find out what was going on and discovered that once 
the AP asked for re-authentication from the client, no traffic was going 
out of the wlan0 interface on the client PC. This was supported by 
ifconfig TX counters. wpa_supplicant stops replying to the AP on the 
wlan0 interface.

It should be noted at this point that I am aware wpa_supplicant is 
supposed to need the "-b" argument in this kind of setup, which is what 
the commented-out "wpa-bridge" parameter in the "interfaces" file above 
is for, but it didn't work. I verified the arguments given to 
wpa_supplicant were correct via ps:

/sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 -b 
br0 -D nl80211,wext -C /run/wpa_supplicant



Additional notes and observations:

Just to be clear, I have inspected the macaddr and arp tables on both 
the OpenWRT AP and the laptop and the MACs are correct. The wireless 
bridging is definitely working as expected. Let me know if you want 
output from these commands, but I don't think they are relevant.

The default WPA rekey timer is every 10 minutes on OpenWRT, but I can 
force the AP to re-authenticate the client by doing this:
ubus call hostapd.wlan0 del_client '{"addr":"34:de:1a:zz:zz:zz", 
"reason":1, "deauth":true, "ban_time":0}'



Finally, here is some debugging output (wpa_supplicant -ddd) from the 
client PC during a failed re-auth with the AP.

http://jmomo.net/files/wpa_probs.txt



What do?

If additional debugging is needed, let me know what to do. If this is a 
Debian package problem, let me know and I'll go open a bug there.

Re: wpa_supplicant bridging problems

[Simon Malthieu]

Hi,

Have you tried to add wlan0 to the bridge **before**
wpa_supplicant (with the -b option) is launched ?

wpa_supplicant opens a socket to listen to EAPOL frames
in the bridge, and it does not seem to work if the interface
is not in the bridge at start.

Regards,
Simon


On 17/02/2016 04:30, J Mo wrote:
>
> Hello everyone
>
> I am having a very difficult time with a wireless bridging problem.
>
> My objective is to use a Debian GNU/Linux host as a wireless ethernet 
> bridge between itself, some hosts connected through a switch on it's 
> eth0 port, and an OpenWRT router.
>
> I have a test setup consisting of a laptop, a small PC (802.11 
> client), and the OpenWRT AP/router.
>
> The wifi client system is an amd64(intel) with one 802.11 interface 
> and a 1000BASE-T interface. The 802.11 hardware here is an Intel 3160. 
> The OS is Debian GNU/Linux unstable with kernel 4.3.0-1-amd64 and 
> wpasupplicant package version 2.3-2.3.
>
> The 802.11 AP is a TP-Link TL-WR710N which is based off the Atheros 
> ar9331.
>
>
>
> My problem is the moment I bridge the wlan0 interface on the 802.11 PC 
> client, wpa_supplicant stops doing it's job. It stops responding to 
> any EAPOL frames from the AP, even though it seems to be receiving them.
>
> It is noteworthy that the bridging works. I am able to get a DHCP 
> lease on the laptop from the OpenWRT AP/router via bridging though the 
> PC. Traffic passes both way and everything works great until the next 
> WPA rekey event comes along (every 10 minutes by default for OpenWRT), 
> and then the client gets deauth'ed from the AP because it fails to 
> respond.
>
> The only way I can get this to work is to first bring up my wlan0 
> interface on the PC so that wpa_supplicant authenticates itself 
> correctly. Once the 802.11 layer 2 is up, I manually use brctl to 
> bridge in the eth0 and wlan0 ports on the PC. Everything works fine 
> until the AP wants to rekey or the client needs to re-auth for some 
> reason.
>
>
>
> Here is what my setup looks like:
>
> The OpenWRT device setup is pretty standard. The only thing required 
> for the bridging is the addition of the "option wds 1" parameter under 
> the wifi-iface in the "wireless" config file. The wds parameter 
> enables 4-address frames to allow the bridging. In case it's relevant, 
> I'm doing WPA2 PSK AES/CCMP.
>
> My PC/client /etc/network/interfaces file looks kind of like this:
>
> allow-hotplug eth0
> iface eth0 inet manual
>
> auto wlan0
> iface wlan0 inet manual
>     wpa-debug-level 2
>     wpa-ssid POTATONET
>     wpa-psk XXXXXXXXX
>     pre-up iw dev wlan0 set 4addr on
>     pre-up iw dev wlan0 set power_save off
>
> allow-auto br0
> # iface br0 inet dhcp
> iface br0 inet manual
>     # bridge_ports wlan0
>     bridge_ports none
>     bridge_stp off
>     bridge_waitport 0
>     bridge_fd 0
>     # wpa-iface wlan0
>     # wpa-bridge br0
>
>
> I bring up wlan0 and br0:
>
> sudo ifup wlan0
> sudo ifup br0
>
> At this point, the wlan0 port should be associated to the AP, even 
> though I don't have any layer 3 interfaces on the PC yet. If I force a 
> re-authentication from the AP it works fine. WPA rekey works fine.
>
> I do this to bridge up the interfaces:
>     sudo brctl addif br0 eth0
>     sudo brctl addif br0 wlan0
>
> From this point on, wpa_supplicant stops working correctly. However, 
> the bridge works and ethernet frames are being passed between the 
> laptop off of PC port eth0 and the OpenWRT AP. Everything is fine 
> until the WPA rekey happens and then the wlan0 interface goes down and 
> stops working.
>
> I did a tcpdump to find out what was going on and discovered that once 
> the AP asked for re-authentication from the client, no traffic was 
> going out of the wlan0 interface on the client PC. This was supported 
> by ifconfig TX counters. wpa_supplicant stops replying to the AP on 
> the wlan0 interface.
>
> It should be noted at this point that I am aware wpa_supplicant is 
> supposed to need the "-b" argument in this kind of setup, which is 
> what the commented-out "wpa-bridge" parameter in the "interfaces" file 
> above is for, but it didn't work. I verified the arguments given to 
> wpa_supplicant were correct via ps:
>
> /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 
> -b br0 -D nl80211,wext -C /run/wpa_supplicant
>
>
>
> Additional notes and observations:
>
> Just to be clear, I have inspected the macaddr and arp tables on both 
> the OpenWRT AP and the laptop and the MACs are correct. The wireless 
> bridging is definitely working as expected. Let me know if you want 
> output from these commands, but I don't think they are relevant.
>
> The default WPA rekey timer is every 10 minutes on OpenWRT, but I can 
> force the AP to re-authenticate the client by doing this:
> ubus call hostapd.wlan0 del_client '{"addr":"34:de:1a:zz:zz:zz", 
> "reason":1, "deauth":true, "ban_time":0}'
>
>
>
> Finally, here is some debugging output (wpa_supplicant -ddd) from the 
> client PC during a failed re-auth with the AP.
>
> http://jmomo.net/files/wpa_probs.txt
>
>
>
> What do?
>
> If additional debugging is needed, let me know what to do. If this is 
> a Debian package problem, let me know and I'll go open a bug there.
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wpa_supplicant bridging problems

[J Mo]

I will go look and verify the order of operations for the Debian 
networking system, but I am under the impression that it brings up the 
wlan interface (via bridge_ports), does all bridging, and then processes 
the wpa-* commands.

In other words, it's already doing what you suggested.

Also, wpa_supplicant gives errors if either the 802.11 interface (-i 
wlan0) or bridge interface (-b br0) wasn't up at the time it was 
launched, so I don't think it's even possible to get the order wrong 
without obvious signs. I just don't think that's the issue here.

Still, I'll take your advice and double check. I think I can debug the 
ifup/down scripts a little more than what I've already done, but I don't 
think order of operation is an issue.

One thing to note is that if I bridge the wlan0 interface and let an 
AP-reauth fail and then take the bridge off, wpa_supplicant starts 
working again. Put the bridge back on and it breaks again, etc. I can do 
this live with brctl without restarting wpa_supplicant and it will start 
and stop working.

I don't even understand why wpa_supplicant needs to know about the 
bridge in this situation, but whatever!

FYI By "official method", I mean the ideal config setup with an 
"interfaces" config like this:

allow-auto wlan0
iface wlan0 inet manual

allow-auto br0
iface br0 inet dhcp
     bridge_ports wlan0
     bridge_stp off
     bridge_waitport 5
     bridge_fd 0
     wpa-ssid POTATONET
     wpa-psk xxxxxxx
     wpa-iface wlan0
     wpa-bridge br0
     pre-up iw dev wlan0 set 4addr on
     pre-up iw dev wlan0 set power_save off



On 2/17/16 00:49, Simon Malthieu wrote:
> Hi,
>
> Have you tried to add wlan0 to the bridge **before**
> wpa_supplicant (with the -b option) is launched ?
>
> wpa_supplicant opens a socket to listen to EAPOL frames
> in the bridge, and it does not seem to work if the interface
> is not in the bridge at start.
>
> Regards,
> Simon
>
>
> On 17/02/2016 04:30, J Mo wrote:
>>
>> Hello everyone
>>
>> I am having a very difficult time with a wireless bridging problem.
>>
>> My objective is to use a Debian GNU/Linux host as a wireless ethernet 
>> bridge between itself, some hosts connected through a switch on it's 
>> eth0 port, and an OpenWRT router.
>>
>> I have a test setup consisting of a laptop, a small PC (802.11 
>> client), and the OpenWRT AP/router.
>>
>> The wifi client system is an amd64(intel) with one 802.11 interface 
>> and a 1000BASE-T interface. The 802.11 hardware here is an Intel 
>> 3160. The OS is Debian GNU/Linux unstable with kernel 4.3.0-1-amd64 
>> and wpasupplicant package version 2.3-2.3.
>>
>> The 802.11 AP is a TP-Link TL-WR710N which is based off the Atheros 
>> ar9331.
>>
>>
>>
>> My problem is the moment I bridge the wlan0 interface on the 802.11 
>> PC client, wpa_supplicant stops doing it's job. It stops responding 
>> to any EAPOL frames from the AP, even though it seems to be receiving 
>> them.
>>
>> It is noteworthy that the bridging works. I am able to get a DHCP 
>> lease on the laptop from the OpenWRT AP/router via bridging though 
>> the PC. Traffic passes both way and everything works great until the 
>> next WPA rekey event comes along (every 10 minutes by default for 
>> OpenWRT), and then the client gets deauth'ed from the AP because it 
>> fails to respond.
>>
>> The only way I can get this to work is to first bring up my wlan0 
>> interface on the PC so that wpa_supplicant authenticates itself 
>> correctly. Once the 802.11 layer 2 is up, I manually use brctl to 
>> bridge in the eth0 and wlan0 ports on the PC. Everything works fine 
>> until the AP wants to rekey or the client needs to re-auth for some 
>> reason.
>>
>>
>>
>> Here is what my setup looks like:
>>
>> The OpenWRT device setup is pretty standard. The only thing required 
>> for the bridging is the addition of the "option wds 1" parameter 
>> under the wifi-iface in the "wireless" config file. The wds parameter 
>> enables 4-address frames to allow the bridging. In case it's 
>> relevant, I'm doing WPA2 PSK AES/CCMP.
>>
>> My PC/client /etc/network/interfaces file looks kind of like this:
>>
>> allow-hotplug eth0
>> iface eth0 inet manual
>>
>> auto wlan0
>> iface wlan0 inet manual
>>     wpa-debug-level 2
>>     wpa-ssid POTATONET
>>     wpa-psk XXXXXXXXX
>>     pre-up iw dev wlan0 set 4addr on
>>     pre-up iw dev wlan0 set power_save off
>>
>> allow-auto br0
>> # iface br0 inet dhcp
>> iface br0 inet manual
>>     # bridge_ports wlan0
>>     bridge_ports none
>>     bridge_stp off
>>     bridge_waitport 0
>>     bridge_fd 0
>>     # wpa-iface wlan0
>>     # wpa-bridge br0
>>
>>
>> I bring up wlan0 and br0:
>>
>> sudo ifup wlan0
>> sudo ifup br0
>>
>> At this point, the wlan0 port should be associated to the AP, even 
>> though I don't have any layer 3 interfaces on the PC yet. If I force 
>> a re-authentication from the AP it works fine. WPA rekey works fine.
>>
>> I do this to bridge up the interfaces:
>>     sudo brctl addif br0 eth0
>>     sudo brctl addif br0 wlan0
>>
>> From this point on, wpa_supplicant stops working correctly. However, 
>> the bridge works and ethernet frames are being passed between the 
>> laptop off of PC port eth0 and the OpenWRT AP. Everything is fine 
>> until the WPA rekey happens and then the wlan0 interface goes down 
>> and stops working.
>>
>> I did a tcpdump to find out what was going on and discovered that 
>> once the AP asked for re-authentication from the client, no traffic 
>> was going out of the wlan0 interface on the client PC. This was 
>> supported by ifconfig TX counters. wpa_supplicant stops replying to 
>> the AP on the wlan0 interface.
>>
>> It should be noted at this point that I am aware wpa_supplicant is 
>> supposed to need the "-b" argument in this kind of setup, which is 
>> what the commented-out "wpa-bridge" parameter in the "interfaces" 
>> file above is for, but it didn't work. I verified the arguments given 
>> to wpa_supplicant were correct via ps:
>>
>> /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 
>> -b br0 -D nl80211,wext -C /run/wpa_supplicant
>>
>>
>>
>> Additional notes and observations:
>>
>> Just to be clear, I have inspected the macaddr and arp tables on both 
>> the OpenWRT AP and the laptop and the MACs are correct. The wireless 
>> bridging is definitely working as expected. Let me know if you want 
>> output from these commands, but I don't think they are relevant.
>>
>> The default WPA rekey timer is every 10 minutes on OpenWRT, but I can 
>> force the AP to re-authenticate the client by doing this:
>> ubus call hostapd.wlan0 del_client '{"addr":"34:de:1a:zz:zz:zz", 
>> "reason":1, "deauth":true, "ban_time":0}'
>>
>>
>>
>> Finally, here is some debugging output (wpa_supplicant -ddd) from the 
>> client PC during a failed re-auth with the AP.
>>
>> http://jmomo.net/files/wpa_probs.txt
>>
>>
>>
>> What do?
>>
>> If additional debugging is needed, let me know what to do. If this is 
>> a Debian package problem, let me know and I'll go open a bug there.
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wpa_supplicant bridging problems

[J Mo]

I decided to grab another 802.11 adapter and test with it. This time a 
rtl8192cu (ALFA AWUS036NHR). Same behavior. No change.

Here is what happens when I run the Debian ifup script in verbose mode:

user@host-->sudo ifup -v br0
Configuring interface br0=br0 (inet)
iw dev wlan0 set 4addr on
iw dev wlan0 set power_save off
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge

Waiting for a max of 5 seconds for wlan0 to become available.

Waiting for br0 to get ready (MAXWAIT is 2 seconds).
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/vlan
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
wpa_supplicant: wpa-bridge br0
wpa_supplicant: wpa-driver nl80211,wext (default)
wpa_supplicant: /sbin/wpa_supplicant -s -B -P 
/run/wpa_supplicant.wlan0.pid -i wlan0 -b br0 -D nl80211,wext -C 
/run/wpa_supplicant
Starting /sbin/wpa_supplicant...
wpa_supplicant: creating sendsigs omission pidfile: 
/run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid
wpa_supplicant: ctrl_interface socket located at /run/wpa_supplicant/wlan0
wpa_supplicant: configuring network block -- 0
wpa_supplicant: wpa-ssid "POTATONET" -- OK
wpa_supplicant: wpa-psk ***** -- OK
wpa_supplicant: enabling network block 0 -- OK
/bin/ip addr add 192.168.130.251/255.255.255.0 broadcast 192.168.130.255 
       dev br0 label br0
/bin/ip link set dev br0   up

/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/000resolvconf
run-parts: executing /etc/network/if-up.d/arping
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/clamav-freshclam-ifupdown
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/ip
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart
run-parts: executing /etc/network/if-up.d/wpasupplicant



It is notable that if I remove the "pre-up iw dev wlan0 set 4addr on" 
parameter from the interfaces config file under br0, I get this error 
when attempting to bring the interface up:

Waiting for a max of 0 seconds for wlan0 to become available.
can't add wlan0 to bridge br0: Operation not supported

So that's the point where the wlan0 interface gets bridged onto br0. 
This indicates that the bridge is definitely exists and wlan0 is a 
member prior to wpa_supplicant being invoked.



On 2/17/16 02:05, J Mo wrote:
>
> I will go look and verify the order of operations for the Debian 
> networking system, but I am under the impression that it brings up the 
> wlan interface (via bridge_ports), does all bridging, and then 
> processes the wpa-* commands.
>
> In other words, it's already doing what you suggested.
>
> Also, wpa_supplicant gives errors if either the 802.11 interface (-i 
> wlan0) or bridge interface (-b br0) wasn't up at the time it was 
> launched, so I don't think it's even possible to get the order wrong 
> without obvious signs. I just don't think that's the issue here.
>
> Still, I'll take your advice and double check. I think I can debug the 
> ifup/down scripts a little more than what I've already done, but I 
> don't think order of operation is an issue.
>
> One thing to note is that if I bridge the wlan0 interface and let an 
> AP-reauth fail and then take the bridge off, wpa_supplicant starts 
> working again. Put the bridge back on and it breaks again, etc. I can 
> do this live with brctl without restarting wpa_supplicant and it will 
> start and stop working.
>
> I don't even understand why wpa_supplicant needs to know about the 
> bridge in this situation, but whatever!
>
> FYI By "official method", I mean the ideal config setup with an 
> "interfaces" config like this:
>
> allow-auto wlan0
> iface wlan0 inet manual
>
> allow-auto br0
> iface br0 inet dhcp
>     bridge_ports wlan0
>     bridge_stp off
>     bridge_waitport 5
>     bridge_fd 0
>     wpa-ssid POTATONET
>     wpa-psk xxxxxxx
>     wpa-iface wlan0
>     wpa-bridge br0
>     pre-up iw dev wlan0 set 4addr on
>     pre-up iw dev wlan0 set power_save off
>
>
>
> On 2/17/16 00:49, Simon Malthieu wrote:
>> Hi,
>>
>> Have you tried to add wlan0 to the bridge **before**
>> wpa_supplicant (with the -b option) is launched ?
>>
>> wpa_supplicant opens a socket to listen to EAPOL frames
>> in the bridge, and it does not seem to work if the interface
>> is not in the bridge at start.
>>
>> Regards,
>> Simon
>>
>>
>> On 17/02/2016 04:30, J Mo wrote:
>>>
>>> Hello everyone
>>>
>>> I am having a very difficult time with a wireless bridging problem.
>>>
>>> My objective is to use a Debian GNU/Linux host as a wireless 
>>> ethernet bridge between itself, some hosts connected through a 
>>> switch on it's eth0 port, and an OpenWRT router.
>>>
>>> I have a test setup consisting of a laptop, a small PC (802.11 
>>> client), and the OpenWRT AP/router.
>>>
>>> The wifi client system is an amd64(intel) with one 802.11 interface 
>>> and a 1000BASE-T interface. The 802.11 hardware here is an Intel 
>>> 3160. The OS is Debian GNU/Linux unstable with kernel 4.3.0-1-amd64 
>>> and wpasupplicant package version 2.3-2.3.
>>>
>>> The 802.11 AP is a TP-Link TL-WR710N which is based off the Atheros 
>>> ar9331.
>>>
>>>
>>>
>>> My problem is the moment I bridge the wlan0 interface on the 802.11 
>>> PC client, wpa_supplicant stops doing it's job. It stops responding 
>>> to any EAPOL frames from the AP, even though it seems to be 
>>> receiving them.
>>>
>>> It is noteworthy that the bridging works. I am able to get a DHCP 
>>> lease on the laptop from the OpenWRT AP/router via bridging though 
>>> the PC. Traffic passes both way and everything works great until the 
>>> next WPA rekey event comes along (every 10 minutes by default for 
>>> OpenWRT), and then the client gets deauth'ed from the AP because it 
>>> fails to respond.
>>>
>>> The only way I can get this to work is to first bring up my wlan0 
>>> interface on the PC so that wpa_supplicant authenticates itself 
>>> correctly. Once the 802.11 layer 2 is up, I manually use brctl to 
>>> bridge in the eth0 and wlan0 ports on the PC. Everything works fine 
>>> until the AP wants to rekey or the client needs to re-auth for some 
>>> reason.
>>>
>>>
>>>
>>> Here is what my setup looks like:
>>>
>>> The OpenWRT device setup is pretty standard. The only thing required 
>>> for the bridging is the addition of the "option wds 1" parameter 
>>> under the wifi-iface in the "wireless" config file. The wds 
>>> parameter enables 4-address frames to allow the bridging. In case 
>>> it's relevant, I'm doing WPA2 PSK AES/CCMP.
>>>
>>> My PC/client /etc/network/interfaces file looks kind of like this:
>>>
>>> allow-hotplug eth0
>>> iface eth0 inet manual
>>>
>>> auto wlan0
>>> iface wlan0 inet manual
>>>     wpa-debug-level 2
>>>     wpa-ssid POTATONET
>>>     wpa-psk XXXXXXXXX
>>>     pre-up iw dev wlan0 set 4addr on
>>>     pre-up iw dev wlan0 set power_save off
>>>
>>> allow-auto br0
>>> # iface br0 inet dhcp
>>> iface br0 inet manual
>>>     # bridge_ports wlan0
>>>     bridge_ports none
>>>     bridge_stp off
>>>     bridge_waitport 0
>>>     bridge_fd 0
>>>     # wpa-iface wlan0
>>>     # wpa-bridge br0
>>>
>>>
>>> I bring up wlan0 and br0:
>>>
>>> sudo ifup wlan0
>>> sudo ifup br0
>>>
>>> At this point, the wlan0 port should be associated to the AP, even 
>>> though I don't have any layer 3 interfaces on the PC yet. If I force 
>>> a re-authentication from the AP it works fine. WPA rekey works fine.
>>>
>>> I do this to bridge up the interfaces:
>>>     sudo brctl addif br0 eth0
>>>     sudo brctl addif br0 wlan0
>>>
>>> From this point on, wpa_supplicant stops working correctly. However, 
>>> the bridge works and ethernet frames are being passed between the 
>>> laptop off of PC port eth0 and the OpenWRT AP. Everything is fine 
>>> until the WPA rekey happens and then the wlan0 interface goes down 
>>> and stops working.
>>>
>>> I did a tcpdump to find out what was going on and discovered that 
>>> once the AP asked for re-authentication from the client, no traffic 
>>> was going out of the wlan0 interface on the client PC. This was 
>>> supported by ifconfig TX counters. wpa_supplicant stops replying to 
>>> the AP on the wlan0 interface.
>>>
>>> It should be noted at this point that I am aware wpa_supplicant is 
>>> supposed to need the "-b" argument in this kind of setup, which is 
>>> what the commented-out "wpa-bridge" parameter in the "interfaces" 
>>> file above is for, but it didn't work. I verified the arguments 
>>> given to wpa_supplicant were correct via ps:
>>>
>>> /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 
>>> -b br0 -D nl80211,wext -C /run/wpa_supplicant
>>>
>>>
>>>
>>> Additional notes and observations:
>>>
>>> Just to be clear, I have inspected the macaddr and arp tables on 
>>> both the OpenWRT AP and the laptop and the MACs are correct. The 
>>> wireless bridging is definitely working as expected. Let me know if 
>>> you want output from these commands, but I don't think they are 
>>> relevant.
>>>
>>> The default WPA rekey timer is every 10 minutes on OpenWRT, but I 
>>> can force the AP to re-authenticate the client by doing this:
>>> ubus call hostapd.wlan0 del_client '{"addr":"34:de:1a:zz:zz:zz", 
>>> "reason":1, "deauth":true, "ban_time":0}'
>>>
>>>
>>>
>>> Finally, here is some debugging output (wpa_supplicant -ddd) from 
>>> the client PC during a failed re-auth with the AP.
>>>
>>> http://jmomo.net/files/wpa_probs.txt
>>>
>>>
>>>
>>> What do?
>>>
>>> If additional debugging is needed, let me know what to do. If this 
>>> is a Debian package problem, let me know and I'll go open a bug there.
>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-wireless" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wpa_supplicant bridging problems

[J Mo]

I just did a frame dump from my OpenWRT device to look at what was going 
on at the 802.11 level.

To be honest, I barely know what I'm doing.

I took a good capture where 4-address frames were off on the client and 
then one where 4-address frames were on and the wlan0 interface was on 
the bridge.

I'm looking at both captures here in Wireshark and I see the probes, the 
initial authentication and association request/replies.

Then the EAPOL process is supposed to occur, and I see that go down okay 
in the successful capture.

But in the bad capture, there is no reply from the client. The AP sends 
out message 1 of 4 in the EAPOL negotiation and the station never responds.

But there are two things in the failed negotiation that I've noticed.

The first is that in the bad/fail capture there is a weird null-data 
frame sent from the station to the AP. I'm not sure what this is all 
about. The only thing I know about these frames is that they can be used 
for power management notifications (hey AP, I'm going to sleep until 
further notice). I don't see any PM flags in this frame. However, I 
notice that it's flags are 0x03 (00000011). Is this a notification that 
the client wants to do WDS? Because that's what the docs here I'm 
reading online says those flags are used for:

https://www.safaribooksonline.com/library/view/80211-wireless-networks/0596100523/ch04.html
See Table 4-2. Use of the address fields in data frames

And then I look at the EAPOL frame the OpenWRT host sends to my station 
after the null-data frame. It's the first EAPOL frame in the negotiation 
process and it's flags are 0x02 (00000010). Isn't that supposed to be 11?

I think OpenWRT might be broken here. I'm going to check with people 
over there and see what they have to say about this. It may be that the 
wpa_supplicant on the station is ignoring the EAPOL frames because this 
flag is wrong. But like I said, I don't know WTF I'm doing.

Captures available on request if anyone wants to look.



On 2/17/16 20:16, J Mo wrote:
>
> I decided to grab another 802.11 adapter and test with it. This time a 
> rtl8192cu (ALFA AWUS036NHR). Same behavior. No change.
>
> Here is what happens when I run the Debian ifup script in verbose mode:
>
> user@host-->sudo ifup -v br0
> Configuring interface br0=br0 (inet)
> iw dev wlan0 set 4addr on
> iw dev wlan0 set power_save off
> /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
> run-parts: executing /etc/network/if-pre-up.d/bridge
>
> Waiting for a max of 5 seconds for wlan0 to become available.
>
> Waiting for br0 to get ready (MAXWAIT is 2 seconds).
> run-parts: executing /etc/network/if-pre-up.d/ethtool
> run-parts: executing /etc/network/if-pre-up.d/vlan
> run-parts: executing /etc/network/if-pre-up.d/wireless-tools
> run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
> wpa_supplicant: wpa-bridge br0
> wpa_supplicant: wpa-driver nl80211,wext (default)
> wpa_supplicant: /sbin/wpa_supplicant -s -B -P 
> /run/wpa_supplicant.wlan0.pid -i wlan0 -b br0 -D nl80211,wext -C 
> /run/wpa_supplicant
> Starting /sbin/wpa_supplicant...
> wpa_supplicant: creating sendsigs omission pidfile: 
> /run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid
> wpa_supplicant: ctrl_interface socket located at 
> /run/wpa_supplicant/wlan0
> wpa_supplicant: configuring network block -- 0
> wpa_supplicant: wpa-ssid "POTATONET" -- OK
> wpa_supplicant: wpa-psk ***** -- OK
> wpa_supplicant: enabling network block 0 -- OK
> /bin/ip addr add 192.168.130.251/255.255.255.0 broadcast 
> 192.168.130.255       dev br0 label br0
> /bin/ip link set dev br0   up
>
> /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
> run-parts: executing /etc/network/if-up.d/000resolvconf
> run-parts: executing /etc/network/if-up.d/arping
> run-parts: executing /etc/network/if-up.d/avahi-autoipd
> run-parts: executing /etc/network/if-up.d/clamav-freshclam-ifupdown
> run-parts: executing /etc/network/if-up.d/ethtool
> run-parts: executing /etc/network/if-up.d/ip
> run-parts: executing /etc/network/if-up.d/mountnfs
> run-parts: executing /etc/network/if-up.d/openssh-server
> run-parts: executing /etc/network/if-up.d/upstart
> run-parts: executing /etc/network/if-up.d/wpasupplicant
>
>
>
> It is notable that if I remove the "pre-up iw dev wlan0 set 4addr on" 
> parameter from the interfaces config file under br0, I get this error 
> when attempting to bring the interface up:
>
> Waiting for a max of 0 seconds for wlan0 to become available.
> can't add wlan0 to bridge br0: Operation not supported
>
> So that's the point where the wlan0 interface gets bridged onto br0. 
> This indicates that the bridge is definitely exists and wlan0 is a 
> member prior to wpa_supplicant being invoked.
>
>
>
> On 2/17/16 02:05, J Mo wrote:
>>
>> I will go look and verify the order of operations for the Debian 
>> networking system, but I am under the impression that it brings up 
>> the wlan interface (via bridge_ports), does all bridging, and then 
>> processes the wpa-* commands.
>>
>> In other words, it's already doing what you suggested.
>>
>> Also, wpa_supplicant gives errors if either the 802.11 interface (-i 
>> wlan0) or bridge interface (-b br0) wasn't up at the time it was 
>> launched, so I don't think it's even possible to get the order wrong 
>> without obvious signs. I just don't think that's the issue here.
>>
>> Still, I'll take your advice and double check. I think I can debug 
>> the ifup/down scripts a little more than what I've already done, but 
>> I don't think order of operation is an issue.
>>
>> One thing to note is that if I bridge the wlan0 interface and let an 
>> AP-reauth fail and then take the bridge off, wpa_supplicant starts 
>> working again. Put the bridge back on and it breaks again, etc. I can 
>> do this live with brctl without restarting wpa_supplicant and it will 
>> start and stop working.
>>
>> I don't even understand why wpa_supplicant needs to know about the 
>> bridge in this situation, but whatever!
>>
>> FYI By "official method", I mean the ideal config setup with an 
>> "interfaces" config like this:
>>
>> allow-auto wlan0
>> iface wlan0 inet manual
>>
>> allow-auto br0
>> iface br0 inet dhcp
>>     bridge_ports wlan0
>>     bridge_stp off
>>     bridge_waitport 5
>>     bridge_fd 0
>>     wpa-ssid POTATONET
>>     wpa-psk xxxxxxx
>>     wpa-iface wlan0
>>     wpa-bridge br0
>>     pre-up iw dev wlan0 set 4addr on
>>     pre-up iw dev wlan0 set power_save off
>>
>>
>>
>> On 2/17/16 00:49, Simon Malthieu wrote:
>>> Hi,
>>>
>>> Have you tried to add wlan0 to the bridge **before**
>>> wpa_supplicant (with the -b option) is launched ?
>>>
>>> wpa_supplicant opens a socket to listen to EAPOL frames
>>> in the bridge, and it does not seem to work if the interface
>>> is not in the bridge at start.
>>>
>>> Regards,
>>> Simon
>>>
>>>
>>> On 17/02/2016 04:30, J Mo wrote:
>>>>
>>>> Hello everyone
>>>>
>>>> I am having a very difficult time with a wireless bridging problem.
>>>>
>>>> My objective is to use a Debian GNU/Linux host as a wireless 
>>>> ethernet bridge between itself, some hosts connected through a 
>>>> switch on it's eth0 port, and an OpenWRT router.
>>>>
>>>> I have a test setup consisting of a laptop, a small PC (802.11 
>>>> client), and the OpenWRT AP/router.
>>>>
>>>> The wifi client system is an amd64(intel) with one 802.11 interface 
>>>> and a 1000BASE-T interface. The 802.11 hardware here is an Intel 
>>>> 3160. The OS is Debian GNU/Linux unstable with kernel 4.3.0-1-amd64 
>>>> and wpasupplicant package version 2.3-2.3.
>>>>
>>>> The 802.11 AP is a TP-Link TL-WR710N which is based off the Atheros 
>>>> ar9331.
>>>>
>>>>
>>>>
>>>> My problem is the moment I bridge the wlan0 interface on the 802.11 
>>>> PC client, wpa_supplicant stops doing it's job. It stops responding 
>>>> to any EAPOL frames from the AP, even though it seems to be 
>>>> receiving them.
>>>>
>>>> It is noteworthy that the bridging works. I am able to get a DHCP 
>>>> lease on the laptop from the OpenWRT AP/router via bridging though 
>>>> the PC. Traffic passes both way and everything works great until 
>>>> the next WPA rekey event comes along (every 10 minutes by default 
>>>> for OpenWRT), and then the client gets deauth'ed from the AP 
>>>> because it fails to respond.
>>>>
>>>> The only way I can get this to work is to first bring up my wlan0 
>>>> interface on the PC so that wpa_supplicant authenticates itself 
>>>> correctly. Once the 802.11 layer 2 is up, I manually use brctl to 
>>>> bridge in the eth0 and wlan0 ports on the PC. Everything works fine 
>>>> until the AP wants to rekey or the client needs to re-auth for some 
>>>> reason.
>>>>
>>>>
>>>>
>>>> Here is what my setup looks like:
>>>>
>>>> The OpenWRT device setup is pretty standard. The only thing 
>>>> required for the bridging is the addition of the "option wds 1" 
>>>> parameter under the wifi-iface in the "wireless" config file. The 
>>>> wds parameter enables 4-address frames to allow the bridging. In 
>>>> case it's relevant, I'm doing WPA2 PSK AES/CCMP.
>>>>
>>>> My PC/client /etc/network/interfaces file looks kind of like this:
>>>>
>>>> allow-hotplug eth0
>>>> iface eth0 inet manual
>>>>
>>>> auto wlan0
>>>> iface wlan0 inet manual
>>>>     wpa-debug-level 2
>>>>     wpa-ssid POTATONET
>>>>     wpa-psk XXXXXXXXX
>>>>     pre-up iw dev wlan0 set 4addr on
>>>>     pre-up iw dev wlan0 set power_save off
>>>>
>>>> allow-auto br0
>>>> # iface br0 inet dhcp
>>>> iface br0 inet manual
>>>>     # bridge_ports wlan0
>>>>     bridge_ports none
>>>>     bridge_stp off
>>>>     bridge_waitport 0
>>>>     bridge_fd 0
>>>>     # wpa-iface wlan0
>>>>     # wpa-bridge br0
>>>>
>>>>
>>>> I bring up wlan0 and br0:
>>>>
>>>> sudo ifup wlan0
>>>> sudo ifup br0
>>>>
>>>> At this point, the wlan0 port should be associated to the AP, even 
>>>> though I don't have any layer 3 interfaces on the PC yet. If I 
>>>> force a re-authentication from the AP it works fine. WPA rekey 
>>>> works fine.
>>>>
>>>> I do this to bridge up the interfaces:
>>>>     sudo brctl addif br0 eth0
>>>>     sudo brctl addif br0 wlan0
>>>>
>>>> From this point on, wpa_supplicant stops working correctly. 
>>>> However, the bridge works and ethernet frames are being passed 
>>>> between the laptop off of PC port eth0 and the OpenWRT AP. 
>>>> Everything is fine until the WPA rekey happens and then the wlan0 
>>>> interface goes down and stops working.
>>>>
>>>> I did a tcpdump to find out what was going on and discovered that 
>>>> once the AP asked for re-authentication from the client, no traffic 
>>>> was going out of the wlan0 interface on the client PC. This was 
>>>> supported by ifconfig TX counters. wpa_supplicant stops replying to 
>>>> the AP on the wlan0 interface.
>>>>
>>>> It should be noted at this point that I am aware wpa_supplicant is 
>>>> supposed to need the "-b" argument in this kind of setup, which is 
>>>> what the commented-out "wpa-bridge" parameter in the "interfaces" 
>>>> file above is for, but it didn't work. I verified the arguments 
>>>> given to wpa_supplicant were correct via ps:
>>>>
>>>> /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i 
>>>> wlan0 -b br0 -D nl80211,wext -C /run/wpa_supplicant
>>>>
>>>>
>>>>
>>>> Additional notes and observations:
>>>>
>>>> Just to be clear, I have inspected the macaddr and arp tables on 
>>>> both the OpenWRT AP and the laptop and the MACs are correct. The 
>>>> wireless bridging is definitely working as expected. Let me know if 
>>>> you want output from these commands, but I don't think they are 
>>>> relevant.
>>>>
>>>> The default WPA rekey timer is every 10 minutes on OpenWRT, but I 
>>>> can force the AP to re-authenticate the client by doing this:
>>>> ubus call hostapd.wlan0 del_client '{"addr":"34:de:1a:zz:zz:zz", 
>>>> "reason":1, "deauth":true, "ban_time":0}'
>>>>
>>>>
>>>>
>>>> Finally, here is some debugging output (wpa_supplicant -ddd) from 
>>>> the client PC during a failed re-auth with the AP.
>>>>
>>>> http://jmomo.net/files/wpa_probs.txt
>>>>
>>>>
>>>>
>>>> What do?
>>>>
>>>> If additional debugging is needed, let me know what to do. If this 
>>>> is a Debian package problem, let me know and I'll go open a bug there.
>>>>
>>>> -- 
>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>> linux-wireless" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-wireless" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: wpa_supplicant bridging problems

[J Mo]

This was a bug already fixed in git. The Debian wpa_supplicant is old 
(2.3). Source right now is pre-2.6. I compiled my own and it works fine.

The wpa_supplicant README file doesn't do a good job of listing 
requirements. These are the packages I needed to install on my Debian 
host to get it compiled. Also had to remove CONFIG_PCSC=y.

sudo apt-get install libnl-3-dev libnl-genl-3-dev libdbus-1-dev 
libdbus-glib-1-dev libglib2.0-bin libglib2.0-dev libpcre16-3 
libpcre3-dev libpcre32-3 libpcrecpp0v5 pkg-config libreadline-dev 
libreadline6-dev

I will open a bug with Debian and get them to upgrade their packages.

I suspect this was fixed in git commit 
e6dd8196e5daf39e4204ef8ecd26dd50fdca6040, but there are two other 
commits which also look like they are related to bridging and EAPOL.

Thanks to those who offered advice.



On 2/17/16 22:43, J Mo wrote:
>
> I just did a frame dump from my OpenWRT device to look at what was 
> going on at the 802.11 level.
>
> To be honest, I barely know what I'm doing.
>
> I took a good capture where 4-address frames were off on the client 
> and then one where 4-address frames were on and the wlan0 interface 
> was on the bridge.
>
> I'm looking at both captures here in Wireshark and I see the probes, 
> the initial authentication and association request/replies.
>
> Then the EAPOL process is supposed to occur, and I see that go down 
> okay in the successful capture.
>
> But in the bad capture, there is no reply from the client. The AP 
> sends out message 1 of 4 in the EAPOL negotiation and the station 
> never responds.
>
> But there are two things in the failed negotiation that I've noticed.
>
> The first is that in the bad/fail capture there is a weird null-data 
> frame sent from the station to the AP. I'm not sure what this is all 
> about. The only thing I know about these frames is that they can be 
> used for power management notifications (hey AP, I'm going to sleep 
> until further notice). I don't see any PM flags in this frame. 
> However, I notice that it's flags are 0x03 (00000011). Is this a 
> notification that the client wants to do WDS? Because that's what the 
> docs here I'm reading online says those flags are used for:
>
> https://www.safaribooksonline.com/library/view/80211-wireless-networks/0596100523/ch04.html 
>
> See Table 4-2. Use of the address fields in data frames
>
> And then I look at the EAPOL frame the OpenWRT host sends to my 
> station after the null-data frame. It's the first EAPOL frame in the 
> negotiation process and it's flags are 0x02 (00000010). Isn't that 
> supposed to be 11?
>
> I think OpenWRT might be broken here. I'm going to check with people 
> over there and see what they have to say about this. It may be that 
> the wpa_supplicant on the station is ignoring the EAPOL frames because 
> this flag is wrong. But like I said, I don't know WTF I'm doing.
>
> Captures available on request if anyone wants to look.
>
>
>
> On 2/17/16 20:16, J Mo wrote:
>>
>> I decided to grab another 802.11 adapter and test with it. This time 
>> a rtl8192cu (ALFA AWUS036NHR). Same behavior. No change.
>>
>> Here is what happens when I run the Debian ifup script in verbose mode:
>>
>> user@host-->sudo ifup -v br0
>> Configuring interface br0=br0 (inet)
>> iw dev wlan0 set 4addr on
>> iw dev wlan0 set power_save off
>> /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
>> run-parts: executing /etc/network/if-pre-up.d/bridge
>>
>> Waiting for a max of 5 seconds for wlan0 to become available.
>>
>> Waiting for br0 to get ready (MAXWAIT is 2 seconds).
>> run-parts: executing /etc/network/if-pre-up.d/ethtool
>> run-parts: executing /etc/network/if-pre-up.d/vlan
>> run-parts: executing /etc/network/if-pre-up.d/wireless-tools
>> run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
>> wpa_supplicant: wpa-bridge br0
>> wpa_supplicant: wpa-driver nl80211,wext (default)
>> wpa_supplicant: /sbin/wpa_supplicant -s -B -P 
>> /run/wpa_supplicant.wlan0.pid -i wlan0 -b br0 -D nl80211,wext -C 
>> /run/wpa_supplicant
>> Starting /sbin/wpa_supplicant...
>> wpa_supplicant: creating sendsigs omission pidfile: 
>> /run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid
>> wpa_supplicant: ctrl_interface socket located at 
>> /run/wpa_supplicant/wlan0
>> wpa_supplicant: configuring network block -- 0
>> wpa_supplicant: wpa-ssid "POTATONET" -- OK
>> wpa_supplicant: wpa-psk ***** -- OK
>> wpa_supplicant: enabling network block 0 -- OK
>> /bin/ip addr add 192.168.130.251/255.255.255.0 broadcast 
>> 192.168.130.255       dev br0 label br0
>> /bin/ip link set dev br0   up
>>
>> /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
>> run-parts: executing /etc/network/if-up.d/000resolvconf
>> run-parts: executing /etc/network/if-up.d/arping
>> run-parts: executing /etc/network/if-up.d/avahi-autoipd
>> run-parts: executing /etc/network/if-up.d/clamav-freshclam-ifupdown
>> run-parts: executing /etc/network/if-up.d/ethtool
>> run-parts: executing /etc/network/if-up.d/ip
>> run-parts: executing /etc/network/if-up.d/mountnfs
>> run-parts: executing /etc/network/if-up.d/openssh-server
>> run-parts: executing /etc/network/if-up.d/upstart
>> run-parts: executing /etc/network/if-up.d/wpasupplicant
>>
>>
>>
>> It is notable that if I remove the "pre-up iw dev wlan0 set 4addr on" 
>> parameter from the interfaces config file under br0, I get this error 
>> when attempting to bring the interface up:
>>
>> Waiting for a max of 0 seconds for wlan0 to become available.
>> can't add wlan0 to bridge br0: Operation not supported
>>
>> So that's the point where the wlan0 interface gets bridged onto br0. 
>> This indicates that the bridge is definitely exists and wlan0 is a 
>> member prior to wpa_supplicant being invoked.
>>
>>
>>
>> On 2/17/16 02:05, J Mo wrote:
>>>
>>> I will go look and verify the order of operations for the Debian 
>>> networking system, but I am under the impression that it brings up 
>>> the wlan interface (via bridge_ports), does all bridging, and then 
>>> processes the wpa-* commands.
>>>
>>> In other words, it's already doing what you suggested.
>>>
>>> Also, wpa_supplicant gives errors if either the 802.11 interface (-i 
>>> wlan0) or bridge interface (-b br0) wasn't up at the time it was 
>>> launched, so I don't think it's even possible to get the order wrong 
>>> without obvious signs. I just don't think that's the issue here.
>>>
>>> Still, I'll take your advice and double check. I think I can debug 
>>> the ifup/down scripts a little more than what I've already done, but 
>>> I don't think order of operation is an issue.
>>>
>>> One thing to note is that if I bridge the wlan0 interface and let an 
>>> AP-reauth fail and then take the bridge off, wpa_supplicant starts 
>>> working again. Put the bridge back on and it breaks again, etc. I 
>>> can do this live with brctl without restarting wpa_supplicant and it 
>>> will start and stop working.
>>>
>>> I don't even understand why wpa_supplicant needs to know about the 
>>> bridge in this situation, but whatever!
>>>
>>> FYI By "official method", I mean the ideal config setup with an 
>>> "interfaces" config like this:
>>>
>>> allow-auto wlan0
>>> iface wlan0 inet manual
>>>
>>> allow-auto br0
>>> iface br0 inet dhcp
>>>     bridge_ports wlan0
>>>     bridge_stp off
>>>     bridge_waitport 5
>>>     bridge_fd 0
>>>     wpa-ssid POTATONET
>>>     wpa-psk xxxxxxx
>>>     wpa-iface wlan0
>>>     wpa-bridge br0
>>>     pre-up iw dev wlan0 set 4addr on
>>>     pre-up iw dev wlan0 set power_save off
>>>
>>>
>>>
>>> On 2/17/16 00:49, Simon Malthieu wrote:
>>>> Hi,
>>>>
>>>> Have you tried to add wlan0 to the bridge **before**
>>>> wpa_supplicant (with the -b option) is launched ?
>>>>
>>>> wpa_supplicant opens a socket to listen to EAPOL frames
>>>> in the bridge, and it does not seem to work if the interface
>>>> is not in the bridge at start.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>>
>>>> On 17/02/2016 04:30, J Mo wrote:
>>>>>
>>>>> Hello everyone
>>>>>
>>>>> I am having a very difficult time with a wireless bridging problem.
>>>>>
>>>>> My objective is to use a Debian GNU/Linux host as a wireless 
>>>>> ethernet bridge between itself, some hosts connected through a 
>>>>> switch on it's eth0 port, and an OpenWRT router.
>>>>>
>>>>> I have a test setup consisting of a laptop, a small PC (802.11 
>>>>> client), and the OpenWRT AP/router.
>>>>>
>>>>> The wifi client system is an amd64(intel) with one 802.11 
>>>>> interface and a 1000BASE-T interface. The 802.11 hardware here is 
>>>>> an Intel 3160. The OS is Debian GNU/Linux unstable with kernel 
>>>>> 4.3.0-1-amd64 and wpasupplicant package version 2.3-2.3.
>>>>>
>>>>> The 802.11 AP is a TP-Link TL-WR710N which is based off the 
>>>>> Atheros ar9331.
>>>>>
>>>>>
>>>>>
>>>>> My problem is the moment I bridge the wlan0 interface on the 
>>>>> 802.11 PC client, wpa_supplicant stops doing it's job. It stops 
>>>>> responding to any EAPOL frames from the AP, even though it seems 
>>>>> to be receiving them.
>>>>>
>>>>> It is noteworthy that the bridging works. I am able to get a DHCP 
>>>>> lease on the laptop from the OpenWRT AP/router via bridging though 
>>>>> the PC. Traffic passes both way and everything works great until 
>>>>> the next WPA rekey event comes along (every 10 minutes by default 
>>>>> for OpenWRT), and then the client gets deauth'ed from the AP 
>>>>> because it fails to respond.
>>>>>
>>>>> The only way I can get this to work is to first bring up my wlan0 
>>>>> interface on the PC so that wpa_supplicant authenticates itself 
>>>>> correctly. Once the 802.11 layer 2 is up, I manually use brctl to 
>>>>> bridge in the eth0 and wlan0 ports on the PC. Everything works 
>>>>> fine until the AP wants to rekey or the client needs to re-auth 
>>>>> for some reason.
>>>>>
>>>>>
>>>>>
>>>>> Here is what my setup looks like:
>>>>>
>>>>> The OpenWRT device setup is pretty standard. The only thing 
>>>>> required for the bridging is the addition of the "option wds 1" 
>>>>> parameter under the wifi-iface in the "wireless" config file. The 
>>>>> wds parameter enables 4-address frames to allow the bridging. In 
>>>>> case it's relevant, I'm doing WPA2 PSK AES/CCMP.
>>>>>
>>>>> My PC/client /etc/network/interfaces file looks kind of like this:
>>>>>
>>>>> allow-hotplug eth0
>>>>> iface eth0 inet manual
>>>>>
>>>>> auto wlan0
>>>>> iface wlan0 inet manual
>>>>>     wpa-debug-level 2
>>>>>     wpa-ssid POTATONET
>>>>>     wpa-psk XXXXXXXXX
>>>>>     pre-up iw dev wlan0 set 4addr on
>>>>>     pre-up iw dev wlan0 set power_save off
>>>>>
>>>>> allow-auto br0
>>>>> # iface br0 inet dhcp
>>>>> iface br0 inet manual
>>>>>     # bridge_ports wlan0
>>>>>     bridge_ports none
>>>>>     bridge_stp off
>>>>>     bridge_waitport 0
>>>>>     bridge_fd 0
>>>>>     # wpa-iface wlan0
>>>>>     # wpa-bridge br0
>>>>>
>>>>>
>>>>> I bring up wlan0 and br0:
>>>>>
>>>>> sudo ifup wlan0
>>>>> sudo ifup br0
>>>>>
>>>>> At this point, the wlan0 port should be associated to the AP, even 
>>>>> though I don't have any layer 3 interfaces on the PC yet. If I 
>>>>> force a re-authentication from the AP it works fine. WPA rekey 
>>>>> works fine.
>>>>>
>>>>> I do this to bridge up the interfaces:
>>>>>     sudo brctl addif br0 eth0
>>>>>     sudo brctl addif br0 wlan0
>>>>>
>>>>> From this point on, wpa_supplicant stops working correctly. 
>>>>> However, the bridge works and ethernet frames are being passed 
>>>>> between the laptop off of PC port eth0 and the OpenWRT AP. 
>>>>> Everything is fine until the WPA rekey happens and then the wlan0 
>>>>> interface goes down and stops working.
>>>>>
>>>>> I did a tcpdump to find out what was going on and discovered that 
>>>>> once the AP asked for re-authentication from the client, no 
>>>>> traffic was going out of the wlan0 interface on the client PC. 
>>>>> This was supported by ifconfig TX counters. wpa_supplicant stops 
>>>>> replying to the AP on the wlan0 interface.
>>>>>
>>>>> It should be noted at this point that I am aware wpa_supplicant is 
>>>>> supposed to need the "-b" argument in this kind of setup, which is 
>>>>> what the commented-out "wpa-bridge" parameter in the "interfaces" 
>>>>> file above is for, but it didn't work. I verified the arguments 
>>>>> given to wpa_supplicant were correct via ps:
>>>>>
>>>>> /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i 
>>>>> wlan0 -b br0 -D nl80211,wext -C /run/wpa_supplicant
>>>>>
>>>>>
>>>>>
>>>>> Additional notes and observations:
>>>>>
>>>>> Just to be clear, I have inspected the macaddr and arp tables on 
>>>>> both the OpenWRT AP and the laptop and the MACs are correct. The 
>>>>> wireless bridging is definitely working as expected. Let me know 
>>>>> if you want output from these commands, but I don't think they are 
>>>>> relevant.
>>>>>
>>>>> The default WPA rekey timer is every 10 minutes on OpenWRT, but I 
>>>>> can force the AP to re-authenticate the client by doing this:
>>>>> ubus call hostapd.wlan0 del_client '{"addr":"34:de:1a:zz:zz:zz", 
>>>>> "reason":1, "deauth":true, "ban_time":0}'
>>>>>
>>>>>
>>>>>
>>>>> Finally, here is some debugging output (wpa_supplicant -ddd) from 
>>>>> the client PC during a failed re-auth with the AP.
>>>>>
>>>>> http://jmomo.net/files/wpa_probs.txt
>>>>>
>>>>>
>>>>>
>>>>> What do?
>>>>>
>>>>> If additional debugging is needed, let me know what to do. If this 
>>>>> is a Debian package problem, let me know and I'll go open a bug 
>>>>> there.
>>>>>
>>>>> -- 
>>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>>> linux-wireless" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>> -- 
>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>> linux-wireless" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-wireless" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wpa_supplicant bridging problems

[Jouni Malinen]

On Thu, Feb 18, 2016 at 07:55:30PM -0800, J Mo wrote:
> This was a bug already fixed in git. The Debian wpa_supplicant is
> old (2.3). Source right now is pre-2.6. I compiled my own and it
> works fine.

> I suspect this was fixed in git commit
> e6dd8196e5daf39e4204ef8ecd26dd50fdca6040, but there are two other
> commits which also look like they are related to bridging and EAPOL.

That is not really a fix for the real problem.. It is only a workaround
to avoid the quite unfortunate and already years old kernel regression..
While that workaround covers some cases, it has a cost (more CPU use)
and it is possible to come up with sequences that break even that
workaround. Unfortunately, I'm not aware of any robust way of working
around this from user space without significant CPU load increase.

This thread from 2013 discusses that root issue:
http://marc.info/?l=linux-wireless&m=136743495526905&w=2

Unfortunately, there is still no fix for this in the kernel.. There is a
proposed fix that is included in OpenWrt, but it is unclear how this
issue could be fixed properly.

-- 
Jouni Malinen                                            PGP id EFC895FA