I have a dlink DW-157 3g dongle. I am trying to assign the same port to the dongle everytime it boots up by modifying the udev rules file. Since the dongle on boot boots up as a storage media, I have to enter the command below to eject and mount for modem mode and then other command below it to make use of the ttyUSB ports of the modem for running a dial up modem. sudo eject /dev/sr0 sudo /bin/sh -c "echo 2001 7d0e > /sys/bus/usb-serial/drivers/option1/new_id After entering these, sudo dmesg| grep ttyUSB appears as: [ 17.581264] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB1 [ 17.584470] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB2 [ 17.593854] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB3 [ 17.594869] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB4 The actual port on which I can use the modem for dial up is ttyUSB1. So, I'm trying to assign ttyUSB1 to d_uart in my udev rules file: ACTION=="add", ATTRS{idVendor}=="2001", ATTRS{idProduct}=="7d0e", SYMLINK+="d_uart" But what happens is d_uart gets assigned to ttyUSB4. What do I do to assign it to the first port always (ttyUSB1 in this case) ? Also, the output of the command for ttyUSB1,ttyUSB2,ttyUSB3 and ttyUSB4 for the comnand below: udevadm info -a -n /dev/ttyUSB4 | grep '{serial}' | head -n1 is the same. ATTRS{serial}=="3f980000.usb" Also, output of command ls -l /dev/d_uart lrwxrwxrwx 1 root root 7 Oct 3 13:27 /dev/d_uart -> ttyUSB4 lsusb output: Bus 001 Device 006: ID 2001:7d0e D-Link Corp. Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root h Output of udevadm info -n /dev/ttyUSB2: P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.3/ttyUSB2/tty/ttyUSB2 N: ttyUSB2 S: d_uart S: serial/by-id/usb-D-Link_Inc_D-Link_DWM-157-if03-port0 S: serial/by-path/platform-3f980000.usb-usb-0:1.4:1.3-port0 E: DEVLINKS=/dev/d_uart /dev/serial/by-id/usb-D-Link_Inc_D-Link_DWM-157-if03-port0 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.4:1.3-port0 E: DEVNAME=/dev/ttyUSB2 E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.3/ttyUSB2/tty/ttyUSB2 E: ID_BUS=usb E: ID_MODEL=D-Link_DWM-157 E: ID_MODEL_ENC=D-Link\x20DWM-157 E: ID_MODEL_ID=7d0e E: ID_PATH=platform-3f980000.usb-usb-0:1.4:1.3 E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_4_1_3 E: ID_REVISION=0300 E: ID_SERIAL=D-Link_Inc_D-Link_DWM-157 E: ID_TYPE=generic E: ID_USB_CLASS_FROM_DATABASE=Miscellaneous Device E: ID_USB_DRIVER=option E: ID_USB_INTERFACES=:020e00:0a0002:ff0201:ff0000:080650: E: ID_USB_INTERFACE_NUM=03 E: ID_USB_PROTOCOL_FROM_DATABASE=Interface Association E: ID_VENDOR=D-Link_Inc E: ID_VENDOR_ENC=D-Link\x2cInc\x20\x20 E: ID_VENDOR_FROM_DATABASE=D-Link Corp. E: ID_VENDOR_ID=2001 E: MAJOR=188 E: MINOR=2 E: SUBSYSTEM=tty E: TAGS=:systemd: E: USEC_INITIALIZED=978899

I have a binary file(obtained from assembly code). I need to transfer this file to an fpga serially via ttyUSB0. I read in some posts that using cat and echo data can be transferred to ttyS0.

echo -ne '\033[2J' > /dev/ttyS1  
cat  < /dev/ttyS1

Does this apply for ttyUSB0 as well? If not, please suggest me other ways to transfer binary file via ttyUSB0.

