Error detecting boards

[evanmoring]

Bug Report

Current behavior

The command arduino-cli board list

Returns this:

Error detecting boards: Error getting board list: [listing ports from discovery builtin:serial-discovery: command failed: Error while enumerating serial ports: open /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/idVendor: permission denied]

I get the same error when I try to upload compiled code.

I checked the permissions on idVendor and they seem fine: -r--r--r-- 1 root root,

I can detect and upload sketches to the board from the arduino ide.

Expected behavior

I expected it to detect my board

Environment

arduino-cli alpha Version: 0.19.3 Commit: 12f1afc Date: 2021-10-12T10:15:19Z

• OS and platform:

Ubuntu 20.04

The board is an Arduino Uno R3, same thing happended with an UNO SMD R2

Additional context

I installed using sudo snap install arduino-cli

[per1234]

I installed using sudo snap install arduino-cli

Hi @evanmoring. Thanks for your report. We don't provide support specific to the Snap installation of Arduino CLI. Please try latest nightly official build of Arduino CLI and then comment here to let us know whether the same problem still occurs.

Download links are here:
https://arduino.github.io/arduino-cli/latest/installation/#nightly-builds

The nightly build won't affect your Snap installation at all, so you are welcome to continue to use the Snap installed version of Arduino CLI for your regular usage.

[evanmoring]

Thanks for the quick response, I will give that a try. Best, Evan

…

On Wed, Nov 10, 2021 at 4:45 PM per1234 ***@***.***> wrote: I installed using sudo snap install arduino-cli Hi @evanmoring <https://github.com/evanmoring>. Thanks for your report. We don't provide support specific to the Snap installation of Arduino CLI. Please try latest nightly official build of Arduino CLI and then comment here to let us know whether the same problem still occurs. Download links are here: https://arduino.github.io/arduino-cli/latest/installation/#nightly-builds The nightly build won't affect your Snap installation at all, so you are welcome to continue to use the Snap installed version of Arduino CLI for your regular usage. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1543 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANCEY627WLHWNQZFSL7VJI3ULMGZPANCNFSM5HXFKIPA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[per1234]

There is a report of a similar error, this time using the official Arduino CLI:
https://forum.arduino.cc/t/arduino-cli-error-getting-board-list/925367

$ arduino-cli board list
Error detecting boards: Error getting board list: [listing ports from discovery builtin:serial-discovery: command failed: Error while enumerating serial ports: open /sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.1/idVendor: permission denied]

[karthikeyan-krish]

I'm have the same issure. Using ardiono-cli in Ubuntu 20.04.3. I get the same error when I ry to arduino-cli board list.

[karthikeyan-krish]

Fixed. Try adding tty and dialout group to your user.
->sudo usermod -a -G tty $USER
->sudo usermod -a -G dialout $USER
Now I can see my board.

[frederikheld]

@karthikeyan-krish's solution did not fix it for me :-(

$ arduino-cli board list
Error detecting boards: Error getting board list: [listing ports from discovery builtin:serial-discovery: command failed: Error while enumerating serial ports: open /sys/devices/pci0000:00/0000:00:08.1/0000:07:00.3/usb4/4-2/idVendor: permission denied]

Calling arduino-cli with sudo doesn't help either.

I have installed arduino-cli via snap on Ubuntu 21.04.

[silvanocerza]

@frederikheld can you try using an arduino-cli installed without snap?
We need to understand if it's an issue with the snap package or a bug in the code.

Download links to latest version are here: https://arduino.github.io/arduino-cli/0.20/installation/#latest-release

[frederikheld]

@silvanocerza: I tried with your installation method and it yielded exactly the same error.

Some feedback about your recommended installation method:

• I don't like to pipe scripts downloaded from the public web directly into sh (and I don't think we should encourage anyone to do so)
• I don't like scripts that install binaries into visible directories in my home directory (my home directory is to get work done, not to clutter it with random stuff that just lays around there)
• I don't like scripts that need me to dive into the intricate depths of unix install locations and path declarations if I want to install it somewhere else (it's a mess, we all know it, I assume that's why you chose to go the simple way and just drop it in my home dir)
• I really like automatic updates

That's why I prefer apt and snap ...

[silvanocerza]

I tried with your installation method and it yielded exactly the same error.

Good to know.

Some feedback about your recommended installation method:

