I am trying to get at the Bluetooth data needed to control my Bluetooth lamp. I have created the bt_snoop file after successfully controlling my lamp through the app. I've done this many times and I always get the same result.
When I open bt_snoop in Wireshark and filter for my device all of the data has a warning: "[[Expert Info (Warning/Malformed): Length too short]". It also says "Payload: MISSING". I am able to control the light through the app, but the bt_snoop log just shows that error. I'm really lost and would really appreciate help!
Related
I've been experimenting with the new Android Nearby Connections v2.0 API. Most of my devices can now talk to each other most of the time, but I also get a lot of error codes back when trying to connect. Checking status.getStatusCode() inside my program, I can see the following return codes:
STATUS_ALREADY_CONNECTED_TO_ENDPOINT (8003)
STATUS_BLUETOOTH_ERROR (8007)
STATUS_ENDPOINT_IO_ERROR (8012)
STATUS_ERROR (13)
I'm having a hard time making sense of these. The first error code seems self-explanatory, except that I see it in cases when I haven't hit the onConnectionResult callback with a "SUCCESS" return code on either side of the alleged connection. My current code is full of trace statements, and I'd see logging entries if those callbacks had been reached. So maybe the devices are connected at some lower level, but if so, the higher-level code doesn't always hear about it.
I'm guessing that STATUS_BLUETOOTH_ERROR indicates a Bluetooth error on the side that logs it, while STATUS_ENDPOINT_IO_ERROR indicates an error (probably involving Bluetooth) on the other end? Is it possible to get any more details?
The STATUS_ERROR (13) status that I see once in a while sounds like the sort of error code a programmer would use for those "WTF, we should never get here" moments, but without access to the source code, I can only guess.
Note that I see these errors between devices that talk to each other beautifully at other times, using the same code. Sometimes if the code retries enough times, it eventually gets a stable connection. Sometimes it connects and gets instantly disconnected from the other end. Sometimes I just get an endless stream of repeated error messages (STATUS_BLUETOOTH_ERROR and/or STATUS_ENDPOINT_IO_ERROR).
I'm using Nearby Connections with the connection strategy P2P_CLUSTER. These problems seem to happen most often when both sides do both advertising and discovery. However, I wrote two smaller programs that specialize in either advertising or discovery, and they sometimes get these errors too (but less often).
In the trace messages, I've also noticed lots of warning messages from Nearby Connections that look like this:
09-04 22:54:40.070 3866-3924/? W/NearbyConnections: Cannot deserialize BluetoothDeviceName: expecting min 16 raw bytes, got 6
I'm guessing that this is because Nearby Connections uses its own short tokens (like ZGbx) instead of the device Bluetooth name? I'm not at all sure about that, though. And anyway, if these are Nearby Connections' own special tokens, then why would it be issuing warning messages about it?
[Disclaimer: I work on Nearby Connections] I can try and help out.
STATUS_ALREADY_CONNECTED_TO_ENDPOINT: This occurs if you call 'requestConnection' while you have any pending (onConnectionInitiated) or established (onConnectionResult) connections to the given endpoint. Move your log statements earlier, to onConnectionInitiated, and you should see why we throw this error.
STATUS_BLUETOOTH_ERROR: Something went wrong with Bluetooth. The phone is probably in a bad state. This (hopefully) shouldn't happen too often. But if you really want a fix, stop advertising & discovery before reattempting requestConnection. Nearby Connections will toggle Bluetooth when it detects this error, but only if nothing else is going on.
STATUS_ENDPOINT_IO_ERROR: We lost connection to the other device. This can happen for a variety of reasons (they could have walked too far away, Bluetooth was flaky, the device stopped responding, etc). If you're discovering while you have connections, avoid that. Discovery can be hard on the phone and reduces bandwidth at best, causes dropped connections at worst.
STATUS_ERROR: Something went wrong that didn't fit well in the other error codes. It's a catch-all. This is most-often returned in onConnectionResult(FAILED), to notify you that something went wrong in between onConnectionInitiated and waiting for both sides to accept the connection.
We've also lowered the log severity of "Cannot deserialize BluetoothDeviceName" in an upcoming release, since it's not really a warning. It's like you said; expected behavior when we see non-Nearby Connections devices while discovering.
If you continue to see problems, let us know what devices you're using and we'll be sure to add them to our test suite.
I just want to add that it may be necessary to have a short client name string when calling the API.
E.g., Nearby.Connections.requestConnection(googleApiClient, shortNameHere,....)
I had been generating my own client name with UUID.randomUUID().toString() and that seemed to cause the STATUS_BLUETOOTH_ERROR.
All I did was change the code sample to use a UUID name and to use P2P_CLUSTER and I got that error.
This was the solution for me regarding the STATUS_BLUETOOTH_ERROR.
I am currently developing an android app and i want to send data message with audio file attached to it. One of the arguments of the sendDataMessage() methods is "destination port".
I know its the port i want to send the message via, but I am not sure what to put there, is there a default port for sending data messages? I have looked for it but every example I have seen uses different port. However, whichever port I use, I get Null PDU exception.
I am using HTC for running and testing the app btw.
Default is 8091. Most devices don't support port filtering very well, though:
SmsManager.sendDataMessage(..., onSpecificPort , ...,.. ) Is not Filtering SMS On Port Basis
Your null PDU is probably not because of a port selection problem, though.
According to the doc negative response means failure.
How to know what's wrong? is there any full doc about error types?
For more curious:
I'm trying to upload arduino sketch via USB. First i'm getting bootloader attention by turning DTR/RTS off/on and then sending data using Stk500 protocol. It's working fine if running on mac/arduino via usb (rxtx serial is used) so i think it should work on android AS-IS (just change serial), but it fails to send the data after DTR/RTS toggling.
Well, after diving into log i was able to handle it - don't close/open usb few times in a row
From the documentation for bulkTransfer():
Returns
length of data transferred (or zero) for success, or negative value for failure
So if you're getting -1, then it means your data transfer has failed. You could look into the logcat, or work with breakpoints to figure out why.
For some work I'm doing, I want to have an emulated GSM modem which will communicate with an Android-x86 virtual machine over a Unix socket. The VM should see the emulator as a real modem and use it to send SMS (as the first pass of functionality).
So far, I've put something together which handles some AT commands and just replies "OK" to all the rest. For some commands, like "AT+CRSM", I just have a table of responses gathered from running the official Android emulator and looking at the radio log. For others, I maintain some state and construct answers; those commands include:
CFUN?
CPIN?
CGREG?
CGREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CGSN
CIMI
CSQ
Android will boot, and send commands to my emulated modem, which answers, however it doesn't seem to be fully functional. Android doesn't detect any radio signal strength, for instance, just showing an "x" in the signal bar.
Does anyone know of a similar project, or just what AT commands are absolutely necessary to get some basic functionality?
Well, I'll answer another of my own questions, it's easier that way.
I ended up implementing an emulator which maintains a little bit of state, such as whether or not unsolicited CREG and CGREG messages are enabled, the network registration status & network name format (for the COPS command), and a message reference counter for SMS.
It supports the following commands:
CFUN?
CPIN?
CGREG?
CREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CMGS=
CGSN
CIMI
CSQ
All other messages just get an "OK" response.
With the stock AOSP Android source running in an emulator with the "-radio unix:/tmp/phone" switch, I can send SMS messages and decode the binary PDUs into real messages. I will continue to add functionality so SMS messages can be injected back to Android, and hopefully open-source the code at some point.
I am developing an application that will make SIP calls using the SIP APIs. I want to use the SipDemo code as my starting point, but when I run SipDemo on my devices (Nexus or Galaxy Tab) I always get "Registration failed. Please check settings." I am using the same username/password/server information that works successfully in Sipdroid.
I inserted log messages in setRegistrationListener to follow what's happening, and I will see onRegistrationDone fire, but then it seems to register again, because it will then see Registration failed with the error message "registration timed out" followed by registration failed with the error message "cannot initiate a new transaction to execute".
I've been beating my head about this for a few days, and I've got a deadline rapidly approaching. Any help on this issue would be greatly appreciated, or if you could point me to some other examples/tutorials of how to use the SIP APIs.
I fixed it! The demo wants to use UDP by default, but I was able to make it connect by hardcoding the protocol to TCP. I have a netgear modem from charter cable, and I have seen several reports of it blocking access. I assume the two are related, but for now I'm just happy to have it work so I can continue my development.
Thanks for the help!
Check the logcat, it should have more information about what failed. Also if you have control over the server, check the server logs as well.
Seems like you are not alone http://code.google.com/p/sipdroid/issues/detail?id=60.
I would suggest that you try what people tried there: i.e.
Try another router.
Change port in code. Read the link for more details.