Develop Reference

send UDP messages from Wear OS via Bluetooth

My goal is to send a UDP message (smaller than 100 bytes) from a SmartWatch (running wear os 2) to an Arduino on the same network. As long as the SmartWatch stays connected to the wifi (ip address of the watch: 145.167.189.23) this works great.
But when I turn on bluetooth, the SmartWatch disables wifi and switches to an internet connection via the bluetooth connected phone.
The SmartWatch gets an ip address in a subnet of the internet connection from the mobile (if the mobile has the ip address 145.167.189.105, it gets 145.167.177.4). TCP requests, like 'stackoverflow.com' work fine.
If I now try to send a UDP message nothing arrives at the Arduino.
I already tried to send a UDP message to 255.255.255.255, 145.255.255.255, 145.167.255.255, 145.167.189.255, but nothing ever arrived at the Arduino ( verified by Wireshark).
Over six years ago there was the same problem (Simple UDP Broadcast not working on Android Wear), at that time wear os 2 was not available. The only proposed solution was the 'Wear Data Layer'. I already tried this as well, but observed very large latencies (about 3 seconds). Therefore, these do not represent a solution for me at all.
The documentation for network access on wear os only says
You can use protocols such as HTTP, TCP, and UDP
Maybe someone could give me a hint why the UDP messages are not forwarded from the phone.

Only DNS udp packages can be forwarded to the phone.
It setup some iptable rules to forward udp packages to the TPROXY. Look at the following rules (iptables -t mangle -L). It does't forward udp packges to Reserved IP addresses.
Chain oem_CW_PROXY_UDP (22 references)
target prot opt source destination
RETURN all -- anywhere 0.0.0.0/8
RETURN all -- anywhere loaclhost/8
RETURN all -- anywhere 100.64.0.0/10
RETURN all -- anywhere 127.0.0.0/8
RETURN all -- anywhere 169.254.0.0/16
RETURN all -- anywhere 172.16.0.0/12
RETURN all -- anywhere 192.0.0.0/29
RETURN all -- anywhere 192.0.2.0/24
RETURN all -- anywhere 192.168.0.0/16
RETURN all -- anywhere 198.18.0.0/15
RETURN all -- anywhere 198.51.100.0/24
RETURN all -- anywhere 203.0.113.0/24
RETURN all -- anywhere 224.0.0.0/4
RETURN all -- anywhere 240.0.0.0/4
RETURN all -- anywhere 255.255.255.255
TPROXY udp -- anywhere anywhere TPROXY redirect 0.0.0.0:35070 mark 0x1/0x1
The TPROXY will forward the reveived udp packcages to the phone throught bluetooth socket. But it will only forwoard DNS packages, which can be seen from the watch's logcat.
It seems that Wear OS decided to only forwoard DNS packages at some time.
05-20 12:20:31.269806 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:36215 original dst: /8.8.8.8:53
05-20 12:21:05.264492 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:63348 original dst: /8.8.8.8:53
05-20 12:21:05.272685 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 32 bytes, from: /192.168.167.239:34219 original dst: /8.8.8.8:53
05-20 12:21:38.282089 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:54529 original dst: /8.8.8.8:53
05-20 12:21:38.287255 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 32 bytes, from: /192.168.167.239:58688 original dst: /8.8.8.8:53

Enabling link layer PDU size of 251 for Bluetooth LE in Android 10

I have a BLE app on an Arduino Nano that continously sends IMU-data to a custom app I have developed for an Android phone. When I am sniffing the on-the-air traffic it seems that the phone is requesting a link layer PDU size of 27. If I would able to increase this to 251, it would require fewer link layer packets (and hence a lower overhead). The phone is a Motorola Edge which implements Bluetooth 5.1. The Android version is 10.
I have not found any settings in the Bluetooth API that controls this. Is it even possible to achieve this?
Upon connection the Arduino (the slave) sends an LL_LENGTH_REQ with 251 RX/TX octets to the master (the phone). The LL_LENGTH_RSP message from the phone looks like below in Wireshark, which might explain why the PDU size of 27 is selected.
Frame 294: 29 bytes on wire (232 bits), 29 bytes captured (232 bits)
Bluetooth
Bluetooth Low Energy RF Info
Bluetooth Low Energy Link Layer
Access Address: 0x88c78ca1
.... ..00 = Coding Indicator: FEC Block 2 coded using S=8 (0)
[Master Address: 51:7a:c0:c9:6e:81 (51:7a:c0:c9:6e:81)]
[Slave Address: ca:8b:68:49:aa:7a (ca:8b:68:49:aa:7a)]
Data Header: 0x090f
.... ..11 = LLID: Control PDU (0x3)
.... .1.. = Next Expected Sequence Number: 1
.... 1... = Sequence Number: 1 [OK]
...0 .... = More Data: False
000. .... = RFU: 0
Length: 9
Control Opcode: LL_LENGTH_RSP (0x15)
Max RX octets: 251
Max RX time: 17040 microseconds
Max TX octets: 27
Max TX time: 2704 microseconds
CRC: 0x000000