I don't like to pipe scripts downloaded from the public web directly into sh (and I don't think we should encourage anyone to do so)
I don't like scripts that install binaries into visible directories in my home directory (my home directory is to get work done, not to clutter it with random stuff that just lays around there)
I don't like scripts that need me to dive into the intricate depths of unix install locations and path declarations if I want to install it somewhere else (it's a mess, we all know it, I assume that's why you chose to go the simple way and just drop it in my home dir)
I really like automatic updates

That's why I prefer apt and snap ...

No worries, you're free to install it using the method you prefer.
I just needed to understand if the issue was with the snap package, the arduino-cli in itself, or something else. I wouldn't have said to just use the other install method if it would have worked. :)

Thanks for the test by the way.

[per1234]

@evanmoring @karthikeyan-krish @frederikheld please try it again now and let us know whether you are still getting the error.

The reason I'm thinking there is a possibility it was fixed since is because there is now a new release of the builtin:serial-discovery tool (1.3.0) that is the result of a lot of development since the previous 1.3.0-rc1 release.

Arduino CLI 0.20.0 and later will automatically install and use builtin:[email protected], so you only need to make sure you are using an updated version of Arduino CLI to test it out.

[Belamat]

Hi, i ve have encountered the same issue, but in my case it only happens when im offline, if im connected to internet the boards appear as expected but if i disconnect internet the command outputs:

arduino-cli board list
Error detecting boards: Error getting board list: [listing ports from discovery builtin:mdns-discovery: command failed: mdns lookup error: failed to bind to any multicast udp port]

is this online dependency on porpoise?

[silvanocerza]

The mdns-discovery searches for ports on the local network, if you're not connected to any network it can't find boards but it shouldn't fail.

I'll open another issue to track that, thanks for the report @Belamat. 🙏

[Koryphon]

Hello,

I get the same error with arduino-cli Version: 0.20.2 Commit: 13783819 Date: 2021-12-07T16:41:50Z installed on my Mac M1 using Homebrew.

jlb@Arrakis ~ % arduino-cli board list
Error detecting boards: Error getting board list: [listing ports from discovery builtin:mdns-discovery: command failed: mdns lookup error: write udp6 [::]:62929->[ff02::fb]:5353: sendto: no route to host]

Is this to discover board with OTA ? I have 3 on my LAN and they ping.

Just downloaded the latest release from here and I get the same error:

jlb@Arrakis arduino-cli_0.20.2_macOS_64bit % ./arduino-cli board list
Error detecting boards: Error getting board list: [listing ports from discovery builtin:mdns-discovery: command failed: mdns lookup error: write udp6 [::]:55985->[ff02::fb]:5353: sendto: no route to host]

Best regards

[tmattio]

I'm having a similar error.

$ uname -a
Darwin ***** 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64
$ arduino-cli version
arduino-cli  Version: 0.21.0 Commit: 10107d24 Date: 2022-02-04T15:58:59Z
$ arduino-cli board list
Error detecting boards: Error getting board list: [listing ports from discovery builtin:mdns-discovery: command failed: mdns lookup error: write udp6 [::]:63214->[ff02::fb]:5353: sendto: no route to host]

I'm connected to the internet and have no connection problem.

Is there a workaround to this while this is resolved upstream? I have no way to upload sketches to my boards if I can't list the connected boards I think.

[tmattio]

Also, possibly naive question: why does board list need network access? Is there a way to connect a board to a computer remotely?

[silvanocerza]

Also, possibly naive question: why does board list need network access? Is there a way to connect a board to a computer remotely?

The arduino-cli runs other small tools used to discover boards, by default there are two builtin tools:

• serial-discovery
• mdns-discovery

The first one is used to find boards connected physically to your computer, while the second is used to find boards connected to the same network your computer is connected to.

When it works correctly and there is a board connected in the network it looks like this. Notice the Protocol is different, in this case you see the same board two times since it's both connected to my computer and the network.

$ arduino-cli board list
Port          Protocol Type              Board Name      FQBN                                  Core
10.130.22.139 network  Network Port      Arduino MKR1000 arduino-beta-development:samd:mkr1000 arduino-beta-development:samd
                       Network Port      Arduino MKR1000 arduino:samd:mkr1000                  arduino:samd
/dev/ttyACM0  serial   Unknown
/dev/ttyACM1  serial   Serial Port (USB) Arduino MKR1000 arduino-beta-development:samd:mkr1000 arduino-beta-development:samd
                       Serial Port (USB) Arduino MKR1000 arduino:samd:mkr1000                  arduino:samd

