Re: Apparent "permissions" issue with /dev/cuau0?

Hello David,

* David Wolfskill <david_at_catwhisker.org> wrote:
> This seems a bit weird to me.  I'll explain the context, then the
> perceived issue.
> 
> I maintain a port (astro/gpsman) which can make use of a serial port to
> communicate with a GPS.
> 
> The author of the program let me know earlier today that he had made a
> tarball of GPSman-6/4 available.  Accordingly, I started updating the
> port to use the new version.
> 
> While I was doing that, I noticed that there's a stanza in the port's
> Makefile:
> 
> .if ${OSVERSION} < 600000
> GPSMAN_DEFAULT_PORT?=   /dev/cuaa0
> .else
> GPSMAN_DEFAULT_PORT?=   /dev/cuad0
> .endif
> 
> and I recalled that the MPSAFE TTY layer was recently committed to HEAD,
> and that the serial device names changed accordingly.  Thus, while it
> isn't actually essential (as the user can change the device name fairlly
> readily), I thought it would be reasonable to adjust that stanza so that
> folks installing GPSman on a recent CURRENT system would at least have a
> default value that matched something on their system.
> 
> Accordingly, I changed my working copy to read:
> 
> .if ${OSVERSION} < 600000
> GPSMAN_DEFAULT_PORT?=   /dev/cuaa0
> .elif ${OSVERSION} < 800045
> GPSMAN_DEFAULT_PORT?=   /dev/cuad0
> .else
> GPSMAN_DEFAULT_PORT?=   /dev/cuau0
> .endif

Yes. That seems to be okay. I think you could already remove the cuaa0
entry, because I'm not sure if we support RELENG_5 anyway?

> I then rebooted my laptop from the CURRENT slice and tried installing
> the (updated) port.
> 
> The install was clean (as expected).  I found that I needed to move my
> old ~/.gpsman directory aside; on invocation, gpsman offered to create
> ~/.gpsman-dir (where it stashes various preferences).  I was mildly
> pleased to see that the default for the serial port showed up as
> /dev/cuau0 (as desired).
> 
> I turned on my GPS, plugged it in, tried getting gpsman to talk to it,
> and got a complaint: GPSman said that I didn't have permission (I
> *think* that was its whine, anyway).  I looked; the device was:
> 
> crw-rw----  1 uucp  dialer    0,  51 Oct 28 20:23 /dev/cuau0
> 
> and output of id(1) verified that I was in group "dialer" (specifically
> so I could do this type of thing), as expected.
>
> [snip]
> 
> I suppose I could try using ktrace(1) to get a better idea what's going
> on.  Any other (better?) ideas?

I think the best thing to try is to see what the error code is the
open() call on the TTY returned. EPERM is possible, but it's more likely
you got an ENXIO or EBUSY. You could add printf's to sys/kern/tty.c's
ttydev_open() to see where it falls through.

Another life saving tool is pstat(8). It gives you a list of TTY's on
the system. The `STATE' column should reveal some of the flags that are
currently set in the TTY, which is useful when looking through
ttydev_open(). You could also run `show all ttys' in DDB and use `show
tty <addr>' to dump all state of the TTY in question.

Please let me know if you discover any new issues/run into any problems.
Thanks!

-- 
 Ed Schouten <ed_at_80386.nl>
 WWW: http://80386.nl/