I'm trying to use a Minitel as a console to connect to my Ubuntu. I've read a lot of information about this, but it seems to work with older versions of Ubuntu. These two files : - etc/inittab - etc/gettydefs ... don't do the job for me ! My inittab: 1:2345:respawn:/sbin/agetty ttyUSB0 4800v23 My gettydefs : 4800v23# B4800 CS7 PARENB -PARODD GLOBAL # B4800 ISTRIP CS7 PARENB -PARODD GLOBAL BRKINT IGNPAR ICRNL IXON IXANY OPOST ONLCR CREAD HUPCLISIG ICANON ECHO ECHOE ECHOK #@S login: #4800v23 The result of "sudo lsusb -v" : Bus 003 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1a86 QinHeng Electronics idProduct 0x7523 HL-340 USB-Serial adapter bcdDevice 2.64 iManufacturer 0 iProduct 2 USB Serial iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0027 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 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 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered) Today I can do this : sudo stty -F /dev/ttyUSB0 4800 parenb cs7 hupcl cread ignpar clocal ixon ixoff opost onlcr isig echoe echok echoctl echoke and this : echo "Hello Minitel" > /dev/ttyUSB0 ... prints Hello Minitel on my Minitel screen. But I'm not able to have a prompt on my minitel. Thanks for your help, and sorry for my "poor english" (I'm an old french developer ;)

I recently purchased a Coolgear USB-32COM-RM 32 Port RS-232 USB-to-Serial Adapter connected to a Thinkpad T490s running Mint 21.3. Some lsusb output:

# lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 04f2:b681 Chicony Electronics Co., Ltd ThinkPad T490 Webcam
Bus 001 Device 118: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 117: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 116: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 115: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 114: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 113: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 109: ID 2109:8887 VIA Labs, Inc. 40AN
Bus 001 Device 108: ID 045e:0047 Microsoft Corp. IntelliMouse Explorer 3.0
Bus 001 Device 112: ID 17ef:3083 Lenovo ThinkPad Thunderbolt 3 Dock USB Audio
Bus 001 Device 110: ID 17ef:3081 Lenovo USB2.0 HUB
Bus 001 Device 107: ID 17ef:3080 Lenovo USB2.0 Hub             
Bus 001 Device 106: ID 17ef:3080 Lenovo USB2.0 Hub             
Bus 001 Device 003: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 10000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 2: Dev 106, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 107, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 110, If 0, Class=Hub, Driver=hub/2p, 480M
                |__ Port 2: Dev 112, If 2, Class=Audio, Driver=snd-usb-audio, 12M
                |__ Port 2: Dev 112, If 0, Class=Audio, Driver=snd-usb-audio, 12M
                |__ Port 2: Dev 112, If 3, Class=Human Interface Device, Driver=usbhid, 12M
                |__ Port 2: Dev 112, If 1, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 4: Dev 108, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 5: Dev 109, If 0, Class=, Driver=, 480M
    |__ Port 4: Dev 113, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 114, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 3: Dev 117, If 2, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 3: Dev 117, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 3: Dev 117, If 3, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 3: Dev 117, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 1: Dev 115, If 3, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 1: Dev 115, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 1: Dev 115, If 2, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 1: Dev 115, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 4: Dev 118, If 3, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 4: Dev 118, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 4: Dev 118, If 2, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 4: Dev 118, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 2: Dev 116, If 2, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 2: Dev 116, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 2: Dev 116, If 3, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
            |__ Port 2: Dev 116, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
    |__ Port 8: Dev 2, If 3, Class=Video, Driver=uvcvideo, 480M
    |__ Port 8: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 8: Dev 2, If 2, Class=Video, Driver=uvcvideo, 480M
    |__ Port 8: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 10: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 10: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M

Even though this is a 32-port device, I only see 16 /dev/ttyUSB devices:

# ls -ld /dev/ttyUSB*
crw-rw---- 1 root dialout 188,  0 Dec 12 23:02 /dev/ttyUSB0
crw-rw---- 1 root dialout 188,  1 Dec 12 23:02 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 10 Dec 12 23:02 /dev/ttyUSB10
crw-rw---- 1 root dialout 188, 11 Dec 12 23:02 /dev/ttyUSB11
crw-rw---- 1 root dialout 188, 12 Dec 12 23:02 /dev/ttyUSB12
crw-rw---- 1 root dialout 188, 13 Dec 12 23:02 /dev/ttyUSB13
crw-rw---- 1 root dialout 188, 14 Dec 12 23:02 /dev/ttyUSB14
crw-rw---- 1 root dialout 188, 15 Dec 12 23:02 /dev/ttyUSB15
crw-rw---- 1 root dialout 188,  2 Dec 12 23:02 /dev/ttyUSB2
crw-rw---- 1 root dialout 188,  3 Dec 12 23:02 /dev/ttyUSB3
crw-rw---- 1 root dialout 188,  4 Dec 12 23:02 /dev/ttyUSB4
crw-rw---- 1 root dialout 188,  5 Dec 12 23:02 /dev/ttyUSB5
crw-rw---- 1 root dialout 188,  6 Dec 12 23:02 /dev/ttyUSB6
crw-rw---- 1 root dialout 188,  7 Dec 12 23:02 /dev/ttyUSB7
crw-rw---- 1 root dialout 188,  8 Dec 12 23:02 /dev/ttyUSB8
crw-rw---- 1 root dialout 188,  9 Dec 12 23:02 /dev/ttyUSB9

Why do I only see 16 of the 32 ports? Update: I removed the case. Looks like the bottom 16 ports are working but not the top 16. I swapped one of the cables from a lower board to the top board and the front lights appeared on the top board rather than the lower board so I might just need to replace the cable. These look like USB cables but the connectors are different. The writing on the cable is "AWM 2725 80C 30V VW-1 E237114 USB(28AWGX1P+28AWGX2C) CABLETECH TECHNOLOGY". Anyone know where I can purchase these USB cables. I reached out to Coolgear as well and am waiting to hear back.

How can I utilize the RS485 port of Epever XTRA (and possibly also Tracer) series solar charge controller? I'd like to use it for monitoring as well as for easy parameter modification. The system installed on my notebook is Fedora 39 at the moment.

What I did so far. Activating the relevant driver & disabling Braille support - which seems to be often the root of the trouble. Reboot. sudo modprobe cp210x sudo apt remove brltty Confirming everything is in place: sudo lsmod | grep cp210x cp210x 36864 0 usbserial 49152 1 cp210x Plugging the device in. It is found: dmesg [ 130.776659] usbcore: registered new interface driver usbserial_generic [ 130.776672] usbserial: USB Serial support registered for generic [ 130.779299] usbcore: registered new interface driver cp210x [ 130.779324] usbserial: USB Serial support registered for cp210x [ 153.870560] usb 1-1.2: USB disconnect, device number 6 [ 169.708562] usb 1-1.2: new full-speed USB device number 7 using ehci-pci [ 169.819779] usb 1-1.2: New USB device found, idVendor=18ef, idProduct=e026, bcdDevice= 1.00 [ 169.819785] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 169.819788] usb 1-1.2: Product: EWD 100 [ 169.819790] usb 1-1.2: Manufacturer: Silicon Labs [ 169.819792] usb 1-1.2: SerialNumber: N0VNELCPLVW9SQVJ lsusb Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] Bus 001 Device 004: ID 147e:2020 Upek TouchChip Fingerprint Coprocessor (WBF advanced mode) Bus 001 Device 007: ID 18ef:e026 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse (M-BT58) Bus 003 Device 002: ID 1ab1:0c94 Rigol Technologies Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub lsusb -d 18ef:e026 -v Bus 001 Device 005: ID 18ef:e026 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x18ef idProduct 0xe026 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 EWD 100 iSerial 3 N0VNELCPLVW9SQVJ bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 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 0 bInterfaceProtocol 0 iInterface 2 EWD 100 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 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) However, nothing to be found at ls -al /dev | grep -i ttyUSB. Any ideas what further to check? I would highly appreciate it!