Is there a workaround to this while this is resolved upstream? I have no way to upload sketches to my boards if I can't list the connected boards I think.

Run the command with the --watch flag, it shouldn't return errors that way.

You have a different issues from the one reported since you can correctly run the discoveries, the problem is that one returns an error.

The issue you have is being tracked over here: arduino/mdns-discovery#24

I also created #1666 to make the Arduino CLI more resilient to this kind of failures.

[b-buckley]

Linux XXXX 5.4.0-99-generic #112-Ubuntu
arduino-cli Version: 0.21.0 Commit: 10107d2 Date: 2022-02-08T15:05:43Z

I am also experiencing this issue.

The error does not occur when there are no boards connected via usb. Plugging in an Arduino Nano and running 'arduino-cli board list' invokes the permission error.

The IDE seems to address "/dev/ttyUSBX" directly, while the enumerator is attempting to work with the sysfs representation.

It appears that the error message originates from a call to go.bug.st/serial.v1/enumerator.GetDetailedPortsList(), possibly at line 67 of board-discovery/serial.go. The enumerator package is listed as "beta"; is this an upstream bug?

[b-buckley]

Follow up: portlist.go from both the master and v1 branch of the enumerator work properly:

$ go run portlist.go
Port: /dev/ttyUSB0
USB ID : 1a86:7523
USB serial :

[cmaglie]

@b-buckley
where did you get the info about go.bug.st/serial.v1/enumerator.GetDetailedPortsList()? it's a very old version of the library, now it should use the import go.bug.st/serial

https://github.com/arduino/serial-discovery/blob/e579447d34847746413321920cac0cb5e5bb25ac/go.mod#L7

[b-buckley]

as root:
cli-log-as-root.txt
strace-log-as-root.txt

[PaulStoffregen]

@cmaglie - This may be a crazy question, maybe even heresy, but would you consider a Linux serial discovery written in C rather than Go and linked against libudev1?

[b-buckley]

Thanks for the tests @b-buckley.

I still cannot understand why the serial-discovery cannot open the /sys/.../idVendor file. This is even weirder since portlist.go, running under the same user, can open it without issues thinking

If you don't mind I would ask you to do some more tests:

* run `arduino-cli board list -v > cli-log.txt`

* run `strace -f arduino-cli board list 2> strace-log.txt`

and post here both cli-log.txt and strace-log.txt, this is a shoot in the dark to get as much data as possible, because at the moment I have no idea of what's happening...

I have an unverified suspicion that somewhere the enumerator is attempting to write to a file under /sys/ or open one for writing or execution. Which noone, not even root, can do. That read-only permission is enforced at the kernel level because the files under /sys are representations of kernel space memory and not regular files. To demonstrate:

$ sudo su
# echo baz >> /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/idVendor
bash: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/idVendor: Permission denied

[b-buckley]

I have an unverified suspicion that somewhere the enumerator is attempting to write to a file under /sys/ or open one for writing or execution. Which noone, not even root, can do. That read-only permission is enforced at the kernel level because the files under /sys are representations of kernel space memory and not regular files. To demonstrate:

$ sudo su
# echo baz >> /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/idVendor
bash: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/idVendor: Permission denied

If I'm reading the below code snippet correctly and I understand the handling of sysfs files right, if portName resolves to a SYFS file, unix.Open(portName,unix.O_RDWR...) will raise the Permission Denied error.

https://github.com/bugst/go-serial/blob/v1.3.4/serial_unix.go, starting at line 204:

