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)
Related
Random mac address that changes every five-ten minutes or so. Sending out two different packets from the same address. What is this for?
No. Time Source Destination Protocol Length Info
9 0.821581 controller host HCI_EVT 42 Rcvd LE Meta (LE Advertising Report)
Frame 9: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface bluetooth-monitor, id 0
Bluetooth
Bluetooth Linux Monitor Transport
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 40
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Scannable Undirected Advertising (0x02)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: 77:fd:98:85:c9:32 (77:fd:98:85:c9:32)
Data Length: 28
Advertising Data
16-bit Service Class UUIDs
Length: 3
Type: 16-bit Service Class UUIDs (0x03)
UUID 16: Google (0xfe9f)
Service Data - 16 bit UUID
Length: 23
Type: Service Data - 16 bit UUID (0x16)
UUID 16: Google (0xfe9f)
Service Data: 026f4c574c3751686a4f4c63000001759a6c74b2
RSSI: -75dBm
No. Time Source Destination Protocol Length Info
10 0.823598 controller host HCI_EVT 24 Rcvd LE Meta (LE Advertising Report)
Frame 10: 24 bytes on wire (192 bits), 24 bytes captured (192 bits) on
interface bluetooth-monitor, id 0
Bluetooth
Bluetooth Linux Monitor Transport
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 22
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Scan Response (0x04)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: 77:fd:98:85:c9:32 (77:fd:98:85:c9:32)
Data Length: 10
Advertising Data
Manufacturer Specific
Length: 9
Type: Manufacturer Specific (0xff)
Company ID: Google (0x00e0)
Data: 0a89fa5bf176
RSSI: -75dBm
This might be some kind of BLE beacon using a random address for privacy. Apart from being registered to Google, there doesn't seem to be any other public information on its use
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 have an embedded Bluetooth 4.0 module (A Laird BT900 with uses a CSR 8811). I am trying to debug some issues that occur during discovery and connection with other devices. So I am trying to understand exactly what this device is communicating about its capabilities to others during an inquiry.
On my embedded module if I disable pairing, and then run hcitool info I see the following
$ sudo hcitool -i hci0 info 00:16:A4:0F:B9:98
Requesting information ...
BD Address: 00:16:A4:0F:B9:98
OUI Company: Ezurio Ltd (00-16-A4)
Device Name: FOO BAR
LMP Version: 4.0 (0x6) LMP Subversion: 0x2031
Manufacturer: Cambridge Silicon Radio (10)
Features page 0: 0xff 0x07 0x87 0x7e 0xd8 0x1f 0x5b 0x87
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <CVSD> <paging scheme>
<power control> <broadcast encrypt> <EDR ACL 2 Mbps>
<EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan>
<interlaced pscan> <inquiry with RSSI> <AFH cap. slave>
<AFH class. slave> <LE support> <3-slot EDR ACL>
<5-slot EDR ACL> <sniff subrating> <pause encryption>
<AFH cap. master> <AFH class. master> <extended inquiry>
<LE and BR/EDR> <simple pairing> <encapsulated PDU>
<non-flush flag> <LSTO> <inquiry TX power> <EPC>
<extended features>
Features page 1: 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00
If I set the device to pairable the output looks like this
$ sudo hcitool -i hci0 info 00:16:A4:0F:B9:98
Requesting information ...
BD Address: 00:16:A4:0F:B9:98
OUI Company: Ezurio Ltd (00-16-A4)
Device Name: FOO BAR
LMP Version: 4.0 (0x6) LMP Subversion: 0x2031
Manufacturer: Cambridge Silicon Radio (10)
Features page 0: 0xff 0x07 0x87 0x7e 0xd8 0x1f 0x5b 0x87
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <CVSD> <paging scheme>
<power control> <broadcast encrypt> <EDR ACL 2 Mbps>
<EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan>
<interlaced pscan> <inquiry with RSSI> <AFH cap. slave>
<AFH class. slave> <LE support> <3-slot EDR ACL>
<5-slot EDR ACL> <sniff subrating> <pause encryption>
<AFH cap. master> <AFH class. master> <extended inquiry>
<LE and BR/EDR> <simple pairing> <encapsulated PDU>
<non-flush flag> <LSTO> <inquiry TX power> <EPC>
<extended features>
Features page 1: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00
The only difference between these two is what is in Features page 1. In one case the first byte is 0x02, and in the other it is 0x03.
So here is my question: What is the meaning of this byte? Where can I locate documentation about these extended features? Is this something that I can only get from the vendor, or is there some standard meaning?
The answer to my question is: The extended features are documented in Table 3.3 in section section 3.3 "FEATURE MASK DEFINITION" of the Link Manager Protocol Specificiation which Volume 2 Part C the Bluetooth Core Specification v 5.2 (Pg 587). The HCI_Read_Remote_Extended_Features command is documented in sections 4.9 and 7.1.22.
I was able to find out the answer to this by performing a TCP dump, and analyzing the data in wireshark.
$ tcpdump -i bluetooth0 -w bt900_inquire_with_pairing_on.pcap &
[1] 26733
tcpdump: listening on bluetooth0, link-type BLUETOOTH_HCI_H4_WITH_PHDR (Bluetooth HCI UART transport layer plus pseudo-header), capture size 262144 bytes
$ hcitool scan
Scanning ...
00:16:A4:0F:B9:98 FOO BAR
$ sudo hcitool -i hci0 info 00:16:A4:0F:B9:98
Requesting information ...
BD Address: 00:16:A4:0F:B9:98
OUI Company: Ezurio Ltd (00-16-A4)
Device Name: FOO BAR
LMP Version: 4.0 (0x6) LMP Subversion: 0x2031
Manufacturer: Cambridge Silicon Radio (10)
Features page 0: 0xff 0x07 0x87 0x7e 0xd8 0x1f 0x5b 0x87
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <CVSD> <paging scheme>
<power control> <broadcast encrypt> <EDR ACL 2 Mbps>
<EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan>
<interlaced pscan> <inquiry with RSSI> <AFH cap. slave>
<AFH class. slave> <LE support> <3-slot EDR ACL>
<5-slot EDR ACL> <sniff subrating> <pause encryption>
<AFH cap. master> <AFH class. master> <extended inquiry>
<LE and BR/EDR> <simple pairing> <encapsulated PDU>
<non-flush flag> <LSTO> <inquiry TX power> <EPC>
<extended features>
Features page 1: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00
$ fg 1
tcpdump -i bluetooth0 -w bt900_inquire_with_pairing_on.pcap
^C44 packets captured
1021 packets received by filter
0 packets dropped by kernel
$
From wireshark I scrolled through the packets and found a sequence:
Command Status (Read Remote Supported Features)
Read Remote Supported Features
Command Status (Read Remote Extended Features)
Read Remote Extended Features Complete
This last frame contained:
Bluetooth HCI Event - Read Remote Extended Features Complete
Event Code: Read Remote Extended Features Complete (0x23)
Parameter Total Length: 13
Status: Success (0x00)
Connection Handle: 0x000c
Page Number: 1
Max. Page Number: 1
LMP Features
.... ...0 = Secure Simple Pairing Host: False
.... ..1. = LE Supported Host: True
.... .0.. = Simultaneous LE and BR/EDR to Same Device Capable Host: False
.... 0... = Secure Connections Host: False
0000 .... = Reserved: 0x0
Reserved: 00000000000000
This gave me a lot of search terms to help me find what I was looking for, and bit 1 is the "Secure Simple Pairing (Host Support) feature bit" per the LMP protocol spec.
I am having an odd problem.
I have made sip users and extensions.
Calling between them works like a charm.
The quality of sound seems to be really of… it sounds horrible.
It’s like I can almost not hear the person on the other side.
What would be the problem to a case like this?
I think (correct me if I am wrong) I did something wrong with my settings.
My settings are as followed;
sip.conf
; SIP Configuration for Asterisk
context => phones ; Default context for incoming calls. Defaults to 'default'
allowguest => yes ; Allow or reject guest calls (default is yes)
allowoverlap => yes ; Disable overlap dialing support. (Default is yes)
tcpenable => yes ; Enable server for incoming TCP connections (default is no)
tcpbindaddr => 0.0.0.0:15060 ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)
udpbindaddr => 0.0.0.0:15060 ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
transport => udp ; Set the default transports. The order determines the primary default transport.
nat => force_rport,comedia
localnet => 172.31.27.202/255.255.0.0 ; NAT SUPPORT
externaddr =>54.178.185.181 ; NAT SUPPORT
media_address => 54.178.185.181 ; NAT SUPPORT
directmedia => no
srvlookup => yes ; Enable DNS SRV lookups on outbound calls
language => ja ; Default language setting for all users/peers
rtcachefriends => yes ; realtime database settings
rtautoclear => yes ; realtime database settings
;------------------------------ quality settings --------------------------
tos_sip => cs3 ; Sets TOS for SIP packets.
tos_audio => ef ; Sets TOS for RTP audio packets.
cos_sip => 3 ; Sets 802.1p priority for SIP packets.
cos_audio => 5 ; Sets 802.1p priority for RTP audio packets.
;------------------------------ JITTER BUFFER CONFIGURATION --------------------------
jbenable => no ; Enables the use of a jitterbuffer on the receiving side of a
; SIP channel. Defaults to "no". An enabled jitterbuffer will
; be used only if the sending side can create and the receiving
; side can not accept jitter. The SIP channel can accept jitter,
; thus a jitterbuffer on the receive SIP side will be used only
; if it is forced and enabled.
; (和訳)SIPチャネルの受信側でジッタバッファを使用できるようにします。
; デフォルトは「いいえ」です。有効なジッタバッファは、送信側が作成でき、
; 受信側がジッタを受け入れることができない場合にのみ使用されます。
; SIPチャネルはジッタを受け入れることができます。
; したがって、受信SIP側のジッタバッファは、
; 強制的に有効化されている場合にのみ使用されます。
jbforce => no ; Forces the use of a jitterbuffer on the receive side of a SIP
; channel. Defaults to "no".
; (和訳)SIPチャネルの受信側でジッタバッファを強制的に使用します。
; デフォルトは「いいえ」です。
jbmaxsize => 200 ; Max length of the jitterbuffer in milliseconds.
; (和訳)ジッタバッファの最大長（ミリ秒単位）。
jbresyncthreshold => 1000 ; Jump in the frame timestamps over which the jitterbuffer is
; resynchronized. Useful to improve the quality of the voice, with
; big jumps in/broken timestamps, usually sent from exotic devices
; and programs. Defaults to 1000.
; (和訳)ジッタバッファが再同期されるフレームタイムスタンプ内をジャンプします。
; 通常はエキゾチックなデバイスやプログラムから送信される、
; 壊れたタイムスタンプの大きなジャンプで、音声の品質を向上させるのに便利です。
; デフォルトは1000です。
jbimpl => fixed ; Jitterbuffer implementation, used on the receiving side of a SIP
; channel. Two implementations are currently available - "fixed"
; (with size always equals to jbmaxsize) and "adaptive" (with
; variable size, actually the new jb of IAX2). Defaults to fixed.
; (和訳)SIPチャネルの受信側で使用されるJitterbuffer実装。
; 現在のところ、 "fixed"（サイズは常にjbmaxsizeに等しい）と
; "adaptive"（可変サイズで、実際はIAX2の新しいjb）という
; 2つの実装が利用可能です。デフォルトは固定です。
jbtargetextra => 40 ; This option only affects the jb when 'jbimpl = adaptive' is set.
; The option represents the number of milliseconds by which the new jitter buffer
; will pad its size. the default is 40, so without modification, the new
; jitter buffer will set its size to the jitter value plus 40 milliseconds.
; increasing this value may help if your network normally has low jitter,
; but occasionally has spikes.
; (和訳)このオプションは、 'jbimpl = adaptive'が設定されている場合に
; のみjbに影響します。このオプションは、新しいジッタバッファがその
; サイズを埋めるまでのミリ秒数を表します。デフォルトは40ですので、
; 変更なしでは、新しいジッタバッファはジッタ値に40ミリ秒を加えたサイズに設定されます。
; この値を大きくすると、ネットワークのジッタが通常は低くなりますが、
; 時にはスパイクが発生することがあります。
jblog => yes ; Enables jitterbuffer frame logging. Defaults to "no".
; (和訳)ジッタバッファフレームロギングをイネーブルにします。
; デフォルトは「いいえ」です。
;--------------------------- RTP timers ----------------------------------------------------
; These timers are currently used for both audio and video streams. The RTP timeouts
; are only applied to the audio channel.
; The settings are settable in the global section as well as per device.
; (和訳)これらのタイマーは、現在、オーディオストリームとビデオストリームの両方に使用されています。
; RTPタイムアウトはオーディオチャネルにのみ適用されます。
; 設定は、デバイスごとにグローバルセクションでも設定できます。
;
rtptimeout => 5 ; Terminate call if 60 seconds of no RTP or RTCP activity
; on the audio channel
; when we're not on hold. This is to be able to hangup
; a call in the case of a phone disappearing from the net,
; like a powerloss or grandma tripping over a cable.
; (和訳)保留されていないときに、オーディオチャネルでRTPまたはRTCPの
; アクティビティがない場合は、60秒間コールを終了します。
; これは、電力損失やおばあちゃんがケーブルを乗り越えるように、
; ネットから消えていく電話の場合に電話を切ることができるようにするためです。
;rtpholdtimeout => 300 ; Terminate call if 300 seconds of no RTP or RTCP activity
; on the audio channel
; when we're on hold (must be > rtptimeout)
; (和訳)保留中の場合、オーディオチャネルでRTPまたはRTCPのアクティビティがない状態で
; 300秒が経過すると、コールを終了します。 （rtptimeoutより大きくなければいけません）
;rtpkeepalive => <secs> ; Send keepalives in the RTP stream to keep NAT open
; (default is off - zero)
; (和訳)キープアライブをRTPストリームに送信して、NATを開いたままにします
; （デフォルトはオフ)
;--------------------------------codec---------------------------------------------------
;音声コーデックのGSM固定 作業者：渋谷 2018/06/26
disallow => all
allow => ulaw,alaw,gsm
;-----------------------------------------------------------------------------------
;セッション設定 作業者：あすか柴田 2018/07/23
session-expires => 1800
session-refresher => uac
[ACCOUNT-COMMON](!)
type=friend
nat=force_rport,comedia
secret=123456
canreinvite=no
dtmfmode=auto
callgroup=1
pickupgroup=1
context=phones
[1000](ACCOUNT-COMMON)
[1001](ACCOUNT-COMMON)
[1002](ACCOUNT-COMMON)
[1003](ACCOUNT-COMMON)
[1004](ACCOUNT-COMMON)
[1005](ACCOUNT-COMMON)
[1006](ACCOUNT-COMMON)
[1007](ACCOUNT-COMMON)
[1008](ACCOUNT-COMMON)
[1009](ACCOUNT-COMMON)
[1010](ACCOUNT-COMMON)
[1011](ACCOUNT-COMMON)
[1012](ACCOUNT-COMMON)
[1013](ACCOUNT-COMMON)
[1014](ACCOUNT-COMMON)
[1015](ACCOUNT-COMMON)
[1016](ACCOUNT-COMMON)
[1017](ACCOUNT-COMMON)
[1018](ACCOUNT-COMMON)
[1019](ACCOUNT-COMMON)
[1020](ACCOUNT-COMMON)
My extensions.conf
[phones]
exten => _X0XX,1,NoOp(First Line)
same => n,dumpchan()
same => n,NoOp(Second Line)
same => n,Dial(SIP/${CALLERID(dnid)}/${CALLERID(dnid)})
same => n,NoOp(dialstatus=${DIALSTATUS},causecode=${HANGUPCAUSE})
same => n,Hangup
The debug log from the client when I call
SIP Debugging enabled
<--- SIP read from UDP:111.108.30.208:62566 --->
<------------->
Really destroying SIP dialog 'e02d510346cd4db58cc2869ea3e85542' Method: REGISTER
<--- SIP read from UDP:111.108.30.208:62383 --->
<------------->
Really destroying SIP dialog '31f2d3b15ce749c38149a4443ceecc7b' Method: REGISTER
<--- SIP read from UDP:111.108.30.208:62566 --->
INVITE sip:1000#54.178.185.181:15060 SIP/2.0
Via: SIP/2.0/UDP 111.108.30.208:62566;rport;branch=z9hG4bKPj12729c1e32264a09a7651de39104bfa2
Max-Forwards: 70
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181
Contact: <sip:1000#111.108.30.208:62566;ob>
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30964 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: PJSUA v2.4 win32-6.2/i386/msvc-15.0
Content-Type: application/sdp
Content-Length: 482
v=0
o=- 3741526335 3741526335 IN IP4 192.168.100.231
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 99 104 3 0 8 9 96
c=IN IP4 192.168.100.231
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.100.231
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:99 speex/32000
a=rtpmap:104 iLBC/8000
a=fmtp:104 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
<------------->
--- (15 headers 22 lines) ---
Sending to 111.108.30.208:62566 (NAT)
Sending to 111.108.30.208:62566 (NAT)
Using INVITE request as basis request - 188d3fbfedf0444e9e528ab83ea38416
Found peer '1000' for '1000' from 111.108.30.208:62566
<--- Reliably Transmitting (NAT) to 111.108.30.208:62566 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 111.108.30.208:62566;branch=z9hG4bKPj12729c1e32264a09a7651de39104bfa2;received=111.108.30.208;rport=62566
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181;tag=as77fea572
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30964 INVITE
Server: Asterisk PBX 13.22.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="35993b20"
Content-Length: 0
<------------>
Scheduling destruction of SIP dialog '188d3fbfedf0444e9e528ab83ea38416' in 6400 ms (Method: INVITE)
<--- SIP read from UDP:111.108.30.208:62566 --->
ACK sip:1000#54.178.185.181:15060 SIP/2.0
Via: SIP/2.0/UDP 111.108.30.208:62566;rport;branch=z9hG4bKPj12729c1e32264a09a7651de39104bfa2
Max-Forwards: 70
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181;tag=as77fea572
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30964 ACK
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
<--- SIP read from TCP:111.108.30.208:63852 --->
INVITE sip:1000#54.178.185.181:15060 SIP/2.0
Via: SIP/2.0/TCP 192.168.100.231:62150;rport;branch=z9hG4bKPjcf39eb0d9b62487f9d334f67373ce98d;alias
Max-Forwards: 70
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181
Contact: <sip:1000#111.108.30.208:62566;ob>
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30965 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: PJSUA v2.4 win32-6.2/i386/msvc-15.0
Authorization: Digest username="1000", realm="asterisk", nonce="35993b20", uri="sip:1000#54.178.185.181:15060", response="e5095bf9a92eeee6668d831f904e7cb1", algorithm=MD5
Content-Type: application/sdp
Content-Length: 482
v=0
o=- 3741526335 3741526335 IN IP4 192.168.100.231
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 99 104 3 0 8 9 96
c=IN IP4 192.168.100.231
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.100.231
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:99 speex/32000
a=rtpmap:104 iLBC/8000
a=fmtp:104 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
<------------->
--- (16 headers 22 lines) ---
Sending to 111.108.30.208:63852 (NAT)
Using INVITE request as basis request - 188d3fbfedf0444e9e528ab83ea38416
Found peer '1000' for '1000' from 111.108.30.208:63852
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
Found RTP audio format 98
Found RTP audio format 97
Found RTP audio format 99
Found RTP audio format 104
Found RTP audio format 3
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 9
Found RTP audio format 96
Found audio description format speex for ID 98
Found audio description format speex for ID 97
Found audio description format speex for ID 99
Found audio description format iLBC for ID 104
Found audio description format GSM for ID 3
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G722 for ID 9
Found audio description format telephone-event for ID 96
Capabilities: us - (ulaw|alaw|gsm), peer - audio=(ulaw|gsm|alaw|g722|speex|speex16|speex32|ilbc)/video=(nothing)/text=(nothing), combined - (ulaw|alaw|gsm)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
> 0x7fd8300072c0 -- Strict RTP learning after remote address set to: 192.168.100.231:4000
Peer audio RTP is at port 192.168.100.231:4000
Looking for 1000 in phones (domain 54.178.185.181)
sip_route_dump: route/path hop: <sip:1000#111.108.30.208:62566;ob>
<--- Transmitting (NAT) to 111.108.30.208:63852 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.100.231:62150;branch=z9hG4bKPjcf39eb0d9b62487f9d334f67373ce98d;alias;received=111.108.30.208;rport=63852
From: sip:1000#192.168.80.123;tag=967faa9ed6f74b0189abfce3da60ba01
To: sip:1000#54.178.185.181
Call-ID: 188d3fbfedf0444e9e528ab83ea38416
CSeq: 30965 INVITE
Server: Asterisk PBX 13.22.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uac
Contact: <sip:1000#54.178.185.181:15060;transport=tcp>
Content-Length: 0
<------------>
-- Executing [1000#phones:1] NoOp("SIP/1000-00000004", "First Line") in new stack
-- Executing [1000#phones:2] DumpChan("SIP/1000-00000004", "") in new stack
Dumping Info For Channel: SIP/1000-00000004:
================================================================================
Info:
Name= SIP/1000-00000004
Type= SIP
UniqueID= 1532505135.6
LinkedID= 1532505135.6
CallerIDNum= 1000
CallerIDName= (N/A)
ConnectedLineIDNum= (N/A)
ConnectedLineIDName=(N/A)
DNIDDigits= 1000
RDNIS= (N/A)
Parkinglot= default
Language= ja
State= Ring (4)
Rings= 0
NativeFormat= (ulaw)
WriteFormat= ulaw
ReadFormat= ulaw
RawWriteFormat= ulaw
RawReadFormat= ulaw
WriteTranscode= No
ReadTranscode= No
1stFileDescriptor= 29
Framesin= 0
Framesout= 0
TimetoHangup= 0
ElapsedTime= 0h0m0s
BridgeID= (Not bridged)
Context= phones
Extension= 1000
Priority= 2
CallGroup= 1
PickupGroup= 1
Application= DumpChan
Data= (Empty)
Blocking_in= (Not Blocking)
Variables:
SIPCALLID=188d3fbfedf0444e9e528ab83ea38416
SIPDOMAIN=54.178.185.181
SIPURI=sip:1000#111.108.30.208:62566
================================================================================
-- Executing [1000#phones:3] NoOp("SIP/1000-00000004", "Second Line") in new stack
-- Executing [1000#phones:4] Dial("SIP/1000-00000004", "SIP/1000/1000") in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
Audio is at 25572
Adding codec ulaw to SDP
Adding codec alaw to SDP
Adding codec gsm to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 111.108.30.208:62566:
INVITE sip:1000#111.108.30.208 SIP/2.0
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK770f26db;rport
Max-Forwards: 70
From: <sip:1000#54.178.185.181:15060>;tag=as14588959
To: <sip:1000#111.108.30.208>
Contact: <sip:1000#54.178.185.181:15060>
Call-ID: 3538e60b5e8c2c1b66ef00297fd218e0#54.178.185.181:15060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.22.0
Date: Wed, 25 Jul 2018 07:52:15 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 303
v=0
o=root 1946525208 1946525208 IN IP4 54.178.185.181
s=Asterisk PBX 13.22.0
c=IN IP4 54.178.185.181
t=0 0
m=audio 25572 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
---
-- Called SIP/1000/1000
<--- SIP read from UDP:111.108.30.208:62566 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 54.178.185.181:15060;rport=15060;received=54.178.185.181;branch=z9hG4bK770f26db
Call-ID: 3538e60b5e8c2c1b66ef00297fd218e0#54.178.185.181:15060
From: <sip:1000#54.178.185.181>;tag=as14588959
To: <sip:1000#111.108.30.208>
CSeq: 102 INVITE
Content-Length: 0
<------------->
--- (7 headers 0 lines) ---
[Jul 25 16:52:15] NOTICE[1088]: chan_sip.c:15753 sip_reregister: -- Re-registration for 53065174#okj.sip.0038.net
REGISTER 12 headers, 0 lines
Reliably Transmitting (NAT) to 61.213.230.145:5060:
REGISTER sip:okj.sip.0038.net SIP/2.0
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK0b40ee91;rport
Max-Forwards: 70
From: <sip:53065174#okj.sip.0038.net>;tag=as7641fec7
To: <sip:53065174#okj.sip.0038.net>
Call-ID: 1fa69de43da6b2d9011b348e26cb4c7b#127.0.0.1
CSeq: 134 REGISTER
Supported: replaces, timer
User-Agent: Asterisk PBX 13.22.0
Authorization: Digest username="53065174", realm="okj.sip.0038.net", algorithm=MD5, uri="sip:okj.sip.0038.net", nonce="0ad266c5", response="d17a1a4a0db40775e77eeb0fcbc6581a"
Expires: 120
Contact: <sip:s#54.178.185.181:15060>
Content-Length: 0
---
<--- SIP read from UDP:61.213.230.145:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK0b40ee91;rport
From: <sip:53065174#okj.sip.0038.net>;tag=as7641fec7
To: <sip:53065174#okj.sip.0038.net>;tag=as32fa296b
Call-ID: 1fa69de43da6b2d9011b348e26cb4c7b#127.0.0.1
CSeq: 134 REGISTER
WWW-Authenticate: Digest algorithm=MD5, realm="okj.sip.0038.net", nonce="2820b83b"
Content-Length: 0
<------------->
--- (8 headers 0 lines) ---
Responding to challenge, registration to domain/host name okj.sip.0038.net
REGISTER 12 headers, 0 lines
Reliably Transmitting (NAT) to 61.213.230.145:5060:
REGISTER sip:okj.sip.0038.net SIP/2.0
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK34214824;rport
Max-Forwards: 70
From: <sip:53065174#okj.sip.0038.net>;tag=as7641fec7
To: <sip:53065174#okj.sip.0038.net>
Call-ID: 1fa69de43da6b2d9011b348e26cb4c7b#127.0.0.1
CSeq: 135 REGISTER
Supported: replaces, timer
User-Agent: Asterisk PBX 13.22.0
Authorization: Digest username="53065174", realm="okj.sip.0038.net", algorithm=MD5, uri="sip:okj.sip.0038.net", nonce="2820b83b", response="4af3e85f4d165cb5ac9a9fa697a98438"
Expires: 120
Contact: <sip:s#54.178.185.181:15060>
Content-Length: 0
---
<--- SIP read from UDP:61.213.230.145:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.178.185.181:15060;branch=z9hG4bK34214824;rport
From: <sip:53065174#okj.sip.0038.net>;tag=as7641fec7
To: <sip:53065174#okj.sip.0038.net>;tag=as32fa296b
Call-ID: 1fa69de43da6b2d9011b348e26cb4c7b#127.0.0.1
CSeq: 135 REGISTER
Expires: 120
Contact: <sip:s#54.178.185.181:15060>;expires=120
Date: Wed, 25 Jul 2018 07:52:15 GMT
Content-Length: 0
<------------->
There doesn’t seem to be any errors in the log files
What am I missing here?
How is it possible that this problem comes up.
I personally thought it has something to do with the codex,
but after hours of searching, I don’t really know it anymore.
Thank you for your input
It’s highly appreciated.
Wesley
Try add to sip.conf to ACCOUNT-COMMON section next options.
disallow=all
allow=alaw
allow=ulaw
First INVITE contain "speex" codec initiate to.
I am currently trying to send data to my STM32F0308 board via USART.
The data is supposed to be sent by a Python script using PySerial.
However, when I plug in the board, I cannot find the corresponding /dev/ttyXXXX.
The board is branched and I can flash code on it (STLink via USB), but there is no port visible.
dmesg shows that the computer is aware of the board:
[10364.101554] usb 1-3: USB disconnect, device number 10
[10368.044231] usb 1-3: new full-speed USB device number 12 using xhci_hcd
[10368.173948] usb 1-3: New USB device found, idVendor=0483, idProduct=3748
[10368.173956] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10368.173959] usb 1-3: Product: STM32 STLink
[10368.173962] usb 1-3: Manufacturer: STMicroelectronics
[10368.173965] usb 1-3: SerialNumber: VÿnIxRT68\xffffffc2\xffffff87
Here is the output of lsusb:
Bus 001 Device 012: ID 0483:3748 STMicroelectronics ST-LINK/V2
Here's the output of ls /dev/tty*:
tty tty12 tty17 tty21 tty26 tty30 tty35 tty4 tty44 tty49 tty53 tty58 tty62 ttyprintk ttyS12 ttyS17 ttyS21 ttyS26 ttyS30 ttyS7
tty0 tty13 tty18 tty22 tty27 tty31 tty36 tty40 tty45 tty5 tty54 tty59 tty63 ttyS0 ttyS13 ttyS18 ttyS22 ttyS27 ttyS31 ttyS8
tty1 tty14 tty19 tty23 tty28 tty32 tty37 tty41 tty46 tty50 tty55 tty6 tty7 ttyS1 ttyS14 ttyS19 ttyS23 ttyS28 ttyS4 ttyS9
tty10 tty15 tty2 tty24 tty29 tty33 tty38 tty42 tty47 tty51 tty56 tty60 tty8 ttyS10 ttyS15 ttyS2 ttyS24 ttyS29 ttyS5
tty11 tty16 tty20 tty25 tty3 tty34 tty39 tty43 tty48 tty52 tty57 tty61 tty9 ttyS11 ttyS16 ttyS20 ttyS25 ttyS3 ttyS6
And here is my the function to initialize the serial port:
#function to initialize the serial port
def init_serial():
global ser #must be declared in each function
#set serial: port, baudrate, timeout (port does not hang)
ser = serial.Serial(port="/dev/ttyS3", baudrate=9600, timeout=5)
if ser.isOpen():
ser.close()
#open the serial port
ser.open()
#print: port is open or closed
if ser.isOpen():
print("Port open: " + ser.portstr)
else:
print("Port not open: We have a problem!")
#function ends here
I am using Ubuntu 15.04, but it also did not work on another computer using Debian.
According to ST, the STM32F0x0 line supports USB.
Edit:
As requested, the output of lsusb -v:
Bus 001 Device 003: ID 0483:3748 STMicroelectronics ST-LINK/V2
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0483 STMicroelectronics
idProduct 0x3748 ST-LINK/V2
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
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 0x02 EP 2 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
The device gets discovered and it's a ST-Link debug interface.
The STM32F0308-Discovery does not have a USB UART interface and the ST-Link does not include UART functionality as far as I can see. What you are trying to do appears to be impossible without extra hardware. You would have to get one of those USB UART interfaces with separate connectors and wire it up to the USART pins exposed on the headers.