arduino usb/com port issue

[Gary Aitken]

Ok, I've rebooted even though I didn't need to ;-)

If I start an X session as root, when I start arduino the Serial Port
menu item is live; I have the needed access and see 4 devices:
   /dev/ttyu0
   /dev/cuau0
   /dev/ttyU0
   /dev/cuaU0
In my case, /dev/cuaU0 is what responds when I have the arduino
plugged in.
The other three devices are "permanently" present;
cuaU0 only appears when the arduino is plugged in.
If I assign cuaU0 as the arduino serial device, arduino uploads to
it fine.
So all is cool if you're the supreme being.

Switching back to a normal user, the entire serial port menu item
is still greyed out, so you see no choices even though the other
three devices are still present.

As a normal user:
$ grep skinnyguy /etc/group
operator:*:5:root,skinnyguy
video:*:44:skinnyguy
dialer:*:68:skinnyguy

$ grep devfs /etc/rc.conf
# allow local rules as specified in /etc/devfs.rules (5)
devfs_system_ruleset="localrules"

$ cat /etc/devfs.rules
# Allow operator group to mount USB devices
[localrules=5]
add path 'da*' mode 0660 group operator
# for arduino hotplug USB
add path 'ugen*' mode 0660 group operator
add path 'usb/*' mode 0660 group operator
add path 'usb' mode 0770 group operator
add path 'cuaU*' mode 0770 group operator

$ ls -l /dev/cuaU0
crwxrwx---  1 uucp  operator  0xac Jun  1 17:32 /dev/cuaU0

Giving +rw access to everyone for cua* makes no difference

Did I miss something along the way, or is there yet something else
that root has that I'm missing?
On 6/1/20 9:36 AM, Tomasz CEDRO wrote:

> On Mon, Jun 1, 2020 at 5:28 PM Ian Lepore wrote:
>> There should be no need to unload ucom to access the low-level usb
>> device via libusb.  I typically have anywhere from 5-8 usb-serial
>> adapters connected at once, it would be crazy to unload ucom and lose
>> access to all of them just to use one of them with libusb.
>>
>> It is important, however, to avoid accessing /dev/cuaU# or /dev/ttyU#
>> at the same time that some application is using libusb (or libftdi) to
>> access that same device.  That would cause ucom and the work being done
>> via libusb to conflict with each other.
> 
> Exactly the problem here. Either application tries to unload kernel
> driver just to make sure terminal can connect to a dongle (linux
> quickfix), or the modem port is already opened with u3g module (more
> probable scenario). Anyway CMSIS-DAP has its own endpoint that is
> separate from VCP so it should work without unloading the module.
> 
> Will verify and send patches to the upstream no worries, thanks for
> the hints, but that could be another source of problem described by
> Gary that I found in a similar application :-)

I'm running xfce via "/usr/local/bin/startxfce4 --with-ck-launch"
Other than a bunch of xterms, a clock, and thunderbird, nothing
special.

However, I see that dbus- has four instances, and at-spi-bus-launcher
has one:

$ ps ax | grep bus
  604  -  Is      0:00.03 /usr/local/bin/dbus-daemon --system
6260  -  Is      0:00.03 /usr/local/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
6262  -  I       0:00.01 /usr/local/libexec/at-spi-bus-launcher
6263  -  S       0:00.09 /usr/local/bin/dbus-daemon --config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --nofork --p
6259 v0  I       0:00.00 /usr/local/bin/dbus-launch --sh-syntax --exit-with-session xfce4-session

Could these be interfering with user access as you hypothesize?
I don't *know* of any other apps accessing any usb port other than
the mouse.

Jun  1 17:32:30 breakaway kernel: ugen6.2: <Arduino www.arduino.cc product 0x0043> at usbus6
Jun  1 17:32:30 breakaway kernel: umodem0 on uhub3
Jun  1 17:32:30 breakaway kernel: umodem0: <Arduino www.arduino.cc product 0x0043, class 2/0, rev 1.10/0.01, addr 2> on usbus6
Jun  1 17:32:30 breakaway kernel: umodem0: data interface 1, has CM over data, has break

Is there a document describing the relationship between usb0 and
ugen6.2, umodem0, usbus6, and uhub3?  I'm guessing something like
usbusn is a physical port on uhubm which is a physical multiplexor,
and ugena.b, umodemx and usbusy are somehow mapped to usbusn, but
that's a wild guess and probably not useful (to *me*) in making
progress here.  But inquiring minds always want to know, if for
no other reason than to fight dementia :-).

Gary