func nativeOpen(portName string, mode *Mode) (*unixPort, error) {
	h, err := unix.Open(portName, unix.O_RDWR|unix.O_NOCTTY|unix.O_NDELAY, 0)
	if err != nil {
		switch err {
		case unix.EBUSY:
			return nil, &PortError{code: PortBusy}
		case unix.EACCES:
			return nil, &PortError{code: PermissionDenied}
		}
		return nil, err

[b-buckley]

$ go run portlist/portlist.go 
Port: /dev/ttyUSB0
   USB ID      : 1a86:7523
   USB serial  :

It's worth noting here that portlist.go runs cleanly against /dev/ttyUSB0. When serial-discovery fails, it's failing against /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/idVendor.

This is the source of my suspicion aimed at the use of the SYSFS

[PaulStoffregen]

@cmaglie - Here is a C-based serial discovery using libudev.

https://github.com/PaulStoffregen/serial-discovery-linux

All info comes from libudev APIs. Even if you rewrite it all in Go, maybe this can help as a template for a better way to do this on Linux?

[cmaglie]

All info comes from libudev APIs. Even if you rewrite it all in Go, maybe this can help as a template for a better way to do this on Linux?

Thanks Paul, looking at the source code I think that libudev also do lookups inside the sysfs directory.

Anyway, the really weird thing is that running portlist.go do not trigger the access denied error, instead running arduino-cli does... and in the end they run the exact same code to enumerate ports (excecpt for the fact that portlist.go interacts directly with the serial library, instead arduino-cli reach it through the serial-discovery tool).

[cmaglie]

@b-buckley are you running arduino-cli under snap? from the strace log I see

[pid 49657] execve("/usr/lib/snapd/snap-confine", ["/usr/lib/snapd/snap-confine", "--base", "core18", "snap.arduino-cli.arduino-cli", "/usr/lib/snapd/snap-exec", "arduino-cli", "board", "list"], 0xc000352480 /* 70 vars */ <unfinished ...>

if yes could you try to download from the official release?
The man page of snap-confine says:

NAME
       snap-confine - internal tool for confining snappy applications

SYNOPSIS
          snap-confine [--classic] [--base BASE] SECURITY_TAG COMMAND [...ARGUMENTS]

DESCRIPTION
       The snap-confine is a program used internally by snapd to construct the execution environment for snap applications.

[PaulStoffregen]

looking at the source code I think that libudev also do lookups inside the sysfs directory.

Ok, maybe use of libudev is just the same.

@b-buckley - any chance I could talk you into running my little libudev-based tool? Is it able to list the ports on your machine, or do you get some sort of error or just wrong results? To try it, just download here (only 2 files) and type "make" to compile and "./serial-discovery" to run. Once it's running, type "LIST" and press Enter to cause it to show JSON for the serial ports on your machine. If compiling gives an error about libudev.h missing, run "sudo apt-get install libudev-dev" to install the library header files.

If it also doesn't work using only libudev to do all the work, that's probably a sign something may be wrong with your system. If it does work, maybe there'll be some clue buried inside libudev?

[silvanocerza]

I think it would also be helpful if @b-buckley runs the Arduino CLI builtin serial-discovery and see what happens.
You should find it in this folder /home/nemo/snap/arduino-cli/17/.arduino15/packages/builtin/tools/tools/serial-discovery/1.3.1/serial-discovery.

After you open it write HELLO 1 "serial", press enter, then START_SYNC, enter again and connect the board that was causing the issue.
If any error is returned please share it here.

I think this is really a Snap permissions issues.

[cmaglie]

It seems that the snap version of the arduino-cli requires extra steps to allow it to access raw-usb and serial ports: https://snapcraft.io/arduino-cli

sudo snap connect arduino-cli:raw-usb

and

sudo snap connect arduino-cli:serial-port

[cmaglie]

And I can confirm that snap is getting in the way here, after installing the cli via snap I get:

$ arduino-cli board list
Error detecting boards: Error starting board discoveries: [starting discovery builtin:serial-discovery: command failed: Cannot START: Error while enumerating serial ports: open /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/idVendor: permission denied]
$ sudo snap connect arduino-cli:raw-usb
$ arduino-cli board list
Porta        Protocollo Tipo    Nome scheda FQBN Core
/dev/ttyS0   serial     Unknown                 
/dev/ttyS1   serial     Unknown                 
/dev/ttyS10  serial     Unknown                 
/dev/ttyS11  serial     Unknown                 
/dev/ttyS12  serial     Unknown                 
/dev/ttyS13  serial     Unknown                 
/dev/ttyS14  serial     Unknown                 
/dev/ttyS15  serial     Unknown                 
/dev/ttyS16  serial     Unknown                 
/dev/ttyS17  serial     Unknown                 
/dev/ttyS18  serial     Unknown                 
/dev/ttyS19  serial     Unknown                 
/dev/ttyS2   serial     Unknown                 
/dev/ttyS20  serial     Unknown                 
/dev/ttyS21  serial     Unknown                 
/dev/ttyS22  serial     Unknown                 
/dev/ttyS23  serial     Unknown                 
/dev/ttyS24  serial     Unknown                 
/dev/ttyS25  serial     Unknown                 
/dev/ttyS26  serial     Unknown                 
/dev/ttyS27  serial     Unknown                 
/dev/ttyS28  serial     Unknown                 
/dev/ttyS29  serial     Unknown                 
/dev/ttyS3   serial     Unknown                 
/dev/ttyS30  serial     Unknown                 
/dev/ttyS31  serial     Unknown                 
/dev/ttyS4   serial     Unknown                 
/dev/ttyS5   serial     Unknown                 
/dev/ttyS6   serial     Unknown                 
/dev/ttyS7   serial     Unknown                 
/dev/ttyS8   serial     Unknown                 
/dev/ttyS9   serial     Unknown                 
/dev/ttyUSB0 serial     Unknown                 

BTW it seems that there is still no full access to the serial port, and running the following command:

$ sudo snap connect arduino-cli:serial-port
error: snap "core" has no "serial-port" interface slots

so I'm stuck here now, BTW I think this issue should be moved to the snap maintainer now.

[PaulStoffregen]

I'm pretty sure whatever libudev is doing can list the serial ports successfully without changing permissions or groups. It even detects that /dev/ttyS0 is real hardware on my machine and the others are just placeholders, without having access to the actual device files.

Sorry if I'm being annoying with this libudev stuff. Unless there is interest expressed, I promise this will be my last message on the topic. Just wanted to help. If anyone wants to explore, feel free to use the code I published.

[cmaglie]

The question is: how can we test the libudev-based discovery under the same condition (I mean wrapped inside the constrained snap environment)

[PaulStoffregen]

Maybe like this?

make
ls -l serial-discovery
mkdir -p ~/.arduino15/packages/builtin/tools/serial-discovery/1.5.0
cp serial-discovery ~/.arduino15/packages/builtin/tools/serial-discovery/1.5.0
arduino-cli board list

[cmaglie]

Sorry if I'm being annoying with this libudev stuff

No worries, your track record of contribution shows that when you say something is because you have reasons to do so :-).

I've chatted a bit with @manchoz (the snap version maintainer) and I found that snap creates a sort of virtual filesystem that keeps track of the changes made by the main application (arduino-cli in this case). The overlay filesystem in my case resides in:

~/snap/arduino-cli/current/.arduino15/....

Another thing that I noticed is that this virtual container seems created "on-demand" on the first write attempt from arduino-cli. This means that if you have already installed the serial-discovery (with the non-snapped arduino-cli) the snapped arduinoc-li may find it already in ~/.arduino15/... and everything works fine.

So with this in mind I tried:

:~/Workspace$ arduino-cli board list
Port         Protocol Type    Board Name FQBN Core
/dev/ttyUSB0 serial   Unknown                

:~/Workspace$ gh repo clone PaulStoffregen/serial-discovery-linux
Clone in 'serial-discovery-linux' in corso...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Decompressione degli oggetti in corso: 100% (4/4), fatto.
:~/Workspace$ cd serial-discovery-linux/
:~/Workspace/serial-discovery-linux$ make
gcc -O2 -Wall -o serial-discovery serial-discovery.c -ludev -lpthread
:~/Workspace/serial-discovery-linux$ cp serial-discovery ~/.arduino15/packages/builtin/tools/serial-discovery/1.3.1/serial-discovery 
:~/Workspace/serial-discovery-linux$ arduino-cli board list
Port         Protocol Type    Board Name FQBN Core
/dev/ttyUSB0 serial   Unknown                

so far so good, but trying with the snap version:

:~/Workspace/serial-discovery-linux$ sudo snap install arduino-cli
arduino-cli 0.21.0 from manchoz installed
:~/Workspace/serial-discovery-linux$ arduino-cli board list          <-- note that the tools are installed AGAIN(!) in the virtual environment, this does not always happen I don't know why...
Updating index: library_index.json.gz scaricato                                                                                                                                                             
Updating index: library_index.json.sig scaricato                                                                                                                                                            
Updating index: package_index.json scaricato                                                                                                                                                                
Updating index: package_index.json.sig scaricato                                                                                                                                                            
Downloading missing tool builtin:[email protected]...
builtin:[email protected] scaricato                                                                                                                                                                      
Installing builtin:[email protected]...
builtin:[email protected] installato
Downloading missing tool builtin:[email protected]...
builtin:[email protected] scaricato                                                                                                                                                                      
Installing builtin:[email protected]...
builtin:[email protected] installato
Downloading missing tool builtin:[email protected]...
builtin:[email protected] scaricato                                                                                                                                                                       
Installing builtin:[email protected]...
builtin:[email protected] installato
Downloading missing tool builtin:[email protected]...
builtin:[email protected] scaricato                                                                                                                                                                    
Installing builtin:[email protected]...
builtin:[email protected] installato
Error detecting boards: Error starting board discoveries: [starting discovery builtin:serial-discovery: command failed: Cannot START: Error while enumerating serial ports: open /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/idVendor: permission denied]
:~/Workspace/serial-discovery-linux$ cp serial-discovery ~/snap/arduino-cli/current/.arduino15/packages/builtin/tools/serial-discovery/1.3.1/serial-discovery 
:~/Workspace/serial-discovery-linux$ arduino-cli board list
Error detecting boards: Error starting board discoveries: [discovery builtin:serial-discovery process not started: calling HELLO: EOF]

so the libudev based discovery crashed as well.

For now, I'll update the serial-discovery to integrate this patch: bugst/go-serial#135
@PaulStoffregen did you confirm that the libudev shows also non-fake ttySxx? it may be interesting to see how knows if they are fake or not.

[PaulStoffregen]

Oh, tried on a clean virtual machine. I believe this is the full set of commands to try the snap packaged arduino-cli.

snap install arduino-cli
arduino-cli version
arduino-cli board list

sudo apt install build-essential
sudo apt install libudev-dev
wget https://github.com/PaulStoffregen/serial-discovery-linux/archive/refs/heads/main.zip
unzip main.zip
cd serial-discovery-linux-main
make
ls -l serial-discovery
mkdir -p ~/snap/arduino-cli/current/.arduino15/packages/builtin/tools/serial-discovery/1.5.0
cp serial-discovery ~/snap/arduino-cli/current/.arduino15/packages/builtin/tools/serial-discovery/1.5.0
arduino-cli board list

[PaulStoffregen]

Can confirm, libudev definitely can tell the difference between /dev/ttyS* real hardware vs placeholders, without permissions to use the devices. The key ingredient is traversing to parent devices with udev_device_get_parent() until one is found with subsystem "pnp" (real hardware) or "platform" (fake placeholder). In the C code, look at line 267 and line 281 for those checks.

[PaulStoffregen]

Looks like serial_unix.go may be actually opening the device to check if it is real. Maybe that could have a side effect of pulsing the DTR signal?

[cmaglie]

In the C code, look at line 267 and line 281 for those checks

thanks, I'll check these ones!

Looks like serial_unix.go may be actually opening the device to check if it is real. Maybe that could have a side effect of pulsing the DTR signal?

I don't know if non-USB serial ports behave differently WRT the DTR signal, but it could likely be as you say.

[b-buckley]

serial-discovery run on its own:

$ ./serial-discovery 
HELLO 1 "serial"
{
  "eventType": "hello",
  "message": "OK",
  "protocolVersion": 1
}
START_SYNC
{
  "eventType": "start_sync",
  "message": "OK"
}
{
  "eventType": "add",
  "port": {
    "address": "/dev/ttyUSB0",
    "label": "/dev/ttyUSB0",
    "protocol": "serial",
    "protocolLabel": "Serial Port (USB)",
    "properties": {
      "pid": "0x7523",
      "serialNumber": "",
      "vid": "0x1a86"
    }
  }
}

Running arduino-cli board list installed outside snap works:

$ ~/bin/arduino-cli board list
Port         Protocol Type    Board Name FQBN Core
/dev/ttyUSB0 serial   Unknown                

Does that confirm that this is a snap issue?

[cmaglie]

Hi @b-buckley, yes it's definitely an issue of the arduino-cli packaged under snap, in particular, when snap decides to constrain the app to write his data file inside ~/snap/arduino-cli/....

In my tests, I see that snap does not always force arduino-cli to write inside ~/snap/arduino-cli/..., especially if arduino-cli is installed via snap after a previous installation of a (non-snapped) arduino-cli: in that case everything works fine. There are still some tricky aspects of snap constraints that I'm not fully understanding...

Anyway, the snap package is not maintained by Arduino, so for now you have to contact the maintainer to fix the bug or use a standalone arduino-cli.