We are developing small internet connected device that connects via wifi and does some work. It is controlled via mobile app.
For configuration purposes we use wi-fi module that can work in both STA + AP modes simultaneously via two interfaces wlan0 and wlan1. One of the interfaces works in Master mode. Phone connects to the device via wlan1 and sends command for the device to connect to another network and waits for result. Device in turn connects to another wi-fi network using wlan0 and notifies the phone if connection was successful or not.
But there is one issue. Both interfaces (wlan0 and wlan1) must work on the same channel as we have single hardware module. This causes channel of wlan1 to change in order to match of channel for wlan0.
Here comes the problem. When channel changes phone looses connection with the device. Is there a way to change wi-fi channel but keep connection between the device and mobile phone?
Our wi-fi module is rtl8723bu.
Linux 3.4.103.
Wifi daemons: hostapd v0.8.x_rtw_r7475.20130812_beta, wpa_supplicant v2.3.
UPDATE
Here is more clearly description what is going on on device.
Let's assume that the phone already connected to Device wlan1 interface with essid DeviceAp which is on channel 1. We have a Router with essid RouterAp which is on channel 6. Device interface wlan0 is not configured and not running.
(Step1 on image below).
Then the phone sends a request to the device to connect to RouterAp.
(Step2 on image below).
When wlan0 starts connecting to RouterAp it changes working channel. Because WiFi module can work only on one channel. The channel of wlan1 also changes (maybe in hard way). Therefore Phone lost DeviceAp and starts roaming.
(Step3 on image below).
SO the update question is:
Is there a way to tell the Phone (or other device) about network change? Or perhaps increase the likelihood that the phone is connected back to DeviceAP.
This behavior is very similar to the process of setting up Google Chromecast.
Chromecast also has two wireless interfaces and change the channel, but the Phone does not lose connection with it.
Image:
http://postimg.org/image/soh78vd17/
Related
I'm very unfamiliar with Linux so forgive me if this has been answered before, I've read quite a few answers but I'm never sure if they actually relate to my question.
I have a headless raspberry pi that connects to my phone's bluetooth automatically, my phone shares its internet access by tethering. I use this initial and reliable connection to SSH to my raspberry pi, and use the desktop with VNC viewer.
I would like to connect to a WiFi network that uses a captive portal, but the browser always uses the bluetooth connection so it never redirects me to the portal page. The bluetooth connection is just to be able to use the desktop so I can get through the portal, then I would like to either disconnect bluetooth or just not use it, mainly because of the low bandwidth it provides.
I've added wlan0 as a priority interface with ifmetric, but that hasn't worked.
I was thinking that forcing all HTTP connections through the wlan0 interface could solve the problem, but there may be a simpler way, feel free to tell me.
Can you explain in "simple" terms the best way to achieve this ?
Of course, there are multiple solutions. The simplest is making sure that there is only one correct default route.
There are 3 situations:
You are only connected via bluetooth via ssh
You are connected via bluetooth and via wifi, but not yet through the splash
You are through the splash
Each will require a different network configuration.
In 1, your network config will probably be:
some IP address (let's call it IP-bt) and network mask
Default gateway is your phone
With route -n you can verify this.
In 2, the network config will depend a bit on the wifi network, but in general, your network config will be:
you'll still have IP-bt
you will have a new address on the wifi adapter (which we call IP-wifi)
the default gateway should be the gateway on the wifi network.
When you verify this with route -n, you might still see a route with destination 0.0.0.0 towards your phone. You can delete this route. Your phone should be on a directly connected network and your ssh session should therefore not break.
If the default gw is not on the wifi network, you can still remove the route that sets your phone as default gw.
Under 3, the default gw must be on the wifi network, and not on the phone. You will still be able to use your phone, because it is directly connected.
Something to watch out for in this scenario is that your phone will act as a DHCP server. That means once in a while your DHCP lease will refresh, and the bluetooth default route may re-appear. Disconnecting bluetooth will prevent this.
The second solution is to use ifmetric. Instead of making wlan0 a lower metric, make your bluetooth a higher metric. Again verify with route -n that the metrics are as you want them to be. Verify with a traceroute how the packets are moving.
A third, and most complex option would be to install Quagga and configure correct routing.
What is the difference between Jackdaw and KillerBee on ZigBee USB Stick, both seem to be sniffing packet, but Jackdaw can act as a network interface, and KillerBee is only used for pentest? As far as I understand it, you can't use either to connect to like a hub or Wireless router, but only to ZigBee based devices, which would be the IoT devices such as sensors or smart socket etc.
Thank you
I have 2 different wireless USB adapters: wlan0 and wlan1.
I have an access to 2 Wifi networks: NETWORK_FOO and NETWORK_BAR.
wlan0 connects to NETWORK_FOO. wlan1 connects to NETWORK_BAR.
I'd like to configure it as follows:
wlan0 automatically makes a connection to NETWORK_FOO and OS always chooses this network for web connection.
wlan1 automatically makes a connection to NETWORK_BAR but OS doesn't use this network.
wlan1 connection to NETWORK_BAR should be available for VM guest running on this machine.
How to do it?
(I know there's a bridge connection option, but don't know how to prevent OS from using NETWORK_BAR connection)
Add the rules in route table. By default windows will connect to internet using network adapter based on routing information. It is automatically generated information. You can change the routing information.
In order to provision my device on the user's home WiFi network, it will temporarily act as an Accesspoint in order to receive the WiFi network details from the client. As part of the setup process, I'd like to verify connection to the user's WiFi network without losing AP connection to the client in order to provide the connection attempt status (success or fail). It works if both AP & user's WiFi network are using the same channel, but I run into problems when the Accesspoint is configured to run on channel X, and the user's WiFi network is on channel Y. Should it be possible to verify network connectivity on another channel?
Here's the scenario where things aren't working:
I have two virtual interfaces, wlan_ap and wlan_sta. hostapd is configured to use wlan_ap on channel 7 in hostapd.conf. The client connects to my ap network, and through an exchange, my device is given the SSID and PW of the user's home wifi network. However, the user's home wifi network turns out to be on a completely different channel (e.g. 11). If I attempt to use my station interface to connect to the user's wifi network while maintaining connection with the client on my ap interface, this station test connection fails. Or if it somehow connects to the user's wifi network, the AP connection to the client drops. If both ap and user's home network happen to be the same channel, the test connection succeeds. Is there a way to test the connection when the channels differ?
My device is running Debian 7.8 (kernel 3.8.13) and my WiFi adapter is using the Atheros AR9271 chipset w/ ath9k_htc driver.
Any direction you can give, including telling me I'm doing everything wrong and how to do it right, is highly appreciated.
"hostapd.conf has channel=7 and client network is on 8" HUH?
The client selects which SSID to access, not the channel.
I want to clear of my basics before I Jump into more complicated matter of bluetooth. I have following basic question.
If there is two bluetooth devices(A phone and a bluetooth display). Is it that bluetooth connection is initiated only by the phone.
Suppose there would be lot of bluetooth communication happening from a phone to bluetooth display.Both devices can send messages to any other devices at any time. What is usual design approach of communication. Is it that the phone creates a Socket Connection to the bluetooth display through RFCOMM first time by sending a connect request to the Bluetooth device and this connection is maintained all the time or for every message the Socket connection is made and then socket is closed, after that again reopened and closed for next message.
If the connection is opened till the devices are in nearby range what are the consequences.
What is normal way of communication in case of phone and headset.
Can I get any reference so that i can get some knowledge about that.
1) In general, bluetooth connections can be initiated by either device. For example, with a phone and computer, you could start a connection from either side. With a phone and a display or headset, there may be no input interface on one device, so you would initiate connections from the phone. Devices can also auto-negotiate role switches such that they swap master/slave roles.
2) If you have continuous data to exchange, or require low latency, the connection would typically be left up. If you only have rare messages to exchange, tearing down the connection would save power because the devices are maintaining the connection synchronization by exchanging null packets.
3) You can't maintain a connection with devices out of range. If they can't communicate for some timeout period (on the order of seconds) then they lose sync and kill the connection.
4) Note that phone/headset are not using RFCOMM connections, rather the HSP (headset profile). Connections for isochronous voice data are inherently different than a sporadic data connection like RFCOMM.
5) A good way to see how "real" devices are communicating is to use tools like hcidump, as part of the linux blueZ stack. This lets you fully sniff the protocol messages that happen as you connect devices.