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
