• 0

multi-user issue: failed to enumberate device


Question

I am able to find an Analog Discovery 2 using djtgcfg enum and it works fine in WaveForms  but only for a single user. Even after the WaveForms application is closed, no other users will be able to connect to the device. After a reboot a different user will be able to connect however the device will then be locked to that user until another reboot. It seems like the first user to connect to the device after a reboot will lock it out to all other users. We have tried all "On Close" device settings in the WaveForms application. We are using Waveforms Version 3.16.3 64-bit Qt5.5.1 Ubuntu 20.04.2 LTS Qt5.12.8 with a single Analog Discovery 2. 

 

Is there an ADEPT2 process that needs to be killed to allow reconnection? 

Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0

Hi @BryanS

I've just tested enumeration and connecting sequentially to one device with different users, it is working under Ubuntu 16 but not with 20.

@malexander
Could you help in this?
Edit: With second user getting ERC 3090 on DmgrEnumDevicesEx

Edited by attila
Link to post
Share on other sites
  • 0

Hi @BryanS @attila

Error code 3090 means that something failed during initialization. It works for me in Ubuntu 16 and Ubuntu 18 but I was able to replicate the issue in Ubuntu 20. It has something to do with the file locks that are created in /tmp. If I run the DmgrEnumEx with my standard account (malexander) it works fine and I can run it as many times as I want. If I run it as root then I get error code 3090. If I then execute "rm /tmp/digilent-adept2-*" to remove the files that we create in /tmp then it works again without error even if I run it with a non-root account. What's weird is that the files are all created with 777 permissions so I wouldn't expect any issue opening or locking them from another account. What's also weird is that error code 3090 doesn't show up on any other distribution that I've tested on. I'll work on finding a solution and hopefully have it fixed in the next release, which is scheduled for later this month.

Thanks,
Michael

Link to post
Share on other sites
  • 0

@BryanS @attila

I spent some time debugging this and discovered that the Adept Runtime is receiving EACCES when trying to open files with read/write permission in "/tmp". The following call results in -1 being returned when the file already exists and was created by another user, other than root:  

open("/tmp/digilent-adept2-shm-dvtbl", O_CREAT | O_RDWR, S_IRWXU | S_IRWXG | S_IRWXO );

This will ultimately lead to error code 3090 (initialization failed) because we use these files for locking while performing certain operations and if they can't be opened then the system won't function correctly.

The "/tmp" directory has permissions 1777, meaning the sticky bit is set. This means that all users have read, write, and execute permissions for all files in "/tmp" but only root or the user that created a file in "/tmp" may delete it. This is fine since our software doesn't delete the files that it creates in "/tmp". After seeing the EACCES error I decided to run some experiments using 3 different user accounts: "malexander", "adept", and "root".

Test 1: Ubuntu 20 LTS with sticky bit set for "/tmp"

1. As user "adept" execute "touch /tmp/blah.txt"
2. As user "adept" execute "chmod 777 /tmp/blah.txt"
3. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive "-bash: /tmp/blah.txt: Permission denied"
4. As user "root" execute "echo "test" > /tmp/blah.txt" and receive "-bash: /tmp/blah.txt: Permission denied"
5. As user "adept" execute "rm /tmp/blah.txt" to remove the file
6. As user "root" execute "touch /tmp/blah.txt" and "chmod 777 /tmp/blah.txt"
7. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive no error.
8. As user "adept" execute "echo "test2" >> /tmp/blah.txt" and receive no error.
9. As user "adept" cat file "/tmp/blah.txt" and see the expected text:
test
test2
10. As "root" execute "rm /tmp/blah.txt"

Test 2: Ubuntu 20 LTS with sticky bit cleared for "/tmp"
1. As user "root" execute "chmod 777 /tmp" to remove sticky bit
2. As user "adept" execute "touch /tmp/blah.txt" followed by "adept" execute "chmod 777 /tmp/blah.txt"
3. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive no error.
4. As user "root" execute "echo "test2" >> /tmp/blah.txt" and receive no error.
5. As user "adept" cat file "/tmp/blah.txt" and see the expected text:
test
test2

Test 3: On Ubuntu 20 LTS run Adept test suite DmgrEnumExt test from multiple user accounts without removing the files in "/tmp" between runs with sticky bit off.
1. First make sure that no adept files are presently in the /tmp dir by executing "rm /tmp/digilent*" as root
2. As user "adept" execute "./test DmgrEnumEx -w 2000" and get expected result:
0:    ADP3450-1
    Transport Type:  TCPIP
    Hostname:        10.1.112.148
    IP Address:      10.1.112.148
    Port:            33890
    Account:         
    Password:        
    UsrName:         ADP3450-1
    ProdName:        Analog Discovery Pro 3450
    SN:              SN:210018AFF319
    MAC Address:     MAC:00-18-3E-03-94-5E
    DCAP:            00000008
    PDID:            40720410

PASS

3. As user "malexander" execute "./test DmgrEnumEx -w 2000" and get expected result:
0:    ADP3450-1
    Transport Type:  TCPIP
    Hostname:        10.1.112.148
    IP Address:      10.1.112.148
    Port:            33890
    Account:         
    Password:        
    UsrName:         ADP3450-1
    ProdName:        Analog Discovery Pro 3450
    SN:              SN:210018AFF319
    MAC Address:     MAC:00-18-3E-03-94-5E
    DCAP:            00000008
    PDID:            40720410

PASS

Test 4: On Ubuntu 18 repeat test 1 with the sticky bit enabled (default on startup). The results under Ubuntu 18 were different. Any user can write a file that was created by another user in "/tmp" as long as the permissions for the file are set to 777. This is the behavior I expected.

Test 5: On Ubuntu 16 repeat test 1 with the sticky bit enabled (default on startup). The results under Ubuntu 18 were different. Any user can write a file that was created by another user in "/tmp" as long as the permissions for the file are set to 777. This is the behavior I expected.

Conclusion:

I think this issue is the result of a bug in Ubuntu 20. Sure, it's possible that the behavior in Ubuntu 16 and Ubuntu 18 is the result of a bug that was fixed in Ubuntu 20. However, I think that's unlikely since we've never received reports of this issue on any other distribution. Further, the code that's being executed hasn't changed in years.

I'm not sure who to contact about this issue to get it fixed upstream in Ubuntu 20 but I'll try to find someone.

For now the only workaround I can suggest for people running Ubuntu 20 is to execute "chmod 777 /tmp" as root on startup to remove the sticky bit.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now