Try to set the MTU by calling requestMtu after your connection is established. You will receive the onMtuChanged callback afterwards. Start your service discovery after a successful MTU request.

Android BLE peripheral disconnects with status code BLE_HCI_INSTANT_PASSED(0x28)

My application is able to connect to the BLE peripheral(which is an OBDII/J1939 device) device successfully.
2018-01-24 14:58:38,413 INFO LogUtil - GATT Server Status = (0) : BLE_HCI_STATUS_CODE_SUCCESS(0x00)
2018-01-24 14:58:38,414 INFO LogUtil - GATT Server New State = (2) : STATE_CONNECTED
2018-01-24 14:58:38,414 INFO LogUtil - Connected to GATT server.
Application started communication with the device but after some time it received GATT server disconnection message in onConnectionStateChange in callback implementation of BluetoothGattCallback . Below are the logs from application:
2018-01-24 15:07:46,396 INFO LogUtil - GATT Server Status = (40) : BLE_HCI_INSTANT_PASSED(0x28)
2018-01-24 15:07:46,397 INFO LogUtil - GATT Server New State = (0) : STATE_DISCONNECTED
2018-01-24 15:07:46,398 INFO LogUtil - Disconnected from GATT server.
Not able to find any reason behind BLE_HCI_INSTANT_PASSED status code.
Any help on this will be helpful.

When data is being transmitted over BLE, data transfers can only start at sync points in time known as "connection events". At the BLE link layer there are couple special requests that can be made which are relative to these sync points. They are:
LL_CHANNEL_MAP_REQ - A request to change the BLE channels being transmitted on. Bluetooth chips will change the channel map based on the noise in the environment to try to limit packet drop.
LL_CONNECTION_UPDATE_REQ - A request to change the frequency of "connection events" (known as the "connection interval"). This is done to achieve better throughput/latency or save more power.
Each of these Link Layer requests when sent over the air contains an "Instant" to change. The "Instant" is the "connection event" in the future to apply the change.
At the Link Layer, BLE is reliable. This means each Link Layer packet must be ack'd by the other side. In a noisy RF environment, it's possible a link layer packet may require a couple retries to actually send. This means the packet could arrive many "connection events" after originally intended.
If one of the packets mentioned above is received after the "Instant" the changes were supposed to be applied, by definition the BLE chip must disconnect with reason 0x28 (Instant Passed)
For additional details on the topic, the Bluetooth Core Specification available from the Bluetooth SIG website is a good reference:

UDP source port number is missing in the SETUP response message

I am working on a Wifi Display Sink application in android and am facing an issue where the source is not sending the UDP server-port number in the RTSP SETUP message.
The SETUP RESPONSE is as below
'RTSP/1.0 200 OK
cseq: 2
date: Tue, 11 Aug 2015 15:12:38 +0000
server: Mine/1.0
session: 1719935144;timeout=60
transport: RTP/AVP/UDP;unicast;client_port=15550-15551;
'
NOTE:
I have figured out the server-port number using tcpdump in the source device. It is 16660. It doesnot look like any specifically assigned port number as well.Seems like a random port number hardcoded into the source device for Wifi Display Application.
Is there any other way to know the server-port number to which I should listen to for incoming UDP packets?

You should be listening on port 15550 and 15551 and the incoming UDP packets will contain their source port.

Android 4.3 BLE connection with Raspbery Pi (Bluez 5.8)

Device1: Nexus 4 Android 4.3 BLE Central (Using BluetoothLeGatt sample app in API 18 SDK as is)
Device2: Raspberry Pi with working BT4.0 USB Dongle, Raspbian Whezzy 20130726. Compiled Bluez 5.8 from the sources.(Since the packaged ver is 4.99 which not officially support BLE yet)
Working as peripheral, I started bluetoothd with "-p alert" (GATT Alert profile).
Test1: Using two raspi (device2 above) I can connect and browse alert gatt service/characteristics on other device using gattool.
Test2: Using iPhone/iPad (free BLE app: LightBlue) as Central I can also connect and browse alert gatt services and characteristics value on the Raspi.
Test3: When connecting using Nexus 4 sample app, (which is unstable), it asking for authorization on both device.Even after I can get rid off the authorization, the hcidump look like they are exchanging SDP info, the service list still not come up on Android sample app.
Test4: Nexus 4 sample app can connect and browse service on Fitbit One and Wahoo HRM.
Using hcidump (on the raspi), I can see different connection initiation:
Test1/2:
>HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 44, role slave
bdaddr ... (Public)
Test3:
>HCI Event: Connect Request (0x04) plen 10
bdaddr ... class 0x5a020c type ACL
(Is it Bluetooth classic connection?)
Question:
Is there any way I can make Android BLE connection to create HCI Event: LE Meta Event on Raspi?