How to make /dev/ttyACM0 (and friends) exclusive?
Hi Everyone, I'm trying to trackdown a problem using my dialup modem. I have a program that opens the modem and watches caller id's. It flashes the hook when a telemarketer calls. It works well until... When another program opens the modem then my program starts reading intermittent responses intended for the other program. I cannot seem to open the device in exclusive mode. The current open is (I also tried with O_EXCL): int modem = open(device_path, O_RDWR | O_NOCTTY | O_SYNC); I'm not sure if it because udev configures the device incorrectly or the kernel driver is configured incorrectly. Or maybe it is impossible to do. Does anyone know how I can make the device exclusive? Thanks in advance.
On Fri, Mar 01, 2019 at 11:29:53PM -0500, Jeffrey Walton wrote:
Hi Everyone,
I'm trying to trackdown a problem using my dialup modem. I have a program that opens the modem and watches caller id's. It flashes the hook when a telemarketer calls. It works well until...
When another program opens the modem then my program starts reading intermittent responses intended for the other program.
I cannot seem to open the device in exclusive mode. The current open is (I also tried with O_EXCL):
int modem = open(device_path, O_RDWR | O_NOCTTY | O_SYNC);
I'm not sure if it because udev configures the device incorrectly or the kernel driver is configured incorrectly. Or maybe it is impossible to do.
This isn't a kernel thing, it is a userspace configuration issue. Just change the permissions of the device node such that only your one program can open it. Or, once you open it, change the permissions such that no one else can open it. Or better yet, uninstall modem manager, that's what is probably opening up the device at random points in time :) good luck! greg k-h
On Fri, 01 Mar 2019 23:29:53 -0500, Jeffrey Walton said:
I cannot seem to open the device in exclusive mode. The current open is (I also tried with O_EXCL):
int modem = open(device_path, O_RDWR | O_NOCTTY | O_SYNC);
So what happens? Does the open fail? If so, what does perror() say about it? Or does the open work but the flag is ignored? Have you tried making the *other* program open it with O_EXCL so your caller-id program can't mess with its state?
On Sat, Mar 2, 2019 at 1:45 PM <valdis.kletnieks@vt.edu> wrote:
On Fri, 01 Mar 2019 23:29:53 -0500, Jeffrey Walton said:
I cannot seem to open the device in exclusive mode. The current open is (I also tried with O_EXCL):
int modem = open(device_path, O_RDWR | O_NOCTTY | O_SYNC);
So what happens? Does the open fail? If so, what does perror() say about it? Or does the open work but the flag is ignored?
Yes, both are allowed to open the device.
Have you tried making the *other* program open it with O_EXCL so your caller-id program can't mess with its state?
Yes, I used O_EXCL . I have no control over other programs (this is the reason I can't use something like a named semaphore or lock file). I can say when I write a second test program that uses O_EXCL, it is also allowed to open the device even when the device was already opened O_EXCL. I feel like I am missing something... Does Linux consider the modem a shared resource instead of an exclusive resource? What use cases support two different programs sending commands to the modem at the same time? Jeff
On Sat, 02 Mar 2019 14:36:12 -0500, Jeffrey Walton said:
I feel like I am missing something... Does Linux consider the modem a shared resource instead of an exclusive resource? What use cases support two different programs sending commands to the modem at the same time?
The Linux kernel has exactly zero clue what a "modem" is. It's talking to a serial port, and doesn't care where the other end of the serial cable is. If you have a onboard modem, that cable may be all of 2 mm long and consist of a bunch of traces between two chips on a PCB, or even internal connections between two sides of a chip, but it's still there. So the correct question is "what use cases have two programs talking to the same serial port"? And the answer is: A lot. For a long time, there were these things called "terminals", that the younger folk may not have encountered. And a very common use case was to login via a terminal. At that point, you usually had a login shell like bash or similar running and often doing I/O to the terminal - and if you ran any sub-processes, they also would do I/O to the terminal. So consider the following bash one-liner: % for i in `seq 1 10`; do echo "Loop number $i"; date; sleep 1; done How and why does this work? (Hint 1: 'echo' is a bash builtin, Hint 2: think about how a shell handles stdin/out for child processes)
On Sun, Mar 3, 2019 at 12:55 AM <valdis.kletnieks@vt.edu> wrote:
On Sat, 02 Mar 2019 14:36:12 -0500, Jeffrey Walton said:
I feel like I am missing something... Does Linux consider the modem a shared resource instead of an exclusive resource? What use cases support two different programs sending commands to the modem at the same time?
The Linux kernel has exactly zero clue what a "modem" is. It's talking to a serial port, and doesn't care where the other end of the serial cable is. If you have a onboard modem, that cable may be all of 2 mm long and consist of a bunch of traces between two chips on a PCB, or even internal connections between two sides of a chip, but it's still there.
So the correct question is "what use cases have two programs talking to the same serial port"?
I agree about the general case of serial lines and /dev/ttySn. However... /dev/ttyACMn are modems, not serial lines. For whatever reason the kernel made a special case for the devices. The kernel knows exactly what they are. Jeff
On Sun, Mar 03, 2019 at 03:55:44AM -0500, Jeffrey Walton wrote:
On Sun, Mar 3, 2019 at 12:55 AM <valdis.kletnieks@vt.edu> wrote:
On Sat, 02 Mar 2019 14:36:12 -0500, Jeffrey Walton said:
I feel like I am missing something... Does Linux consider the modem a shared resource instead of an exclusive resource? What use cases support two different programs sending commands to the modem at the same time?
The Linux kernel has exactly zero clue what a "modem" is. It's talking to a serial port, and doesn't care where the other end of the serial cable is. If you have a onboard modem, that cable may be all of 2 mm long and consist of a bunch of traces between two chips on a PCB, or even internal connections between two sides of a chip, but it's still there.
So the correct question is "what use cases have two programs talking to the same serial port"?
I agree about the general case of serial lines and /dev/ttySn. However...
/dev/ttyACMn are modems, not serial lines. For whatever reason the kernel made a special case for the devices. The kernel knows exactly what they are.
The kernel has no idea that this is a "modem". It doesn't even know what a modem is. All it knows is that this is a tty device, and then there happens to be a driver that knows how to speak the USB ACM class protocol bound to it. Again, go delete modem manager off of your system, it is the thing that keeps opening the port up to see if you have made a valid connection on the device or not. If you write your own program to talk to the device, modem manager is not needed at all, and is known to cause this problem. greg k-h
On Sun, Mar 3, 2019 at 6:00 AM Greg KH <greg@kroah.com> wrote:
On Sun, Mar 03, 2019 at 03:55:44AM -0500, Jeffrey Walton wrote:
...
Again, go delete modem manager off of your system, it is the thing that keeps opening the port up to see if you have made a valid connection on the device or not. If you write your own program to talk to the device, modem manager is not needed at all, and is known to cause this problem.
Thanks Greg. I deleted modem manager, then ran two instances of my program. Both opened the device with O_EXCL, and both opens succeeded. They proceeded to much with one another's state. I don't think modem manager is the problem here. The first problem is the way this device is setup. An exclusive resource is being treated as a shared resource. The second problem is open silently ignores flags. Epic fail. Thanks again for the help. Jeff
On Mon, Mar 04, 2019 at 08:04:23AM -0500, Jeffrey Walton wrote:
On Sun, Mar 3, 2019 at 6:00 AM Greg KH <greg@kroah.com> wrote:
On Sun, Mar 03, 2019 at 03:55:44AM -0500, Jeffrey Walton wrote:
...
Again, go delete modem manager off of your system, it is the thing that keeps opening the port up to see if you have made a valid connection on the device or not. If you write your own program to talk to the device, modem manager is not needed at all, and is known to cause this problem.
Thanks Greg. I deleted modem manager, then ran two instances of my program. Both opened the device with O_EXCL, and both opens succeeded. They proceeded to much with one another's state.
Yes, don't do that :)
I don't think modem manager is the problem here.
The problem is your userspace is trying to open a device node twice without being _very_ careful about it :)
The first problem is the way this device is setup. An exclusive resource is being treated as a shared resource. The second problem is open silently ignores flags. Epic fail.
character device nodes do not support O_EXCL, only block device nodes do in kernels newer than 2.6. Again, the kernel is working just fine the only "failure" is a lack of reading the man page for open(2) fully :) greg k-h
Hi, Le lundi 04 mars 2019 à 08:04 -0500, Jeffrey Walton a écrit :
On Sun, Mar 3, 2019 at 6:00 AM Greg KH <greg@kroah.com> wrote:
On Sun, Mar 03, 2019 at 03:55:44AM -0500, Jeffrey Walton wrote:
...
Again, go delete modem manager off of your system, it is the thing that keeps opening the port up to see if you have made a valid connection on the device or not. If you write your own program to talk to the device, modem manager is not needed at all, and is known to cause this problem.
Thanks Greg. I deleted modem manager, then ran two instances of my program. Both opened the device with O_EXCL, and both opens succeeded. They proceeded to much with one another's state.
http://man7.org/linux/man-pages/man2/open.2.html "In general, the behavior of O_EXCL is undefined if it is used without O_CREAT. There is one exception: on Linux 2.6 and later, O_EXCL can be used without O_CREAT if pathname refers to a block device. If the block device is in use by the system (e.g., mounted), open() fails with the error EBUSY." O_EXCL is intended to be used to prevent opening an existing file. Said differently, it's used to ensure a new file is created, useful to prevent race condition, where multiple processes compete to create a file. For example think of temporary file created with random name. Regards -- Yann Droneaud OPTEYA
On Mon, 04 Mar 2019 16:38:44 +0100, Yann Droneaud said:
O_EXCL is intended to be used to prevent opening an existing file. Said differently, it's used to ensure a new file is created, useful to prevent race condition, where multiple processes compete to create a file. For example think of temporary file created with random name.
Which means that if you're trying to regulate exclusive use of a character device or similar, you use O_EXCL|O_CREAT to create a lock file, and make sure that all the programs competing for the character device use the same pathname to create the lock file - which has been a tried-and-true way of handling exclusive locking for serial ports for 4 decades now. The fact that 'strings /usr/sbin/ModemManager | grep /' proves pretty clearly that ModemManager is trusting DBus to keep track of things rather than using lock files on the modems is almost certainly part of the reason it's a steaming pile of dingo's kidneys rather than a helpful piece of software.
Hello! I'm not subscribed to this list, but I thought I would resurrect this old thread, as I ran across it on the web.
On Mon, 04 Mar 2019 16:38:44 +0100, Yann Droneaud said:
O_EXCL is intended to be used to prevent opening an existing file. Said differently, it's used to ensure a new file is created, useful to prevent race condition, where multiple processes compete to create a file. For example think of temporary file created with random name.
Which means that if you're trying to regulate exclusive use of a character device or similar, you use O_EXCL|O_CREAT to create a lock file, and make sure that all the programs competing for the character device use the same pathname to create the lock file - which has been a tried-and-true way of handling exclusive locking for serial ports for 4 decades now.
The fact that 'strings /usr/sbin/ModemManager | grep /' proves pretty clearly that ModemManager is trusting DBus to keep track of things rather than using lock files on the modems is almost certainly part of the reason it's a steaming pile of dingo's kidneys rather than a helpful piece of software.
My solution to this particular dingo terd is this: cat << EOF >> /var/udev/rules.d/81-ttyUSB_ACM_no_mm.rules KERNEL=="ttyUSB[0-9]*", ENV{ID_MM_DEVICE_IGNORE}="1" KERNEL=="ttyACM[0-9]*", ENV{ID_MM_DEVICE_IGNORE}="1" EOF Very evil indeed. I have a lot of strange devices attached to serial ports or emulating USB CDC ACM devices, and this cost me a lot of time. The funny thing is that I went CDC ACM (on one device) instead of raw URBs because I thought it would save me time, but I spent much longer trying to figure this out than I saved. Daniel
I’m grateful for having you as a friend! Sent from my iPhone
On Oct 7, 2020, at 4:41 AM, Daniel Santos <daniel.santos@pobox.com> wrote:
Hello!
I'm not subscribed to this list, but I thought I would resurrect this old thread, as I ran across it on the web.
On Mon, 04 Mar 2019 16:38:44 +0100, Yann Droneaud said:
O_EXCL is intended to be used to prevent opening an existing file. Said differently, it's used to ensure a new file is created, useful to prevent race condition, where multiple processes compete to create a file. For example think of temporary file created with random name.
Which means that if you're trying to regulate exclusive use of a character device or similar, you use O_EXCL|O_CREAT to create a lock file, and make sure that all the programs competing for the character device use the same pathname to create the lock file - which has been a tried-and-true way of handling exclusive locking for serial ports for 4 decades now.
The fact that 'strings /usr/sbin/ModemManager | grep /' proves pretty clearly that ModemManager is trusting DBus to keep track of things rather than using lock files on the modems is almost certainly part of the reason it's a steaming pile of dingo's kidneys rather than a helpful piece of software.
My solution to this particular dingo terd is this:
cat << EOF >> /var/udev/rules.d/81-ttyUSB_ACM_no_mm.rules KERNEL=="ttyUSB[0-9]*", ENV{ID_MM_DEVICE_IGNORE}="1" KERNEL=="ttyACM[0-9]*", ENV{ID_MM_DEVICE_IGNORE}="1" EOF
Very evil indeed. I have a lot of strange devices attached to serial ports or emulating USB CDC ACM devices, and this cost me a lot of time. The funny thing is that I went CDC ACM (on one device) instead of raw URBs because I thought it would save me time, but I spent much longer trying to figure this out than I saved.
Daniel
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (6)
-
Daniel Santos -
Greg KH -
Jeffrey Walton -
linux lover -
valdis.kletnieks＠vt.edu -
Yann Droneaud