All of lore.kernel.org
 help / color / mirror / Atom feed
From: J Mo <jmomo@jmomo.net>
To: Simon Malthieu <simon.malthieu@luceor.com>,
	linux-wireless@vger.kernel.org
Subject: Re: wpa_supplicant bridging problems
Date: Wed, 17 Feb 2016 02:05:22 -0800	[thread overview]
Message-ID: <56C445E2.1050904@jmomo.net> (raw)
In-Reply-To: <56C4340D.9000508@luceor.com>


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


  reply	other threads:[~2016-02-17 10:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17  3:30 wpa_supplicant bridging problems J Mo
2016-02-17  8:49 ` Simon Malthieu
2016-02-17 10:05   ` J Mo [this message]
2016-02-18  4:16     ` J Mo
2016-02-18  6:43       ` J Mo
2016-02-19  3:55         ` J Mo
2016-02-19 19:39           ` Jouni Malinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56C445E2.1050904@jmomo.net \
    --to=jmomo@jmomo.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=simon.malthieu@luceor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.