I'm trying to redirect the console to ttyUSB0, with the idea of later disable tty1, but I'm not getting anywhere.... I've added

GRUB_CMDLINE_LINUX="console=tty1 console=ttyUSB0,19200n8r"

To /etc/default/grub and ran update-grub, confirms it work from looking at /proc/cmdline. But nothing appears on the console, and /proc/consoles only includes:

tty1                 -WU (EC p  )    4:1

Note that if I'm able to run agetty -t10 -8 -h ttyUSB0 19200 and it works fine, I can log in from the other end (with GTKTerm). I've also added to /etc/initramfs-tools/modules (and ran update-initramfs -u)

usbserial
ftdi_sio

Thinking that the USB device is loaded too late, but that made no difference. Any idea? Anybody managed to get this working? Thanks.

I'm trying to access the serial port of ZTE MF831 cellular modem. I can access the serial port from Windows using the driver "ZTE Proprietary USB Modem" (modem.sys, ZTEusbmdm6k.sys) But I can't access it from the raspberry pi, I've tried: minicom -D /dev/ttyUSB0 -b 9600 but i can't input anything and there is no output, I've also tried to read/write using cat/echo to /dev/ttyUSB0 without success **lsusb** Bus 001 Device 011: ID 19d2:0016 ZTE WCDMA Technologies MSM ZTE Wireless Ethernet Adapter **dmesg** [13336096.289113] usb 1-1.3: new high-speed USB device number 11 using xhci_hcd [13336096.423536] usb 1-1.3: New USB device found, idVendor=19d2, idProduct=0016, bcdDevice=52.45 [13336096.423565] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [13336096.423579] usb 1-1.3: Product: ZTE Wireless Ethernet Adapter [13336096.423589] usb 1-1.3: Manufacturer: ZTE,Incorporated [13336096.444144] option 1-1.3:1.0: GSM modem (1-port) converter detected [13336096.444559] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0 > Update **sudo journalctl --follow** Oct 03 01:00:59 raspberrypi kernel: usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0 Oct 03 01:00:59 raspberrypi mtp-probe: checking bus 1, device 14: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3" Oct 03 01:00:59 raspberrypi mtp-probe: bus: 1, device: 14 was not an MTP device Oct 03 01:00:59 raspberrypi mtp-probe: checking bus 1, device 14: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3" Oct 03 01:00:59 raspberrypi mtp-probe: bus: 1, device: 14 was not an MTP device Oct 03 01:01:13 raspberrypi ModemManager: [ttyUSB0/probe] failed to parse QCDM version info command result: -7 Oct 03 01:01:13 raspberrypi ModemManager: [ttyUSB0/probe] failed to parse QCDM version info command result: -7 Oct 03 01:01:13 raspberrypi ModemManager: [device /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3] creating modem with plugin 'zte' and '1' ports Oct 03 01:01:13 raspberrypi ModemManager: [plugin/zte] could not grab port ttyUSB0: Cannot add port 'tty/ttyUSB0', unhandled port type Oct 03 01:01:13 raspberrypi ModemManager: [base-manager] couldn't create modem for device '/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3': Failed to find primary AT port **usb-devices** T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 15 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=0016 Rev=52.45 S: Manufacturer=ZTE,Incorporated S: Product=ZTE Wireless Ethernet Adapter C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms **permissions** $ id -a uid=1000(pi) gid=1000(pi) groups=1000(pi),20(dialout) $ ls -l /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 Oct 3 01:45 /dev/ttyUSB0 I've also tried to disable ModemManager and then try to connect using minicom but i get the same result

