On 23.07.2019 11:56, Theo de Raadt wrote: > Scott Seekamp <compli...@risei.net> wrote: > >> I purchased an inexpensive USB GPS receiver to test with time keeping on >> my OpenBSD 6.5 box. It's a "u-blox" supported by the nmea driver. >> >> Following the man pages for ldattach it says: >> >> "Specifies the name of the serial line. device should be a string of the >> form "cuaXX" or "/dev/cuaXX". >> >> cua(4) [1] devices should be used when ldattach is started from the >> command line; when started using init(8) [2], tty(4) [3] devices should >> be used." >> >> However, if I use ttyU0 as the device in /etc/ttys I never get the >> hw.sensors.nmea0 tree created. If I manually start ldattach with cuaU0 >> or put cuaU0 in /etc/ttys everything behaves as expected. > > There should never be cua devices in /etc/ttys, so something is curiously > wrong. > > Can you try playing with some of the following flags, and tell us > which ones work, from ttys(4): > > Additionally, the following flags modify the default behavior of the > terminal line. Some of these flags may not be supported by a terminal > line driver. The flag fields should not be quoted. > > local Treat the line as if it is locally connected. > > rtscts Use RTS/CTS hardware flow control, if possible. > > mdmbuf Use DTR/DCD flow control if possible. > > softcar Ignore hardware carrier on the line. > > Try all. Some of them will have similar effects.
I tested by: - unplugging the sensor - changing /etc/ttys - kill -HUP 1 - plugging sensor in and waiting 30 seconds - check sysctl output for data No difference in behavior with any of the flags above. Dmesg output of the device is: umodem0 at uhub0 port 3 configuration 1 interface 0 "u-blox AG - www.u-blox.com u-blox GNSS receiver" rev 1.10/3.01 addr 3 umodem0: data interface 1, has CM over data, has no break umodem0: status change notification available ucom0 at umodem0 I know I'm not telling you anything you don't already know, but according to the ttys manpage: > Whereas the dial-in device (the tty) normally requires a hardware signal to > indicate to the system that it is active, the dial-out device (the cua) does > not, and hence can communicate unimpeded with a device such as a modem, or > with another system over a serial link. Is it possible the sensor doesn't behave properly to tell the system it's ready? Thanks for the help! Scott
