I'm building an application (runs on central device) in which I can scan, connect, pair, & reconnect in LE to a specific target device (peripheral device). My application is able to scan for Bluetooth LE devices and I have set the connection function. When I run my application, it scans until it find the target device and then it starts the connecting process.
On the target side (peripheral), I can see my central device was able to connect to it but the connection is dropped immediately. I think this is because it didn't find any compatible service (I think that just means there was no recognizable GATT attirubute/application/service?). I tried to connect to the same peripheral device through bluetoothctl and the connection drops immediately which makes me think something is missing from my target device (peripheral).
I'm wondering if I need to implement anything else before I try to connect to my peripheral device? Is it disconnecting because it didn't find any recognizable service on my central?
This is what I have from btmon on the peripheral side with another connection which was successful:
Connection request
Read remote supported features (understood remote as target device)
Turn off scan
Read remote extended features
Remote name request
Found this in the BTMON. "Attribute not found" possibly the issue?
> ACL Data RX: Handle 128 flags 0x02 dlen 11 #23 [hci0] 16.564046
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
< ACL Data TX: Handle 128 flags 0x00 dlen 24 #24 [hci0] 16.564325
ATT: Read By Group Type Response (0x11) len 19
Attribute data length: 6
Attribute group list: 3 entries
Handle range: 0x0001-0x0005
UUID: Generic Access Profile (0x1800)
Handle range: 0x0006-0x000f
UUID: Generic Attribute Profile (0x1801)
Handle range: 0x0010-0x0012
UUID: Device Information (0x180a)
< ACL Data TX: Handle 128 flags 0x00 dlen 11 #25 [hci0] 16.564349
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0xffff
Attribute type: Unknown (0x2b3a)
> HCI Event: Number of Completed Packets (0x13) plen 5 #26 [hci0] 16.580038
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 11 #27 [hci0] 16.596035
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0013-0xffff
Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5 #28 [hci0] 16.596041
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 9 #29 [hci0] 16.596267
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0013
Error: Attribute Not Found (0x0a)
> ACL Data RX: Handle 128 flags 0x02 dlen 9 #30 [hci0] 16.620082
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x0001
Error: Attribute Not Found (0x0a)
I am doing some changes in the SO_PRIORITY of the socket that sends UDP packets, using the command setsockopt, is there a way to see that changes with Wireshark or Tcpdump.
I read that can be DSF (Differentiated Services Field), but I am not sure because when I make the changes I see that this field is 00.
I am running a Linux Mint 19.3
It is part of the 802.1Q header. For ex:
> 802.1Q Virtual LAN, PRI: 5, DEI: 0, ID: 4
101. .... .... .... = Priority: Voice, < 10ms latency and jitter (5)
...0 .... .... .... = DEI: Ineligible
.... 0000 0000 0100 = ID: 4
Type: IPv6 (0x86dd)
I am attempting to utilize the DLN-2 in an x86_64 Linux environment (kernel version 4.18) to provide SPI and I2C bus controllers to the userspace, in a similar manner you would using an ARM platform with DTS/DTB file modifications. I am having trouble identifying the proper method to attach a SPI slave device or mount the device to userspace with the spidev driver.
The kernel modules are loading successfully and the SPI bus is mounted as a spi_master. I am certain the chip itself is working because the I2C (/dev/i2c-#) and GPIO (/dev/gpiochip#) interfaces can be successfully manipulated. For reference, here is a list of all references in the Linux system tree for "dln":
# find /sys -name *dln*
/sys/devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/dln2-i2c.1.auto
/sys/devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/dln2-spi.2.auto
/sys/devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/dln2-gpio.0.auto
/sys/fs/selinux/booleans/minidlna_read_generic_user_content
/sys/bus/platform/devices/dln2-i2c.1.auto
/sys/bus/platform/devices/dln2-spi.2.auto
/sys/bus/platform/devices/dln2-gpio.0.auto
/sys/bus/platform/drivers/dln2-gpio
/sys/bus/platform/drivers/dln2-gpio/dln2-gpio.0.auto
/sys/bus/platform/drivers/dln2-adc
/sys/bus/platform/drivers/dln2-spi
/sys/bus/platform/drivers/dln2-spi/dln2-spi.2.auto
/sys/bus/platform/drivers/dln2-i2c
/sys/bus/platform/drivers/dln2-i2c/dln2-i2c.1.auto
/sys/bus/usb/drivers/dln2
/sys/module/i2c_dln2
/sys/module/i2c_dln2/drivers/platform:dln2-i2c
/sys/module/industrialio_triggered_buffer/holders/dln2_adc
/sys/module/spi_dln2
/sys/module/spi_dln2/drivers/platform:dln2-spi
/sys/module/industrialio/holders/dln2_adc
/sys/module/dln2_adc
/sys/module/dln2_adc/drivers/platform:dln2-adc
/sys/module/gpio_dln2
/sys/module/gpio_dln2/drivers/platform:dln2-gpio
/sys/module/dln2
/sys/module/dln2/holders/i2c_dln2
/sys/module/dln2/holders/spi_dln2
/sys/module/dln2/holders/dln2_adc
/sys/module/dln2/holders/gpio_dln2
/sys/module/dln2/drivers/usb:dln2
Here is the matching portion of the boot log:
[ 1.578110] usb 1-2: new full-speed USB device number 2 using xhci_hcd
[ 1.705306] usb 1-2: New USB device found, idVendor=a257, idProduct=2013, bcdDevice= 1.00
[ 1.705310] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.705312] usb 1-2: Product: Diolan DLN2
[ 1.705314] usb 1-2: Manufacturer: Diolan
[ 10.485997] dln2 1-2:1.0: Diolan DLN2 serial 33632920
[ 10.486182] usbcore: registered new interface driver dln2
And the relevant portion of the usb device tree:
Bus 001 Device 002: ID a257:2013
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0xa257
idProduct 0x2013
bcdDevice 1.00
iManufacturer 1 Diolan
iProduct 2 Diolan DLN2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
At this point, I am assuming that an ACPI patch is the correct method. however, the device does not appear in the ACPI device tree, or I am not searching with the correct string. I am assuming it will be similar to the following, which I pulled from a kernel patch (https://lore.kernel.org/patchwork/patch/527210/) that appears to have since been removed from the current kernel.
DefinitionBlock ("dln2.aml", "SSDT", 1, "INTEL", "CpuDptf", 3)
{
Device (DLN0)
{
Name (_ADR, Zero)
Name (_HID, "DLN2000")
Device (TP40) {
Name (_HID, "SPT0001")
Name (_DDN, "SPI4-CS0")
Name (_CRS, ResourceTemplate () {
SpiSerialBus (
1, // Chip select
PolarityLow, // Chip select is active low
FourWireMode, // Full duplex
8, // Bits per word is 8 (byte)
ControllerInitiated, // Don't care
1000000, // 1 MHz
ClockPolarityLow, // SPI mode 0
ClockPhaseFirst, // SPI mode 0
"\\DLN0.SPI0", // SPI host controller
0 // Must be 0
)
})
}
}
}
I have also tried udev rules, but my knowledge of udev is slim so they are likely incorrect. None of these appeared to have done the trick:
DEVPATH=="/devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/dln2-spi.2.auto/spi_master/spi0", DRIVER="spidev"
DEVPATH=="/devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/dln2-spi.2.auto/spi_master/spi0", KERNEL="spi-SPT0001:02", SUBSYSTEM="spi", DRIVER="spidev", ATTRS{driver_override}==""
DEVPATH=="/devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/dln2-spi.2.auto/spi_master/spi0/spi-SPT0001:02", KERNEL="spidev2.0", SUBSYSTEM="spidev", DRIVER=""
Okay, now I'm able to answer to the question.
First of all, assume that DSDT on the host machine, i.e. USB host controller excerpt, looks like this (some names maybe different, some methods may or may not be provided, just interesting us part):
Device (XHC)
{
Name (_ADR, 0x00110000)
...
Device (RHUB)
{
Name (_ADR, Zero)
// GPLD: Generate Port Location Data (PLD)
Method (GPLD, 1, Serialized) {
Name (PCKG, Package () {
Buffer (0x10) {}
})
// REV: Revision 0x02 for ACPI 5.0
CreateField (DerefOf (Index (PCKG, Zero)), Zero, 0x07, REV)
Store (0x02, REV)
// VISI: Port visibility to user per port
CreateField (DerefOf (Index (PCKG, Zero)), 0x40, One, VISI)
Store (Arg0, VISI)
Return (PCKG)
}
Device (HS01) { Name (_ADR, 1) }
Device (HS02) { Name (_ADR, 2) }
Device (SS01) { Name (_ADR, 3) }
Device (SS02) { Name (_ADR, 4) }
...
}
}
Important thing above is that port devices (HS01, SS01, etc) does not have _UPC() or _PLD() methods. If they are, you will need to override complete DSDT or upgrade it and ACPI SSDT overlays won't work.
Assume that Diolan device is connected to HS02 USB port. In this case we have to provide the following ACPI excerpt, either in DSDT or as SSDT overlay (Note, method GPLD(), if not present, should be copied from above excerpt):
External (\_SB.PCI0.XHC.RHUB.HS02, DeviceObj)
External (\_SB.PCI0.XHC.RHUB.GPLD, MethodObj)
/*
* We set the port to hard wired state to get the connected device
* enumerated properly. See more details here:
* https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-_adr-for-embedded-usb-devices
*/
Scope (\_SB.PCI0.XHC.RHUB.HS02)
{
Name (_UPC, Package ()
{
0xFF,
0xFF,
Zero,
Zero,
})
Method (_PLD, 0, NotSerialized)
{
Return (GPLD (Zero))
}
Device (GPIO)
{
Name (_ADR, Zero)
Name (_STA, 0x0F)
}
Device (I2C)
{
Name (_ADR, One)
Name (_STA, 0x0F)
}
Device (SPI)
{
Name (_ADR, 0x02)
Name (_STA, 0x0F)
}
}
Note, this example now is a part of meta-acpi project.
After loading these tables we will get everything enumerated like:
$ grep -H HS02 /sys/bus/acpi/devices/device\:*/path
/sys/bus/acpi/devices/device:09/path:\_SB_.PCI0.XHC.RHUB.HS02
/sys/bus/acpi/devices/device:0e/path:\_SB_.PCI0.XHC.RHUB.HS02.GPIO
/sys/bus/acpi/devices/device:0f/path:\_SB_.PCI0.XHC.RHUB.HS02.I2C_
/sys/bus/acpi/devices/device:10/path:\_SB_.PCI0.XHC.RHUB.HS02.SPI_
$ ls -l /sys/bus/platform/devices/dln2-*/firmware_node
lrwxrwxrwx 1 root root 0 Jan 1 00:04 /sys/bus/platform/devices/dln2-gpio.2.auto/firmware_node -> ../../../../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:07/device:08/device:09/device:0e
lrwxrwxrwx 1 root root 0 Jan 1 00:04 /sys/bus/platform/devices/dln2-i2c.3.auto/firmware_node -> ../../../../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:07/device:08/device:09/device:0f
lrwxrwxrwx 1 root root 0 Jan 1 00:04 /sys/bus/platform/devices/dln2-spi.4.auto/firmware_node -> ../../../../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:07/device:08/device:09/device:10
This gets us the device object we can attach our slave devices to. So, more detailed this part has been answered in the following SO posts:
adding i2c client devices on x86_64
Building a i2c device controller
spidev Linux driver on Intel Atom board
Note, there are two patches to make it possible in Linux.
One is a599a0fb629a ("Add ACPI support for USB interface devices") and one is pending e3fadb35bc1b ("Allow to be enumerated via ACPI"). Both will be in v5.7-rc1.
I am trying to read the data coming from one device with the CAN communication protocol. I am using the Kvaser CAN-USB connector and python-can, but after sending the message I get the following:
Here's the my code:
import can
import time
bus=can.interface.Bus(bustype='kvaser',channel=0, bitrate=250000)
print (bus)
time.sleep(1)
msg =can.Message(arbitration_id=0x032)
print(msg)
time.sleep(1)
while True:
bus.send(msg)
recvMsg = bus.recv(timeout=0.5)
print (recvMsg)
time.sleep(1)
And here's the response i'm getting:
Kvaser Leaf Light v2, S/N 54781 (#1)
Timestamp: 0.000000 ID: 00000032 X DLC: 0
Timestamp: 1546613346.010231 ID: 0000 S E DLC: 4 00 01 00 00 Channel: 0
According to the manual I have to use the following:
Bitrate: 250 kbs
11-bit identifier: 0x031
Default settings TX only
8 byte message structure:
Byte:1,
Description:State of charge [%],
Type: Unsigned char,
Value: 0-200 LSB = 0.5 % SOC.
This is my first time I use this communication protocol and I have read the python-can 3.0 description, but still is not clear to me how to solve the problem. Any recommendation?
ID: 0000 indicates an error frame!
In the script you set the arbitration_id=0x032, but the manual says
11-bit identifier: 0x031
is that a typo?
How does your network look like? How many nodes do you have?
Have you terminated the CAN bus?
Is there any reason why you do not use PyCANlib from Kvaser?
Use of IPv6 tunnels (like tunnelbroker.net) is possible on Azure VM, via ILPIP (Instance Level Public IP)?
I tried to use it, but I don't get replies for ping packets to IPv6 gateway.
Internet Protocol Version 4, Src: 100.90.204.79, Dst: 216.66.84.46
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 124
Identification: 0x33d7 (13271)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: IPv6 (41)
Header checksum: 0xea66 [validation disabled]
[Good: False]
[Bad: False]
Source: 100.90.204.79
Destination: 216.66.84.46
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Protocol Version 6, Src: 2001:470:1f14:105a::2, Dst: 2001:470:1f14:105a::1
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 1001 0111 0111 0110 1010 = Flowlabel: 0x0009776a
Payload length: 64
Next header: ICMPv6 (58)
Hop limit: 64
Source: 2001:470:1f14:105a::2
Destination: 2001:470:1f14:105a::1
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0xd3f8 [correct]
Identifier: 0x5016
Sequence: 1
[No response seen]
[Expert Info (Warn/Sequence): No response seen to ICMPv6 request in frame 212]
[No response seen to ICMPv6 request in frame 212]
[Severity level: Warn]
[Group: Sequence]
Data (56 bytes)
Data: 8bb5ed56000000006ed40d00000000001011121314151617...
[Length: 56]
I suspect that Azure is rejecting IPv4 protocol 41, am I correct?
The following is documented:
Microsoft has played a leading role in helping customers to smoothly transition from IPv4 to IPv6 for the past several years. To date, Microsoft has built IPv6 support into many of its products and solutions like Windows 8 and Windows Server 2012 R2. Microsoft is committed to expanding the worldwide capabilities of the Internet through IPv6 and enabling a variety of valuable and exciting scenarios, including peer-to-peer and mobile applications. The foundational work to enable IPv6 in the Azure environment is well underway. However, we are unable to share a date when IPv6 support will be generally available at this time.