I have the following problem. Im developing an embedded system and I have two USB to UART devices (FT232). The problem is that I need to differentiate them because sometimes when booting one shows up as /dev/TTYUSB0 and others as /dev/TTYUSB1. If I use libusb to read their info its exactly the same: Bus 003 Device 028 ID 0403:6001 DeviceDescriptor { bLength: 18, bDescriptorType: 1, bcdUSB: 512, bDeviceClass: 0, bDeviceSubClass: 0, bDeviceProtocol: 0, bMaxPacketSize: 8, idVendor: 1027, idProduct: 24577, bcdDevice: 1536, iManufacturer: 1, iProduct: 2, iSerialNumber: 3, bNumConfigurations: 1 } Bus 003 Device 027 ID 0403:6001 DeviceDescriptor { bLength: 18, bDescriptorType: 1, bcdUSB: 512, bDeviceClass: 0, bDeviceSubClass: 0, bDeviceProtocol: 0, bMaxPacketSize: 8, idVendor: 1027, idProduct: 24577, bcdDevice: 1536, iManufacturer: 1, iProduct: 2, iSerialNumber: 3, bNumConfigurations: 1 } The only difference is that one is plugged to a different physical port in the hub, but as far as I know its impossible to access / talk the actual Hub to see what is connected where. The only solution would be to talk to the hub (if its even possible) and see what tty is assigned to a device on an specific physical socket? Thanks!

I am trying to set up getty to log in over serial (mainly as an experiment). With almost any configuration, the same thing happens. If my default shell is bash, I get this message after I log in:

-bash: cannot set terminal process group (15297): Inappropriate ioctl for device
-bash: no job control in this shell

and then to prove that it doesn't work, I can't use ctrl+C to stop programs:

$ sleep 30
^C

and it doesn't seem to send the signal. These are the configurations I have tried: I have tried both of these commands

# copied from raspberry pi:
sudo /sbin/agetty --keep-baud 115200,38400,9600 ttyUSB0 vt220
# something else I read somewhere
sudo getty -L ttyUSB0 9600 vt100
# (I know I'm mixing and matching a lot of differences but the result is the same)

I have tried both screen and picocom as a client. I have tried using a rasberry pi as a server, and two different ubuntu laptops. I have tried two FTDIs, two RS-485 usb adapters, and a built in RS232 on the getty side with a USB RS232 on the client side. I have also tried changing my default shell to sh and dash. I don't get the message, but ctrl+C still doesn't work as expected The funny thing is - when raspberry pi's automatically configure /dev/ttyAMA0, and it uses exactly the getty command that I have put, job control works! And the terminal settings are almost identical. (except for -iutf8 actually) here are the terminal settings with the FTDI connection, and picocom running:

$ stty -a -F /dev/ttyUSB0
speed 9600 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D;
eol = ; eol2 = ; swtch = ; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ; discard = ; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal
-crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr
-icrnl ixon ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0
tab0 bs0 vt0 ff0
isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase
-tostop -echoprt echoctl echoke -flusho -extproc
$ stty -a -F /dev/ttyUSB1
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D;
eol = ; eol2 = ; swtch = ; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal
-crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr
-icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0
cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase
-tostop -echoprt echoctl echoke -flusho -extproc

What am I doing wrong? And why does it work with the built in configuration for the built in serial port on the raspberry pi?

