Ajay,
I'm just starting to investigate an issue with the wilc1000 driver that occurs
when it is operating as an access point. I came across this thread:
https://lore.kernel.org/linux-wireless/[email protected]/
and was wondering if there has been progress towards converting the driver to
use the nl80211-based TX/RX interface. If so, is this something that's
available somewhere or could be shared?
Thanks and best regards,
--david
Hi David,
On 4/11/23 14:08, David Mosberger-Tang wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Ajay,
>
> I'm just starting to investigate an issue with the wilc1000 driver that occurs
> when it is operating as an access point. I came across this thread:
What is the issue observed with the AP mode.
>
> https://lore.kernel.org/linux-wireless/[email protected]/
>
> and was wondering if there has been progress towards converting the driver to
> use the nl80211-based TX/RX interface. If so, is this something that's
> available somewhere or could be shared?
>
I haven't started working on this part yet. After completing few pending
ongoing patches. I will look into this.
Regards,
Ajay
On Wed, 2023-04-12 at 00:33 +0000, [email protected] wrote:
> Hi David,
>
> On 4/11/23 14:08, David Mosberger-Tang wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > Ajay,
> >
> > I'm just starting to investigate an issue with the wilc1000 driver that occurs
> > when it is operating as an access point. I came across this thread:
>
> What is the issue observed with the AP mode.
I'm still working on simplifying the test case. Right now, it's rather
complex:
1) Connect wlan0 in managed mode to an existing access point.
2) Create a virtual interface wlan0 (iw dev wlan0ap interface add
wlan0ap type __ap)
3) Set up a captive portal on wlan0ap (iptables rules, web server,
dnsmasq)
3) Start hostapd on wlan0ap
Once that's done, use a smartphone or any other client device to
connect to the captive portal's SSID. The captive portal redirects any
HTTP requests to the portal's web server.
Now, when the client starts downloading pages from the web server,
something bad happens in the wilc1000. The connections to the web
server get stuck and wilc1000 stops broadcasting the hostapd's SSID.
There are no error message (even with debug enabled in wilc1000).
Depending on the client device, the problems appears sooner or later.
For example, with Android 13, the problem happens infrequently but
with iOS or Android 9, it happens rather reliably and early on (within
the first few KiB of data transmission).
> >
> > https://lore.kernel.org/linux-wireless/[email protected]/
> >
> > and was wondering if there has been progress towards converting the driver to
> > use the nl80211-based TX/RX interface. If so, is this something that's
> > available somewhere or could be shared?
> >
>
> I haven't started working on this part yet. After completing few pending
> ongoing patches. I will look into this.
Great!
Best regards,
--david
Ajay,
OK, here is a simpler test case:
- Setup wlan0 to connect to an existing access point.
In my case, wlan0 ends up with IP address 172.17.2.230.
- Start hostapd on wlan0tst with these commands:
---
cat > hostapd-wlan0tst.conf <<EOF
interface=wlan0tst
hw_mode=g
channel=6
ieee80211n=1
wmm_enabled=1
ssid=WLAN0TST
wpa=2
wpa_passphrase=SOME_PASSWORD
EOF
iw dev wlan0 interface add wlan0tst type __ap
ip link set dev wlan0tst address 12:34:56:78:9a:bc
ip addr add 10.234.193.42/24 dev wlan0tst
hostapd hostapd-wlan0tst.conf
---
- Connect another computer to WLAN0TST
When I try the above, usually WLAN0TST works fine but as soon as it starts up,
pings to 172.17.2.230 stop. Sometimes, WLAN0TST starts up fine, but after a few
seconds, the client's connection gets shut down and WLAN0TST stops
working (or even being advertised). When that happens, pings to 172.17.2.230
start working again.
I don't think the issue is really AP-mode specific though. I also see issues
when trying to create a virtual interface that connects to another access point:
- Setup wlan0 to connect to an existing access point.
- Start a second connection to another access point:
---
iw dev wlan0 interface add wlan0tst type managed
ip link set dev wlan0tst address 12:34:56:78:9a:bc
ip addr add 10.0.0.88/24 dev wlan0tst
wpa_supplicant -s -B -Dnl80211 -i wlan0tst -c /home/eguser/wlan0tst.conf
---
In this case, too, traffic on wlan0 and WLAN0TST seem to affect each other.
Interestingly, in this case, I can bring back the non-working connection by
issuing a "wpa_cli reassociate" command. This will bring back the non-working
connection, but break the one that had been working fine before (to bring back
the WLAN0TST connection, you'd have to use "wpa_cli -p /var/run/wpa_supplicant-
wlan0tst reassociate").
--david
Hi David,
On 4/12/23 12:47, David Mosberger-Tang wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Ajay,
>
> OK, here is a simpler test case:
>
> - Setup wlan0 to connect to an existing access point.
> In my case, wlan0 ends up with IP address 172.17.2.230.
>
> - Start hostapd on wlan0tst with these commands:
>
> ---
> cat > hostapd-wlan0tst.conf <<EOF
> interface=wlan0tst
> hw_mode=g
> channel=6
> ieee80211n=1
> wmm_enabled=1
> ssid=WLAN0TST
> wpa=2
> wpa_passphrase=SOME_PASSWORD
> EOF
> iw dev wlan0 interface add wlan0tst type __ap
> ip link set dev wlan0tst address 12:34:56:78:9a:bc
> ip addr add 10.234.193.42/24 dev wlan0tst
> hostapd hostapd-wlan0tst.conf
> ---
>
> - Connect another computer to WLAN0TST
>
> When I try the above, usually WLAN0TST works fine but as soon as it starts up,
> pings to 172.17.2.230 stop. Sometimes, WLAN0TST starts up fine, but after a few
> seconds, the client's connection gets shut down and WLAN0TST stops
> working (or even being advertised). When that happens, pings to 172.17.2.230
> start working again.
>
> I don't think the issue is really AP-mode specific though. I also see issues
> when trying to create a virtual interface that connects to another access point:
In wilc1000, the concurrent mode is only supported on a single channel.
I suspect the STA and AP are started on different channels. Because of
that, the existing interface is getting affected when other interface is
started.
Once the station is connected to AP on wlan0 interface, try using the
same channel number to run hostapd on wlan0tst interface.
>
> - Setup wlan0 to connect to an existing access point.
> - Start a second connection to another access point:
>
> ---
> iw dev wlan0 interface add wlan0tst type managed
> ip link set dev wlan0tst address 12:34:56:78:9a:bc
> ip addr add 10.0.0.88/24 dev wlan0tst
> wpa_supplicant -s -B -Dnl80211 -i wlan0tst -c /home/eguser/wlan0tst.conf
> ---
>
> In this case, too, traffic on wlan0 and WLAN0TST seem to affect each other.
>
> Interestingly, in this case, I can bring back the non-working connection by
> issuing a "wpa_cli reassociate" command. This will bring back the non-working
> connection, but break the one that had been working fine before (to bring back
> the WLAN0TST connection, you'd have to use "wpa_cli -p /var/run/wpa_supplicant-
> wlan0tst reassociate").
Same as above, for STA+STA concurrent mode, please check with if both
AP's are on same channel.
Regards,
Ajay
On Wed, 2023-04-12 at 21:10 +0000, [email protected] wrote:
> Hi David,
>
> On 4/12/23 12:47, David Mosberger-Tang wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > Ajay,
> >
> > OK, here is a simpler test case:
> >
> > - Setup wlan0 to connect to an existing access point.
> > In my case, wlan0 ends up with IP address 172.17.2.230.
> >
> > - Start hostapd on wlan0tst with these commands:
> >
> > ---
> > cat > hostapd-wlan0tst.conf <<EOF
> > interface=wlan0tst
> > hw_mode=g
> > channel=6
> > ieee80211n=1
> > wmm_enabled=1
> > ssid=WLAN0TST
> > wpa=2
> > wpa_passphrase=SOME_PASSWORD
> > EOF
> > iw dev wlan0 interface add wlan0tst type __ap
> > ip link set dev wlan0tst address 12:34:56:78:9a:bc
> > ip addr add 10.234.193.42/24 dev wlan0tst
> > hostapd hostapd-wlan0tst.conf
> > ---
> >
> > - Connect another computer to WLAN0TST
> >
> > When I try the above, usually WLAN0TST works fine but as soon as it starts up,
> > pings to 172.17.2.230 stop. Sometimes, WLAN0TST starts up fine, but after a few
> > seconds, the client's connection gets shut down and WLAN0TST stops
> > working (or even being advertised). When that happens, pings to 172.17.2.230
> > start working again.
> >
> > I don't think the issue is really AP-mode specific though. I also see issues
> > when trying to create a virtual interface that connects to another access point:
>
> In wilc1000, the concurrent mode is only supported on a single channel.
Ahh, now that makes sense. I take it that's a physical limitation?
> I suspect the STA and AP are started on different channels. Because of
> that, the existing interface is getting affected when other interface is
> started.
Yep. I wasn't really paying too much attention to the channels as I
was assuming they could be separate for distinct virtual interfaces
and, at first blush, it did look like it was working fine.
> Once the station is connected to AP on wlan0 interface, try using the
> same channel number to run hostapd on wlan0tst interface.
Confirmed. I just tried that and was able to successfully connect with
Android 13, Android 9, and iOS devices without problem!
I guess I'll have to use hostapd_cli chan_switch to ensure the AP
channel stays in sync with the station's channel and hope that any
clients connected to the AP will update seamlessly if and when the
channel switches.
Would it be difficult to output an error when two virtual interfaces
are configured for different channel numbers?
In any case, thanks for your help - much appreciated!
--david
>