LinuxLists.cc - rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

2012-05-09 10:57:23

Subject: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

Hi,

I've bisected a problem with running rt3052-based APs on recent
OpenWRT down to this commit: 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63
"mac80211: manage AP netdev carrier state"

If I revert this commit (and also fix the max_power issue), AP-mode
works fine, but if I leave it in, association to the AP times out.

(The AP-side hostapd claims WPA authentication was successful, but
the client never connects)

(Note: I haven't gotten around to testing a non-rt28xx based AP yet,
so I'm only assuming this affects only rt28xx, maybe it does affect
other chipsets as well)

See also "rt28xx: Revert eccc068e8e84c8fe997115629925e0422a98e4de
which causes txpower to be stuck at 0" on the openwrt list:
http://www.spinics.net/lists/linux-wireless/msg89732.html

Cheers,

--
Tobias PGP: http://8ef7ddba.uguu.de

2012-05-11 23:39:14

by Tobias Diedrich

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

Johannes Berg wrote:
> On Wed, 2012-05-09 at 23:04 +0200, Tobias Diedrich wrote:
>
> > > PKG_REV:=1f0cc27eb98f7d1af9c64d0752238184cbdb9a24
>
> Ok.
>
> > When associating to the AP works (3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 reverted):
> > root@OpenWrt:/# ip monitor
> > dev eth0.1 lladdr 00:50:5b:04:05:7e REACHABLE
> > dev wlan0 lladdr a0:0b:ba:c6:9f:88 REACHABLE
>
> Ah, well, I wanted "ip monitor" (and maybe restrict to "ip monitor
> link") while you start/stop hostapd. Sorry for not being clear on that.
> Also could be useful to look at it with the tcpdump thing, which is very
> very strange.
>
> I wonder if things like broadcast addresses are only added upon
> netif_carrier_on() and that would reprogram filters and cause issues for
> rt2x00... For that we'd need to do some more debugging inside mac80211
> though.

BTW I'll resume debugging next week, I'm on vacation in warsaw since
yesterday.

Cheers,

--
Tobias PGP: http://8ef7ddba.uguu.de

2012-05-09 21:04:52

by Tobias Diedrich

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

Tobias Diedrich wrote:
> Johannes Berg wrote:
> > On Wed, 2012-05-09 at 12:57 +0200, Tobias Diedrich wrote:
> >
> > > I've bisected a problem with running rt3052-based APs on recent
> > > OpenWRT down to this commit: 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63
> > > "mac80211: manage AP netdev carrier state"
> > >
> > > If I revert this commit (and also fix the max_power issue), AP-mode
> > > works fine, but if I leave it in, association to the AP times out.
> > >
> > > (The AP-side hostapd claims WPA authentication was successful, but
> > > the client never connects)
> > >
> > > (Note: I haven't gotten around to testing a non-rt28xx based AP yet,
> > > so I'm only assuming this affects only rt28xx, maybe it does affect
> > > other chipsets as well)
> >
> > Works fine here, but I don't see how that patch could affect rt2x00
> > only.
> >
> > You're going to have to give us more details about the failure, like the
> > version of hostapd at least. The output of "ip monitor" would also be
> > helpful.
>
> The hostapd package Makefile says:
>
> PKG_NAME:=hostapd
> PKG_VERSION:=20120428
> PKG_RELEASE:=1
> PKG_REV:=1f0cc27eb98f7d1af9c64d0752238184cbdb9a24
>
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
> PKG_SOURCE_URL:=git://w1.fi/srv/git/hostap.git
>
> Can't look at ip output right now as I'm still at work and the
> AP is switched off.

root@OpenWrt:/# hostapd -v
hostapd v2.0-devel
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2012, Jouni Malinen <[email protected]> and contributors

When associating to the AP works (3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 reverted):
root@OpenWrt:/# ip monitor
dev eth0.1 lladdr 00:50:5b:04:05:7e REACHABLE
dev wlan0 lladdr a0:0b:ba:c6:9f:88 REACHABLE
root@OpenWrt:/# logread
[...]
Sep 8 15:44:52 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: authenticated
Sep 8 15:44:52 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: associated (aid 1)
Sep 8 15:44:52 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 WPA: pairwise key handshake completed (RSN)
[...]
[switching phone back to different working AP]
Sep 8 15:45:01 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: disassociated
Sep 8 15:45:02 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: deauthenticated due to inactivity
(timer)

When associating fails:
root@OpenWrt:/# ip monitor
dev eth0.1 lladdr 00:50:5b:04:05:7e REACHABLE
root@OpenWrt:/# logread
[...]
Sep 8 15:44:59 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: authenticated
Sep 8 15:44:59 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: associated (aid 1)
Sep 8 15:45:05 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: authenticated
Sep 8 15:45:05 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: associated (aid 1)
Sep 8 15:45:12 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: authenticated
Sep 8 15:45:12 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: associated (aid 1)
Sep 8 15:45:18 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: authenticated
Sep 8 15:45:18 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: associated (aid 1)
Sep 8 15:45:24 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: authenticated
Sep 8 15:45:24 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: associated (aid 1)
Sep 8 15:45:31 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: authenticated
Sep 8 15:45:31 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: associated (aid 1)
Sep 8 15:45:37 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: authenticated
Sep 8 15:45:37 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: associated (aid 1)
[...]
[switching phone back to different working AP]
Sep 8 15:47:40 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: disassociated
Sep 8 15:47:41 OpenWrt daemon.info hostapd: wlan0: STA
a0:0b:ba:c6:9f:88 IEEE 802.11: deauthenticated due to inactivity
(timer)
[...]

Aaand now I was trying to take traffic capture on the AP, but it
also works as long as the tcpdump is running.
Adding the monitor device by itself doesn't help, but actually
starting tcpdump does make it suddenly work (regardless of -p).

Also /usr/sbin/hostapd -dd /var/run/hostapd-phy0.conf seems to work,
while
hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
doesn't.

Some sort of subtle timing issue maybe?

--
Tobias PGP: http://8ef7ddba.uguu.de

2012-05-09 21:29:02

by Tobias Diedrich

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

Tobias Diedrich wrote:
> Tobias Diedrich wrote:
> > Johannes Berg wrote:
> > > On Wed, 2012-05-09 at 12:57 +0200, Tobias Diedrich wrote:
> > >
> > > > I've bisected a problem with running rt3052-based APs on recent
> > > > OpenWRT down to this commit: 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63
> > > > "mac80211: manage AP netdev carrier state"
> > > >
> > > > If I revert this commit (and also fix the max_power issue), AP-mode
> > > > works fine, but if I leave it in, association to the AP times out.

This seems to be the crucial hunk (and it conveniently ermoves a
check against NL80211_IFTYPE_AP), if I revert just this it works for
me:

Index: compat-wireless-2012-04-17/net/mac80211/iface.c
===================================================================
--- compat-wireless-2012-04-17.orig/net/mac80211/iface.c 2012-05-09 01:00:39.197975402 +0200
+++ compat-wireless-2012-04-17/net/mac80211/iface.c 2012-05-09 01:02:32.514918371 +0200
@@ -411,8 +407,7 @@
ieee80211_bss_info_change_notify(sdata, changed);

if (sdata->vif.type == NL80211_IFTYPE_STATION ||
- sdata->vif.type == NL80211_IFTYPE_ADHOC ||
- sdata->vif.type == NL80211_IFTYPE_AP)
+ sdata->vif.type == NL80211_IFTYPE_ADHOC)
netif_carrier_off(dev);
else
netif_carrier_on(dev);