I previously followed the answer in this question: https://unix.stackexchange.com/questions/67936/attaching-usb-serial-device-with-custom-pid-to-ttyusb0-on-embedded?newreg=77c2eaf90f504613a637a40bd9a095b3 Now, I need to revert that step so that the device id I echoed to new_id doesn't map to ttyUSB0 every time I connect it. The file, new_id, seems to have '0403 e0d0' permanently written to it now. I've tried to use the unbind file to no luck. There's also no "remove_id" file. Only bind, new_id, uevent, and unbind. How can I revert this?

I have a STM32F4 microcontroller, with the USB interface, I connected it to the raspberry pi. When connected, it shows up as /dev/ttyACM0. I send some chars every second from the device. In windows, with putty, all works fine. I receive the chars nicely. On the raspberry pi, if I run the command: >> sudo tail -f /dev/ttyACM0 It does not show anything on the screen. In my debugger, I do see that the device does not "hang", it seems like it is sending properly. If the tail command is not running, the device (with a simple program) does hang, and the watchdog timer does time out. This behavior seems normal, as I have the same symptom in windows when putty is not listing. How to display the sent chars? Is this a problem with rights? Should I use another program? I did try some suggestions from forums: change rules in 99-com.rules, set all rights to /dev/ttyACM0`, but with no luck.

Faced with:

root@conserver01:/home/owen# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 3: Dev 5, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 4: Dev 6, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
                |__ Port 3: Dev 13, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
                |__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
                |__ Port 4: Dev 15, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
                |__ Port 2: Dev 9, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
            |__ Port 2: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
                |__ Port 4: Dev 16, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
                |__ Port 2: Dev 12, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
                |__ Port 3: Dev 14, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
                |__ Port 1: Dev 8, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
            |__ Port 3: Dev 7, If 0, Class=Hub, Driver=hub/4p, 480M
                |__ Port 1: Dev 11, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
            |__ Port 4: Dev 10, If 0, Class=Hub, Driver=hub/4p, 480M

And:

root@conserver01:/home/owen# ls -al /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jun 17 03:49 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Jun 17 03:50 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 2 Jun 17 03:51 /dev/ttyUSB2
crw-rw---- 1 root dialout 188, 3 Jun 17 03:54 /dev/ttyUSB3
crw-rw---- 1 root dialout 188, 4 Jun 17 03:54 /dev/ttyUSB4
crw-rw---- 1 root dialout 188, 5 Jun 17 03:55 /dev/ttyUSB5
crw-rw---- 1 root dialout 188, 6 Jun 14 20:20 /dev/ttyUSB6
crw-rw---- 1 root dialout 188, 7 Jun 14 20:20 /dev/ttyUSB7
crw-rw---- 1 root dialout 188, 8 Jun 14 20:20 /dev/ttyUSB8

I'd like to accomplish two things: 1. A way to match the lsusb output line to the /dev entry. 2. A way to create a consistent relationship between a port on the USB hub (or the particular FTDI adapter, either is acceptable/useful) and the /dev/ entry. Any help much appreciated. I know this is similar to at least one other previously posted question, but the question was vague and the answers look like they approach, but don't quite achieve what I want. I'm hoping that my question is more clear. Please note, also, I'm not opposed to answers that use Linux resources outside of lsusb to achieve this, that's just the tool I'm most familiar with. The non-FTDI devices are included for completeness, but they are plugged into a 16 port Genesys Logic hub which appears to be implemented as 5 4-port Genesys Logic hubs stacked together internally.

I have an Arduino board connected to a

port and recognized by Ubuntu as the

device. For programming reasons on the Arduino site, the device should be visible on Linux as the

device. This trouble could be solved by using

and the rule:

=="tty", ATTRS{idVendor}=="XXX", ATTRS{idProduct}=="YYY", MODE="0666", SYMLINK+="ttyUSBO"

written in the

/etc/udev/rules.d/99-usb-serial.rules

The Arduino board works with these settings, and everything looks good. But I want to connect the second device with a

chip. This device is automatically recognized by Ubuntu and registered as the

device. At this point, I have a mix - because I have symlink from Arduino to the

and "true"

device from the

chip. As a result, none of these devices are working correctly. When I tried to look at the

, there was a mix of data from these two devices. I tried to rename the

from the

chip by writing another

rule, but this didn't have any effect because I could only create another symlink to the

device. Renaming the

device with the

rules is impossible, according to the documentation I tried to find another way to rename the

device to the static name, e.g.,

, during connecting but failed. Can the

based chip device static name be given during its connecting or renamed it later so as not to collide with the

symlink created for Arduino?

I use several Linux servers hosts, in which multiple serial-to-USB links are plugged in. They look like /dev/ttyUSBx devices, where x is a number starting from 0. Client devices are often rebooted or go offline or are unplugged or new ones are added. This causes ttyUSB device numbering to change constantly because each new client takes lowest unused number. Can I somehow set client devices to have constant numbers? E.g. client A will be ttyUSB0, then client B will be ttyUSB1 and so on. And when client A is offline and client B reboots it will come back online as ttyUSB1, and there will be no ttyUSB0 (since it is offline). PS: hosts are either Debian or Ubuntu, mostly Debian.

I have seen that it is possible to connect two computers by USB cable and make a virtual ethernet bridge or something like that. My question is, can we do something similar but configure the connection as a SERIAL interface? To be exact: Is it possible to connect two computers with a USB cable (I do not know what the correct name is, I mean a cable that has USB-A connector on both ends) without any Serial adapter involved and then configure the usb port as a serial.

I am working on a project involving the development of a device that interfaces with multiple ttyUSB ports, specifically 16 of them. It's important to note that Linux handles ttyUSB ports differently from Windows. In Linux, ttyUSB ports are typically labeled in the order they are connected, which contrasts with Windows where each USB device consistently receives a specific and unchanging COM port number (e.g., COM7 always corresponds to the same USB device, regardless of reconnections or machine reboots). My primary objective is to ensure that the ttyUSB port numbering in Linux remains consistent even after a device reboot. However, my experiments have shown that Linux does not assign ttyUSB ports in a specific order based on USB connections. As an illustration, when examining the output of dmesg | grep tty, you can observe that usb 1-2 corresponds to ttyUSB0, and usb 1-1 starts from ttyUSB1. It's worth mentioning that usb 1-1 and usb 1-3 represents a USB-to-serial adapter with multiple serial ports. If you have any insights or suggestions on how to achieve consistent ttyUSB port numbering in Linux, I would greatly appreciate your input.

dmesg | grep tty
- [    0.241124] printk: console [tty0] enabled
- [   98.575723] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
- [  107.645192] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
- [  107.647738] usb 1-1: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB1
- [  107.703274] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB5
- [  107.718566] usb 1-1: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB2
- [  107.734340] usb 1-1: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB3
- [  107.736637] usb 1-1: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB4
- [  107.778240] usb 1-3: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB6
- [  107.831044] usb 1-3: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB7
- [  107.832354] usb 1-3: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB8
- [  107.850976] usb 1-3: Moschip 7840/7820 USB Serial Driver converter now attached to ttyUSB9

I have two serial to USB adapters connected to my computer, each one is connected to a microcontroller. What I want to do is send commands to each microcontroller through UART (I'm using minicom), but only one is succeeding. Both send data to the computer, but only one is capable of receiving it. This is the result after sending a command to one device. This is what happens with the other device. It's not that the connection is wrong, because I switched to Windows and both of them worked. Also, I have to add that the adapter started to fail when I attempted to transmit information to both devices at the same time (as *ttyUSB0* and *ttyUSB1*). It was working fine before that attempt. After that, it doesn't matter if only one is connected, one always works and the other doesn't. It is recognized by the computer as *ttyUSB0* but it never receives the information. As more evidence that it's the software that is wrong and not the hardware: the LED of the failing adapter never turns on when it's supposed to be receiving data. Edit: information about the two adapters and the microcontrollers. **Device CH341** [11208.020500] usb 3-2.3: new full-speed USB device number 23 using xhci_hcd [11208.222337] usb 3-2.3: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64 [11208.222345] usb 3-2.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [11208.222348] usb 3-2.3: Product: USB Serial [11208.232359] usb 3-2.3: ch341-uart converter now attached to ttyUSB0 **Device FT232** (the one that doesn't receive data) [11208.400547] usb 3-2.1.4: new full-speed USB device number 24 using xhci_hcd [11208.613046] usb 3-2.1.4: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00 [11208.613056] usb 3-2.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [11208.613060] usb 3-2.1.4: Product: FT232R USB UART [11208.613062] usb 3-2.1.4: Manufacturer: FTDI [11208.613065] usb 3-2.1.4: SerialNumber: A9EYI2C0 [11208.621661] usb 3-2.1.4: Detected FT232RL [11208.623137] usb 3-2.1.4: FTDI USB Serial Device converter now attached to ttyUSB1 The microcontrollers are both Black Pill boards (STM32F401)

I have more than 2 serial devices enumerated by FTDI driver as /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2 etc. On reboot, these may get jumbled up in any other order. Also, I may replace/swap these devices physically among these or with some other similar device. Now, I want a persistent enumeration for these. I want the device names to be enumerated according to the physical USB port (I may connect to the USB ports on the motherboard of the PC directly or use a USB hub) that the device is connected to - say if the devices are connected to the USB hub, port 1 should be reserved to named as ttyUSB0, port 2 as ttyUSB1 and so on. After some basic reading, I figured (as mentioned [here](https://unix.stackexchange.com/questions/68588/fixed-udev-rules-for-usb-modems)) that /dev/serial/by-path/ lists the devices as sort of a symlink. So, I created a file /etc/udev/rules.d/101-usb-serial.rules with the following: KERNEL=="ttyUSB[0-9]*", SUBSYSTEM=="tty", DRIVERS=="ftdi_sio", PATH=="pci-0000:00:14.0-usb-0:10.1:1.0", SYMLINK+="ttyUSB000" KERNEL=="ttyUSB[0-9]*", SUBSYSTEM=="tty", DRIVERS=="ftdi_sio", PATH=="pci-0000:00:14.0-usb-0:10.2:1.0", SYMLINK+="ttyUSB001" KERNEL=="ttyUSB[0-9]*", SUBSYSTEM=="tty", DRIVERS=="ftdi_sio", PATH=="pci-0000:00:14.0-usb-0:10.3:1.0", SYMLINK+="ttyUSB002" But this doesn't work. On doing ls /dev/ttyUSB* I'm unable to see the new symlinks I have created. What could possibly be going wrong?

I am currently able to connect a handheld to the PC running Linux with a very old Ubuntu 14.04, adding repository PPA for SynCE to source list. Now, the goal is to update the operating system, I chose Debian Buster where I have successfully installed the DEB packages from the same repository in its version for Ubuntu Xenial. In Debian, USB serial device is recognized and connects with ttyUSB bus, obtains an IP address and disconnects after a few seconds (two, max three). I have done a PPP debug (options debug dump & kdebug), everything seems normal: pppd options in effect: debug # (from /etc/ppp/options) kdebug 7 # (from /etc/ppp/options) logfile /tmp/pppd.log # (from /etc/ppp/options) linkname synce-device0 # (from command line) dump # (from /etc/ppp/options) noauth # (from command line) /dev/ttyUSB0 # (from command line) 115200 # (from command line) lock # (from /etc/ppp/options) connect /usr/lib/synce-core/synce-serial-chat # (from command line) record /tmp/pppd.pcap # (from /etc/ppp/options) crtscts # (from command line) local # (from command line) asyncmap 0 # (from /etc/ppp/options) lcp-echo-failure 4 # (from /etc/ppp/options) lcp-echo-interval 30 # (from /etc/ppp/options) hide-password # (from /etc/ppp/options) ms-dns xxx # [don't know how to print value] # (from command line) nodefaultroute # (from command line) 192.168.131.1:192.168.131.129 # (from command line) noipx # (from /etc/ppp/options) Removed stale lock on ttyUSB0 (pid 4366) Script /usr/lib/synce-core/synce-serial-chat finished (pid 4435), status = 0x0 Serial connection established. using channel 14 Using interface ppp0 Connect: ppp0 /dev/pts/3 rcvd [LCP ConfReq id=0x0 ] sent [LCP ConfReq id=0x1 ] sent [LCP ConfAck id=0x0 ] rcvd [LCP ConfAck id=0x1 ] sent [LCP EchoReq id=0x0 magic=0xf230f2eb] sent [CCP ConfReq id=0x1 ] sent [IPCP ConfReq id=0x1 ] rcvd [CCP ConfReq id=0x0 ] sent [CCP ConfRej id=0x0 ] rcvd [IPCP ConfReq id=0x2 ] sent [IPCP ConfRej id=0x2 ] rcvd [IPV6CP ConfReq id=0x0 ] Unsupported protocol 'IPv6 Control Protocol' (0x8057) received sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 42 83 de ff fe ae de c9] rcvd [LCP EchoRep id=0x0 magic=0x0] rcvd [CCP ConfRej id=0x1 ] sent [CCP ConfReq id=0x2] rcvd [IPCP ConfAck id=0x1 ] rcvd [CCP ConfReq id=0x1] sent [CCP ConfAck id=0x1] rcvd [IPCP ConfReq id=0x3 ] sent [IPCP ConfNak id=0x3 ] rcvd [CCP ConfNak id=0x2 ] sent [CCP ConfReq id=0x3] rcvd [IPCP ConfReq id=0x4 ] sent [IPCP ConfAck id=0x4 ] local IP address 192.168.131.1 remote IP address 192.168.131.129 Script /etc/ppp/ip-up started (pid 4444) rcvd [CCP ConfAck id=0x3] Script /etc/ppp/ip-up finished (pid 4444), status = 0x0 In UDEV, I see that after the "add" event, from the kernel, it fires a "remove", without having disconnected the device. It is striking that the event is associated only with the ppp0 network device.

KERNEL[13133.932298] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2 (usb)
KERNEL[13133.941859] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0 (usb)
KERNEL[13133.946512] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0 (usb-serial)
KERNEL[13133.946847] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 (tty)
KERNEL[13133.946887] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0 (usb-serial)
KERNEL[13133.946930] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0 (usb)
KERNEL[13133.947016] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2 (usb)
UDEV  [13133.951550] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2 (usb)
UDEV  [13133.967665] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0 (usb)
UDEV  [13133.969926] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0 (usb-serial)
UDEV  [13133.993251] add      /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 (tty)
UDEV  [13134.002291] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0 (usb-serial)
UDEV  [13134.003803] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0 (usb)
UDEV  [13134.004620] bind     /devices/pci0000:00/0000:00:06.0/usb2/2-2 (usb)
KERNEL[13134.445488] add      /devices/virtual/net/ppp0 (net)
KERNEL[13134.445509] add      /devices/virtual/net/ppp0/queues/rx-0 (queues)
KERNEL[13134.445519] add      /devices/virtual/net/ppp0/queues/tx-0 (queues)
UDEV  [13134.498959] add      /devices/virtual/net/ppp0 (net)
UDEV  [13134.510588] add      /devices/virtual/net/ppp0/queues/rx-0 (queues)
UDEV  [13134.514145] add      /devices/virtual/net/ppp0/queues/tx-0 (queues)
>
KERNEL[13137.624110] remove   /devices/virtual/net/ppp0/queues/rx-0 (queues)
KERNEL[13137.624144] remove   /devices/virtual/net/ppp0/queues/tx-0 (queues)
KERNEL[13137.624169] remove   /devices/virtual/net/ppp0 (net)
UDEV  [13137.644633] remove   /devices/virtual/net/ppp0/queues/tx-0 (queues)
UDEV  [13137.644791] remove   /devices/virtual/net/ppp0/queues/rx-0 (queues)
UDEV  [13137.659488] remove   /devices/virtual/net/ppp0 (net)

The event is related to the network interface or the network protocol, but I have not seen anything that causes it. Looked at the network traffic with Whireshark (record to pcap file), I have not found any clue. I have compared with the connection in Ubuntu and I do not see anything. In Ubuntu, despite the RSTs, the connection is never lost (see below image) On Debian, it is lost abruptly. The objective is to have a TCP/IP stable connection between the USB serial device and Linux PC: ppp0 /dev/ttyUSB0 Currently, with Debian, the connection is lost in a few seconds (two or three)... Jan 18 20:26:56 debian10 pppd: local IP address 192.168.131.1 Jan 18 20:26:56 debian10 pppd: remote IP address 192.168.131.129 Jan 18 20:26:56 debian10 dccm: DEBUG: synce_device_manager_check_interface_cb: address ready Jan 18 20:26:56 debian10 dccm: DEBUG: synce_device_manager_create_device: found device interface for /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 Jan 18 20:26:56 debian10 dccm: DEBUG: synce_device_manager_create_device: listening for device /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 Jan 18 20:26:56 debian10 dccm: DEBUG: synce_device_manager_create_device: NOT triggering connection Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_manager_client_connected_cb: have a connection to port 5679 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_manager_client_connected_cb: creating device object for /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_set_property: running for device /devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_initable_init: connecting to udev Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: info buffer length = 138 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 0: unknown: guint32 ?: 40 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 4: os_major: guint8: 6 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 5: os_minor: guint8: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 6: unknown, build number ?: guint16 ?: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 8: cpu_type: guint16: 2577 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 10: unknown: guint16 ?: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 12: unknown: guint32 ?: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 16: cur_partner_id: guint32: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 20: second partner id ?: guint32 ?: 0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 24: offset to device name: guint32: 40 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 28: offset to platform name: guint32: 74 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: offset 32: offset to model name: guint32: 104 Jan 18 20:26:57 debian10 dccm: Message: synce_device_dbus_init: registering object path '/org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0' Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_manager_device_obj_path_changed_cb: sending connected signal for /org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_dbus_init: obj_path set to /org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0 Jan 18 20:26:57 debian10 dccm: DEBUG: get_password_flag_text: setting password flags unset Jan 18 20:26:57 debian10 dccm: DEBUG: synce_device_legacy_info_received: setting CTRL_STATE_CONNECTED Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0/queues/tx-0 Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0/queues/rx-0 Jan 18 20:26:58 debian10 dccm: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0 How can I detect what is happening?, What can be the cause for the kernel to remove the ppp0 device? Any answer that helps to solve this problem will be highly appreciated, even if there is another way to connect a USB serial device, I don't know if there is.