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
