Onion Omega 2+ ttys0 "blocked"
crispyoz last edited by
@francisco-vieira Try netstat -utnp this will show you the ports in use and the process id, but I think lsof command will be more useful since since ports are generally treated as files on *nix platforms so you may find the device listed there, then you'll also have the process id to kill.
Hi @crispyoz thank you again for your quick answer. I already try the netstat -utnp but the result it's the connections TCP/UDP Onion have and not the pid of the process that is using the tty. Lsof is not natively on Onion Omega 2+ version I have. Do you see anything that can close this "zombie" connection?
crispyoz last edited by
@francisco-vieira to install lsof, open /etc/opkg/distfeeds.conf, uncomment line 5:
src/gz openwrt_packages http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/packages
Then run opkg update then opkg install lsof
This is the tool I would use to troubleshoot this issue.
port ttyS0 is used by the Omega2s serial console.
Have you considered using the ttyS1 or ttyS2 port for communication with the modem?
@jossvall Hi, on Omega 2+ model we just have 2 tty port available and we are using the 2. One for 3g (ttyS0) and another to communicate with another CPU (ttyS1).
@francisco-vieira I'm sorry I read it wrong, you're right, the omega 2 only has two ports, what did you do to disable the omega console?
This was the result for lsof.
root@Omega-4F7D:~# lsof | grep ttyS0
It seems no process is using the ttyS0 and I have the
root@Omega-4F7D:~# gcom -d /dev/ttyS0 info
Wireless WAN Modem Configuration
comgt 14:14:00 -> -- Error Report --
comgt 14:14:00 -> ----> ^
comgt 14:14:00 -> Error @187, line 10, Could not write to COM device. (1)
@jossvall to disable the omega console just follow this link https://www.hackster.io/sidwarkd/free-up-the-serial-port-on-the-onion-omega-7b3849
crispyoz last edited by crispyoz
@francisco-vieira I wonder if the issue is that the port handshaking is up the spout. Try fixing the device using sane command. Sane doesn't fix hardware handshaking but it can fix software handshaking (xon/xoff).
You need to install coreutils-stty, then you can run the command:
stty -F /dev/ttyS0 115200 sane (115200 may not be the correct baud rate for your device)
If that doesn't fix it then look at what loadable modules may be attached to the device (lsmod) try unloading the module (rmmod) then reload the module (insmod) and see if sanity is restored.
To check on this, you can use the
devmemcommand to read the UART0 status registers. I would start with the Line Status and Modem Status registers.
See the MT7688 datasheet for more info on the registers, and run
devmem --helpon the command line to see how to read the registers.