Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)

Boost - Users mailing list
Hello,

i'm using boost asio 1.66 serial port on a Ubuntu Mate 64 machine, and I
facing the fact that open("port name", error_code) command on an already
openned port do not return an error.

My test sequence :

On the same machine I pre-open /dev/ttsS0 on minicom : minicom -D
/dev/ttyS0 and check that is indeed open by sending some chars.
Now while minicom still openned, I try openning a second minicom on same
/dev/ttyS0 and this return an error : "device /dev/ttyS0 locked" as
expected.
So the device and system is able to knows that ttyS0 is already open
(minicom + OS is capable of doing that)

Now, with first minicom still running, if I run my program which is
doing open("/dev/ttySO",ec), ec is 0 and further is-open() returns true
while obviously the port is not openned.

When device not already openned with minicom, my software is behaving
properly.

Am I doing something wrong detecting if the "open" operation suceeded ?

I have a separated boost::thread
io_thread(boost::bind(&C_IO_Controller::run,&theIOController));

that is running the boost::asio::io_service object

the open command is called from the main thread (not the io_thread )

Regards

Mathieu
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)

Boost - Users mailing list
Hello,

this probably is a linux issue.

> i'm using boost asio 1.66 serial port on a Ubuntu Mate 64 machine, and
> I facing the fact that open("port name", error_code) command on an
> already openned port do not return an error.
>
> My test sequence :
>
> On the same machine I pre-open /dev/ttsS0 on minicom : minicom -D
> /dev/ttyS0 and check that is indeed open by sending some chars.

You could use /dev/cua*-devices for this instead of /dev/ttyS*.

/dev/cua*-Devicess take exclusive use of the serial port, while /dev/ttyS* are intended for being used in interactive sessions (with a serial terminal attached).

Until recently, the linux kernel included a file Documentation/devices.txt (It was there in Linux-4.9.72) saying /dev/cua* are major 5, minor 64 and up. Newer kernels describe the cua*-devices in Documentation/admin-guide/devices.rst.

> Now while minicom still openned, I try openning a second minicom on
> same
> /dev/ttyS0 and this return an error : "device /dev/ttyS0 locked" as
> expected.

This works, because minicom uses additional locking with a lock-file. If you strace minicom, you will see, that minicom not even tried to open /dev/ttyS0.

The locking procedure for serial ports also is described in Documentation/admin-guide/devices.rst.

73, Mario
--
Mario Klebsch Actia I+ME GmbH
[hidden email] Dresdenstrasse 17/18
Fon: +49 531 38 701 716 38124 Braunschweig
Fax: +49 531 38 701 88 Germany



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
2018-01-11 12:12 GMT+03:00 Mathieu Peyr├ęga via Boost-users
<[hidden email]>:
> Hello,
>
> i'm using boost asio 1.66 serial port on a Ubuntu Mate 64 machine, and I
> facing the fact that open("port name", error_code) command on an already
> openned port do not return an error.
>

Could you please check the previous release of Boost?

For example, in my case, version 1.65.1 used on  CentOS Linux release
7.4.1708 (Core).

If ttyS0 opened with screen (screen /dev/ttyS0 115200) ASIO will not
open it with error

$ sreqrep /dev/ttyS0 "%%"
[2018-01-11 17:49:30.868] [serial] [error] Error: Device or resource busy
$

If your case related only to 1.66, then it'll be possible regression bug.

--
Best Regards,
Sergei Nikulov
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)

Boost - Users mailing list

> Could you please check the previous release of Boost?
>
> For example, in my case, version 1.65.1 used on  CentOS Linux release
> 7.4.1708 (Core).
>
> If ttyS0 opened with screen (screen /dev/ttyS0 115200) ASIO will not
> open it with error
>
> $ sreqrep /dev/ttyS0 "%%"
> [2018-01-11 17:49:30.868] [serial] [error] Error: Device or resource busy
> $
>
> If your case related only to 1.66, then it'll be possible regression bug.
>
Thanks for the people who answered !
Unfortunatly, i'm not able to try another bosot version right now. I can
not easily change boost version and have not another machine to test.
As suggested I tested starting my software and taking control of
/dev/ttyS0 and then launching screen and screen start correctly (screen
steals the control of /dev/ttyS0 to my software)
If I try to reconnect to /dev/ttyS0 while screen still running, this
time asio gives a no go (I guess screen is putting a "kernel" lock on
the file)
At this point, I guess this is more a Linux point that is really
considering /dev/ttyS0 as a regular file and allows multiple opens
unless the openning process takes a lock on it.
I added that on my serial port wrapper class through flock calls call
from #include <sys/file.h>

flock(this->m_SerialPort.native_handle(), LOCK_EX | LOCK_NB)
flock(this->m_SerialPort.native_handle(), LOCK_UN | LOCK_NB)

at adequate points. This at least prevent other software from tampering
with the serial port i just openned...

> You could use /dev/cua*-devices for this instead of /dev/ttyS*.
> /dev/cua*-Devicess take exclusive use of the serial port, while
> /dev/ttyS* are intended for being used in interactive sessions (with a
> serial terminal attached). Until recently, the linux kernel included a
> file Documentation/devices.txt (It was there in Linux-4.9.72) saying
> /dev/cua* are major 5, minor 64 and up. Newer kernels describe the
> cua*-devices in Documentation/admin-guide/devices.rst.

those files are not exposed on my machine (kernal too old)

mathieu@UbuntuMate-VirtualBox:/dev$ uname -a
Linux UbuntuMate-VirtualBox 4.4.0-67-generic #88-Ubuntu SMP Wed Mar 8
16:34:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

About minicom, it's probably getting its own internal mecanism to
prevent several instances openning same port, but not actually taking a
filesystem lock on the /dev/ttyS0 (maybe with a specific option it can
do that but the basic -D device option does not).
This means I should probably also try to see if another process is using
the file. Linux had a fuser or lsof commands for that (and therefore
could be implemented at code level) but they only reports process of the
current user (which would already be better than nothing)

Reading here
https://stackoverflow.com/questions/1048592/how-to-check-if-a-file-has-been-opened-by-another-application-in-c 
it seems that the last option would be to moutn the filesystem a special
way and add special flag to some files but that would be very platform
specific.

 From these findings, I believe boost::asio::serial_port should propose
a (default enabled) option to implement "locking" the port at open time
and checking if it's used (at least by same user) pre-open time at
library level, that would make those serial port safer as most of the
time, datastream going though serial ports are really not intended to
have multiple talkers on any side.

Regards,

Mathieu
--
tel : +33 (0)6 87 30 83 59

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users