When using Android's startDiscovery() method to discover Bluetooth devices one gets BOTH classic and Bluetooth Low Energy devices in the BroadcastReceiver action DEVICE_FOUND. The problem is that I cannot find a way to tell if the discovery came from a BTLE scan or a classic inquiry.
In many cases I can use the device type, but that doesn't work if the device is dual.
If it is dual, then in many cases I can look at the Device class. If the device class is not 7936 (unspecified), then I know it is a classic device. However, some classic devices are too lazy to put in a class value so it is reported as unspecified.
So now I am up against devices that are dual, responds to both inquiries and BTLE scans, and in the classic inquiry give unspecified. So I do not know if the action DEVICE_FOUND is from a BTLE device or a classic device. That means I cannot connect to the correct handler. If its an inquiry response and I try and connect BTLE, that will fail and vice versa.
The best solution in my opinion would be that Android allows one to specify that startDiscovery ONLY does inquiries (or BTLE scans) and not both.
In the absence of that, does anyone know how I could tell whether the discovery was from an inquiry or a BTLE advertisement WITHOUT trying to connect?
Related
I'm doing an embedded-system project now. From my view, AT commands can be sent to a device to retrieve 4G information, dial and so on. On the other hand, we can also do that by calling APIs provided by the 4G vendor.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
TL;DR
Vendor's API (not only C, but also C++, Java or Python depending to the vendor and the modem model) can both be wrappers for AT commands and a wider, more powerful set of API were the user can port complex applications.
It depends on the vendor and on the model.
A jungle of modems produced by different vendors
It is impossible to define a general "rule" about API provided by a Cellular Module (not necessarily a 4G module).
First of all every vendor usually implements standard AT Commands (both Hayes commands and extended standard commands for cellular devices). In the same way every vendor has it's own implementation of the user application area where the customers can store their own application to control the modem's functionalities and to use them according to their own application requirements.
AT commands remain the interface to be used when the modem needs to be connected (and driven) by an external host. When the user application area is used, instead, a wider set of API is usually provided. They may include:
A library exporting a subset of the OS capabilities (threads management, events, semaphores, mutexes, SW timers, FS access and so on)
A library offering the capability to manage the specific HW of the device (GPIOs, SPI, I2C, ADC, DAC and so on)
A library offering a programmatical way to perform action, related to connectivity, that would normally be executed through AT commands (registration status check, PIN code insertion, PDP context activation, SMS management, TCP/UDP/TLS sockets)
The latter usually access a base layer involving all the functionalities provided by the modem. Usually this is the same layer invoked by the AT commands sent through modem's serial interface.
Sending AT commands... from the vendor's API?
Of course it often happens that the library mentioned above provides just a subset of the functionalities usually exported with the AT commands set so, in order to "fill the gap", a further set of APIs is usually exported as well:
A set of functions that allow the simulation of AT commands sent to the modem's serial port. Sending them and parsering the responses they send in the vitual internal serial/USB interface allow the user to port in the internal user application area the the application they previously run on an external host processor (with obvious BOM benefits).
As an example, please check Telit Appzone here and here. It was the inspiration of my answer because I know it very well.
I don't know why you name the title that there's a relationship between AT command and Linux-C API.
Regarding AT command, you can take a look at this wiki article for general information.
Each module has a specified AT command sets. Normally, the module manufacture just offers AT command set and what return values are.
Is API a wrapper of AT command?
If you can use the API provided by the manufacturer, then yes, it's a wrapper of the AT command handler.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
It is impossible to be sure without having any details of the device, but probably any C API for it wraps the AT command set, either by communicating with the device directly over an internal serial interface or by going through a device driver that uses AT commands to communicate with it.
However, it is at least conceivable, albeit unlikely, that the 4G device offers an alternative control path that the C API uses (definitely via a driver in this case).
I'm not quite sure what the point of the question is, though. If you are programming the device and its 4G component in C, and the manufacturer has provided a C API, then use it! If you are programming in some other language then at least consider using the C API, which you should be able to access from most other languages in some language-specific way. You should not expend effort on rolling your own without a compelling reason to reject the API already provided to you.
I am trying to implement a method which a client behind a NAT can reach my video/audio encoder device connected to another LAN (behind another NAT), and then my device streams Video and Audio to that client.
Is there anyone who knows how to deal with NAT issue for P2P communication?
I have read and review the UDP hole punching, STUN/TURN/ICE and a few other methods like uPnP protocol and so on. All of them either have uncertainty in transmission or it's different from NAT to NAT or it is complicated to be implemented on my device.
I am wondering if there is a simpler method to handle this thing?! Since I have to do networking things on my device, unlike PC, it is not very strong and I can't expect a lot of computation. Thus I prefer a simple method.
Thanks~
The 'easiest' way would be to have 1 device outside both NATs which both devices connect to and acts as a proxy. From the question you are asking, I think this would be an answer to your problem, AND, that you could probably implement.
Is there any way to query the system's date/time via USB without installing anything on the host computer (maybe just drivers)?
Background of the original problem
To avoid the XY problem, let me explain a bit what I'm trying to do.
To be able to calculate a TOTP token for 2FA (e.g. like Google Authenticator app does) you need a real-time clock to get the date and time.
There's this USB device called SC4-HSM that I would like to use to calculate the tokens, however it doesn't have a clock and according to the designer, adding one would be too expensive (needs a battery, etc).
Possible solution to the original problem
This device is going to be used with a computer which already has an RTC of course. Thus I had the idea of querying the system for a date/time which would solve the issue.
(Note: I know that a USB device can be connected to all sorts of hosts and not all hosts will have an RTC, but since this only needs to work with a computer, I thought this shouldn't be an issue)
My first thought was that there might be some USB device class that had date/time needs, so I could register the device as that type and then I would be able to query the values.
After going through the device class codes list (Internet Archive) nothing jumped at me as needing date/time. The closest ones I could think of were:
Content Security (PDF)
Personal Healthcare
Smart Card Class (PDF)
I skimmed the device class documents in the USB Implementers Forum but there's nothing in there even remotely related to date or time.
Current problem
Since the USB specs seemed like a dead-end I thought that maybe there was a way to write a very simple USB driver that can be auto-loaded when the device is plugged in to a computer and then we can use the driver to return the date/time when the device asks for it (unless I'm misunderstanding something).
I am now looking through USB development docs like Michael Opdenacker's Linux USB drivers course, I tried the Linux USB Project which seems dead. Skimmed through Driver Development for Windows NT just to get an idea, however I am still not able to figure out if this is possible or not, and how hard it would be.
I'm a complete beginner at this and maybe this is something out of my skill level, but I would like to figure out if will I need weird hacks and workarounds or is there a much more straightforward way to do this?
There seems to be little information about it or I'm just searching the wrong places.
Any ideas/or pointers on either solving the original problem or the current one?
system time is not necessarily the general time i.e. the 'atomic' time you get from a NTP server
the most obvious solution is to use autorun, this is also possible on linux but normally autorun is blocked so the user explicitely has to activate it
https://askubuntu.com/questions/642511/how-to-autorun-files-and-scripts-in-ubuntu-when-inserting-a-usb-stick-like-autor
the linux command to get the time is date or hwclock or if the computer is connected to the net it may be possible to contact a NTP server (if the firewall does not block this)
then your autorun program has to send the data to the SC4-HSM. i do not know what USB classes the SC4-HSM implements if it implements CDC ACM (virtual COM port) this is easy:
Unable to sync computer time to Arduino via USB
(something like echo "T$(($(date +%s)+60*60*$TZ_adjust))" >/dev/tty.usbmodemfa131)
maybe it is possible to access system time over the USB drivers, i do not know this right now
I build a script with scapy to capture probe requests in a monitornig wi-fi interface.
I successfully capture the requests, and some of the SSIDs contained in them. But most of the networks stored in the phone don't get broadcasted.
And there isn't a clear pattern of why this happens. Some phones don't broadcast ssids at all.
I'm trying to find an explanation for the reasoning behind this behaviour, but haven't found any, apart that the hidden networks should be broadcasted in order for the phone to connect to them, but even that is not true, and most of the broadcasted ones are visible.
Another behaviour is the iPhones, that only seem to broadcast the network that they are connected to, and nothing else. (no network -> no SSIDs).
I have tried putting the interface in various channels, and results vary on the broadcasted networks, but the great majority of the saved ones in the device still aren't broadcasted.
Is there a reason behind this? Or a way to force the device to broadcast them all?
You seem to assume that the phone would do a probe request for each and every known network, permanently.
This is not the case - and not just for phone, but in general. Quoting the Wi-Fi Alliance[*]:
What are passive and active scanning?
The reason for client scanning is to determine a suitable AP to which
the client may [emphasis mine] need to roam now or in the future. A client can use two
scanning methods: active and passive. During an active scan, the
client radio transmits a probe request and listens for a probe
response from an AP [emphasis mine]. With a passive scan, the
client radio listens on each channel for beacons[emphasis mine again]
sent periodically by an AP. A passive scan generally takes more time,
since the client must listen and wait for a beacon versus actively
probing to find an AP. Another limitation with a passive scan is that
if the client does not wait long enough on a channel, then the client
may miss an AP beacon.
So this is entirely application/OS dependent if
the phone STA do an active scan, sending probe requests,
or just seat there listening for beacons (or doing nothing at all).
In my remembering - it's been a few years I didn't worked/looked at Android code, so it may have change - Android will not do an active scan, and thus will not send probe request to known SSID, unless you're in the Wi-Fi networks setting screen. It will just listen to beacons.
There are some Wi-Fi 802.11 design rationale behind this:
STA are supposed to be mobile. After all, if you're not moving from
time to time, there's not much point in using Wi-Fi (except marketing
or laziness, and of course smartphones changed that), you might as
well get wired.
...if you're mobile, it's reasonable to think you're running on a
battery,
And so you want to save battery life: so you'll rather do passive
scans listening to beacons rather than active scan sending probe
request, because this uses less power.
This idea of power saving alternative capabilities is spread all other the place in 802.11 design, hidden under carpet, when you're a STA.
So it is fully OS stack/application dependent from the STA if it 1/ just listen to beacons /2 actively send probe-request for every know AP 3/ send a broadcast probe-request, and also if it do so in a continuous manner, or periodically, or depending if it's in a know state (ex screen ON, and user going to the Wi-Fi networks setting screen).
Now there may be some other considerations, like some regional regulations that mandate that you first listen to beacons to decide if you can or cannot use some channels. But the main point is above.
*:
http://www.wi-fi.org/knowledge-center/faq/what-are-passive-and-active-scanning
EDIT:
On the programming side:
1/ What you seem to have is an IOP (interoperability) problem, because you expect a specific behavior from STA regarding scanning active vs passive and the involved probe-requests, and this is not how it works in the real world. Depending on your application final main goal, this may be a flawn in the design - or just a minor nuisance. You may want to restrict yourself to some specific device's brand, or try to cover all cases, which has a development cost.
2/ ...OR you were just surprised by your observations, and look for an explanation. In such case of surprising results, it goes without saying: go straight to wireshark to check your program observations (if your program is a packet sniffer) or behavior (if your program is a client/server/layer XYZ protocol implementation).
On the 802.11 strategies regarding active vs passive scan and power saving:
From "802.11 Wireless Networks: The Definitive Guide, 2nd Edition", by Matthew S. Gast ("member of the IEEE 802.11 working group, and serves as chair of 802.11 Task Group M. As chair of the Wi-Fi Alliance's Wireless Network Management marketing task group, he is leading the investigation of certification requirements for power saving, performance optimization, and location and timing services" - from his publisher bio). A book i can highly recommend.
p. 171:
ScanType (active or passive)
Active scanning uses the transmission of Probe Request frames to
identify networks in the area. Passive scanning saves battery power by
listening for Beacon frames.
p. 172:
Passive Scanning
Passive scanning saves battery power because it does not require
transmitting. In passive scanning, a station moves to each channel on
the channel list and waits for Beacon frames.
Also, a bit old (2003), but these guys know their stuff about networking. About scanning strategies:
From Cisco "802.11 Wireless LAN Fundamentals", chapter 5 "mobility".
Page 153:
Roaming Algorithms
The mechanism to determine when to roam is not defined by the IEEE
802.11 specification and is, therefore, left to vendors to implement. [...] The fact that the algorithms are left to vendor implementation
provide vendors an opportunity to differentiate themselves by creating
new and better performing algorithms than their competitors. Roaming
algorithms become a vendor’s “secret sauce,” and as a result are kept
confidential.
Page 154 "Determining Where to Roam":
There is no ideal technique for scanning. Passive scanning has the
benefit of not requiring the client to transmit probe requests but
runs the risk of potentially missing an AP because it might not
receive a beacon during the scanning duration. Active scanning has the
benefit of actively seeking out APs to associate to but requires the
client to actively transmit probes. Depending on the implementation
for the 802.11 client, one might be better suited than the other. For
example, many embedded systems use passive scanning as the preferred
method [emphasis mine] [...]
Other interesting stuff on page 155, "Preemptive AP Discovery".
I have a requirement to have a cross-platform program --- intended for mobile devices such as Android, Brew, Bada, WinCE etc --- be able to communicate with other instances of itself via Bluetooth.
Unfortunately:
the Bluetooth APIs on such devices are all radically, radically different.
the terminology they use is also radically different.
what actually works is frequently radically different to what they say works.
So far I've discovered that Android will allow you to connect to or listen on RFCOMM services specified by a simple UUID, but does not allow more complicated manipulation of SDP records; Brew claims to support SPP but the API appears to allow arbitrary RFCOMM; Bada supports SPP but doesn't allow you to specify the UUID, so I have no idea how you're supposed to do service discovery or listen for two things at once...
Oh, and iOS doesn't allow Bluetooth communication at all to non-iOS devices.
So:
I can't be the first person to need to do this. Is there a known subset of Bluetooth functionality that I should be using in order to maximise portability?
Device makers usually implement some bluetooth profiles such as A2DP, OBEX, etc. Depending what you want to do, you should check that all your target devices implement the required profiles.
Note that even though a device can implement an specific profile, there may not be an API that will allow you to use it.
See http://en.wikipedia.org/wiki/Bluetooth_profile.