--
Tobias PGP: http://8ef7ddba.uguu.de

2012-05-10 08:27:36

by Johannes Berg

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

On Thu, 2012-05-10 at 10:15 +0200, Johannes Berg wrote:
> On Wed, 2012-05-09 at 23:04 +0200, Tobias Diedrich wrote:
>
> > > PKG_REV:=1f0cc27eb98f7d1af9c64d0752238184cbdb9a24
>
> Ok.
>
> > When associating to the AP works (3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 reverted):
> > root@OpenWrt:/# ip monitor
> > dev eth0.1 lladdr 00:50:5b:04:05:7e REACHABLE
> > dev wlan0 lladdr a0:0b:ba:c6:9f:88 REACHABLE
>
> Ah, well, I wanted "ip monitor" (and maybe restrict to "ip monitor
> link") while you start/stop hostapd. Sorry for not being clear on that.
> Also could be useful to look at it with the tcpdump thing, which is very
> very strange.
>
> I wonder if things like broadcast addresses are only added upon
> netif_carrier_on() and that would reprogram filters and cause issues for
> rt2x00... For that we'd need to do some more debugging inside mac80211
> though.

I don't see anything like that happening upon netif_carrier_on(), the
only thing that really seems to happen is attaching and starting qdiscs,
which shouldn't make a difference across drivers...

Is this using compat-wireless? But then, so do I right now, against 3.1
base kernel.

johannes

2012-05-18 00:57:04

by Tobias Diedrich

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

Johannes Berg wrote:
> On Thu, 2012-05-10 at 10:15 +0200, Johannes Berg wrote:
> > On Wed, 2012-05-09 at 23:04 +0200, Tobias Diedrich wrote:
> >
> > > > PKG_REV:=1f0cc27eb98f7d1af9c64d0752238184cbdb9a24
> >
> > Ok.
> >
> > > When associating to the AP works (3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 reverted):
> > > root@OpenWrt:/# ip monitor
> > > dev eth0.1 lladdr 00:50:5b:04:05:7e REACHABLE
> > > dev wlan0 lladdr a0:0b:ba:c6:9f:88 REACHABLE
> >
> > Ah, well, I wanted "ip monitor" (and maybe restrict to "ip monitor
> > link") while you start/stop hostapd. Sorry for not being clear on that.
> > Also could be useful to look at it with the tcpdump thing, which is very
> > very strange.
> >
> > I wonder if things like broadcast addresses are only added upon
> > netif_carrier_on() and that would reprogram filters and cause issues for
> > rt2x00... For that we'd need to do some more debugging inside mac80211
> > though.
>
> I don't see anything like that happening upon netif_carrier_on(), the
> only thing that really seems to happen is attaching and starting qdiscs,
> which shouldn't make a difference across drivers...
>
> Is this using compat-wireless? But then, so do I right now, against 3.1
> base kernel.

It's with compat-wireless, as I wrote earlier. Against 3.3.6 base
kernel.

ip_monitor_link.ok.log
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UNKNOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DORMANT
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state DORMANT
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56
|Deleted nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56

ip_monitor_link.borked.log
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UNKNOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DORMANT
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DORMANT
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DORMANT
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DORMANT
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state DORMANT
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56
|Deleted nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
| link/ether 1c:af:f7:49:50:56
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UP
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
| link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
|nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master br-lan state DOWN
| link/ether 1c:af:f7:49:50:56

diff:
--- ip_monitor_link.ok.log 2012-05-18 02:52:03.150741127 +0200
+++ ip_monitor_link.borked.log 2012-05-18 02:39:05.846504038 +0200
@@ -2,6 +2,8 @@
link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
nn: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UNKNOWN
link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
+nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DORMANT
+ link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
@@ -10,13 +12,13 @@
link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 master br-lan state DOWN
link/ether 1c:af:f7:49:50:56
-nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state DOWN
+nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN
link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
-nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DOWN
+nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master br-lan state DOWN
link/ether 1c:af:f7:49:50:56
-nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DOWN
+nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DORMANT
link/ether 1c:af:f7:49:50:56
-nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DOWN
+nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DORMANT
link/ether 1c:af:f7:49:50:56
nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state DORMANT
link/ether 1c:af:f7:49:50:56
@@ -34,11 +36,9 @@
link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
nn: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
-nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
+nn: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UP
link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
-nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
- link/ether 1c:af:f7:49:50:56
-nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
- link/ether 1c:af:f7:49:50:56
-nn: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-lan state UP
+nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
+ link/ether 1c:af:f7:49:50:56 brd ff:ff:ff:ff:ff:ff
+nn: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master br-lan state DOWN
link/ether 1c:af:f7:49:50:56

--
Tobias PGP: http://8ef7ddba.uguu.de

2012-05-10 08:13:08

by Johannes Berg

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

On Wed, 2012-05-09 at 23:28 +0200, Tobias Diedrich wrote:

> This seems to be the crucial hunk (and it conveniently ermoves a
> check against NL80211_IFTYPE_AP), if I revert just this it works for
> me:
>
> Index: compat-wireless-2012-04-17/net/mac80211/iface.c
> ===================================================================
> --- compat-wireless-2012-04-17.orig/net/mac80211/iface.c 2012-05-09 01:00:39.197975402 +0200
> +++ compat-wireless-2012-04-17/net/mac80211/iface.c 2012-05-09 01:02:32.514918371 +0200
> @@ -411,8 +407,7 @@
> ieee80211_bss_info_change_notify(sdata, changed);
>
> if (sdata->vif.type == NL80211_IFTYPE_STATION ||
> - sdata->vif.type == NL80211_IFTYPE_ADHOC ||
> - sdata->vif.type == NL80211_IFTYPE_AP)
> + sdata->vif.type == NL80211_IFTYPE_ADHOC)
> netif_carrier_off(dev);

Well ... yeah, if you remove this change all the other changes don't
really do anything so that's not really surprising :)

johannes

2012-05-10 08:15:29

by Johannes Berg

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

On Wed, 2012-05-09 at 23:04 +0200, Tobias Diedrich wrote:

> > PKG_REV:=1f0cc27eb98f7d1af9c64d0752238184cbdb9a24

Ok.

> When associating to the AP works (3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 reverted):
> root@OpenWrt:/# ip monitor
> dev eth0.1 lladdr 00:50:5b:04:05:7e REACHABLE
> dev wlan0 lladdr a0:0b:ba:c6:9f:88 REACHABLE

Ah, well, I wanted "ip monitor" (and maybe restrict to "ip monitor
link") while you start/stop hostapd. Sorry for not being clear on that.
Also could be useful to look at it with the tcpdump thing, which is very
very strange.

I wonder if things like broadcast addresses are only added upon
netif_carrier_on() and that would reprogram filters and cause issues for
rt2x00... For that we'd need to do some more debugging inside mac80211
though.

johannes

2012-05-18 01:18:34

by Tobias Diedrich

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

2012-05-09 12:18:31

by Tobias Diedrich

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

Johannes Berg wrote:
> On Wed, 2012-05-09 at 12:57 +0200, Tobias Diedrich wrote:
>
> > I've bisected a problem with running rt3052-based APs on recent
> > OpenWRT down to this commit: 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63
> > "mac80211: manage AP netdev carrier state"
> >
> > If I revert this commit (and also fix the max_power issue), AP-mode
> > works fine, but if I leave it in, association to the AP times out.
> >
> > (The AP-side hostapd claims WPA authentication was successful, but
> > the client never connects)
> >
> > (Note: I haven't gotten around to testing a non-rt28xx based AP yet,
> > so I'm only assuming this affects only rt28xx, maybe it does affect
> > other chipsets as well)
>
> Works fine here, but I don't see how that patch could affect rt2x00
> only.
>
> You're going to have to give us more details about the failure, like the
> version of hostapd at least. The output of "ip monitor" would also be
> helpful.

The hostapd package Makefile says:

PKG_NAME:=hostapd
PKG_VERSION:=20120428
PKG_RELEASE:=1
PKG_REV:=1f0cc27eb98f7d1af9c64d0752238184cbdb9a24

PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=git://w1.fi/srv/git/hostap.git

Can't look at ip output right now as I'm still at work and the
AP is switched off.

--
Tobias PGP: http://8ef7ddba.uguu.de

2012-05-18 17:16:33

by Johannes Berg

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

[dropping openwrt list, it keeps bothering me that I should subscribe]

On Fri, 2012-05-18 at 03:18 +0200, Tobias Diedrich wrote:

> One more clue:
> I think this has to do with the order in which the OpenWRT wifi
> script does things:
>
> hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
> hostapd_ctrl=/var/run/hostapd-phy0/wlan0
> ifconfig wlan0
> ifconfig wlan0 down
> ifconfig wlan0 hw ether 1c:af:f7:49:50:56 up
> ifconfig wlan0 0.0.0.0
> ifconfig wlan0
> ifconfig br-lan
> ifconfig wlan0 0.0.0.0
> ifconfig wlan0 hw ether 1c:af:f7:49:50:56 up
> iw dev wlan0 set txpower fixed 2000

Wow, ok, setting the interface down while the AP is up really isn't a
valid use of it. I'm actually amazed that it ever works at all when you
do this. Either this should be done the other way around, or hostapd
needs to get some smarts about it. For example, with the start-AP
function transition, I'm not sure even *beacon* after you do this...

johannes

2012-05-19 07:54:17

by Tobias Diedrich

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

Johannes Berg wrote:
> [dropping openwrt list, it keeps bothering me that I should subscribe]
>
> On Fri, 2012-05-18 at 03:18 +0200, Tobias Diedrich wrote:
>
> > One more clue:
> > I think this has to do with the order in which the OpenWRT wifi
> > script does things:
> >
> > hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
> > hostapd_ctrl=/var/run/hostapd-phy0/wlan0
> > ifconfig wlan0
> > ifconfig wlan0 down
> > ifconfig wlan0 hw ether 1c:af:f7:49:50:56 up
> > ifconfig wlan0 0.0.0.0
> > ifconfig wlan0
> > ifconfig br-lan
> > ifconfig wlan0 0.0.0.0
> > ifconfig wlan0 hw ether 1c:af:f7:49:50:56 up
> > iw dev wlan0 set txpower fixed 2000
>
> Wow, ok, setting the interface down while the AP is up really isn't a
> valid use of it. I'm actually amazed that it ever works at all when you
> do this. Either this should be done the other way around, or hostapd
> needs to get some smarts about it. For example, with the start-AP
> function transition, I'm not sure even *beacon* after you do this...

I think the problem here is you can have multiple logical interfaces per phy
devices, so the init script has to start hostapd first and do setup
setup for the interfaces after that. And you can't change the mac
address as long as the interface is up. This naturally leads to
- start hostapd
- for each interface
- down the interface
- set mac address
- up the interface

Which seems to be exactly what the scripts are doing from what I can
see:

|hostapd -P /var/run/wifi-$phy.pid -B /var/run/hostapd-$phy.conf || {
| echo "Failed to start hostapd for $phy"
| return
|}
|sleep 2
|
|for vif in $vifs; do
| config_get mode "$vif" mode
| config_get ifname "$vif" ifname
| [ "$mode" = "ap" ] || continue
| hostapd_ctrl="${hostapd_ctrl:-/var/run/hostapd-$phy/$ifname}"
| mac80211_start_vif "$vif" "$ifname"
|done

mac80211_start_vif in turn calls start_net, which calls setup_interface, which
calls prepare_interface, which does the mac-address setup among other things.

|prepare_interface() {
[...]
| [ -n "$macaddr" ] && $DEBUG ifconfig "$iface" down
| $DEBUG ifconfig "$iface" ${macaddr:+hw ether "$macaddr"} ${mtu:+mtu $mtu} ${txqueuelen:+txqueuelen $txqueuelen} up
[...]

--
Tobias PGP: http://8ef7ddba.uguu.de

2012-05-09 11:59:42

by Johannes Berg

[permalink] [raw]

Subject: Re: rt28xx AP-mode problem with commit 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63 "mac80211: manage AP netdev carrier state"

On Wed, 2012-05-09 at 12:57 +0200, Tobias Diedrich wrote:

> I've bisected a problem with running rt3052-based APs on recent
> OpenWRT down to this commit: 3edaf3e61fda3aa9ff8d38445bf92f2bec23bf63
> "mac80211: manage AP netdev carrier state"
>
> If I revert this commit (and also fix the max_power issue), AP-mode
> works fine, but if I leave it in, association to the AP times out.
>
> (The AP-side hostapd claims WPA authentication was successful, but
> the client never connects)
>
> (Note: I haven't gotten around to testing a non-rt28xx based AP yet,
> so I'm only assuming this affects only rt28xx, maybe it does affect
> other chipsets as well)

Works fine here, but I don't see how that patch could affect rt2x00
only.

You're going to have to give us more details about the failure, like the
version of hostapd at least. The output of "ip monitor" would also be
helpful.

johannes