I confirm this bug.
Here is an interesting part of a strace of the execution of wvdial:
...
open("/dev/ttyS0", O_RDWR|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
select(5, [4], [], [], {0, 0}) = 0 (Timeout)
ioctl(4, TIOCGSERIAL, 0xbfffe4a0) = 0
ioctl(4, TIOCSSERIAL, 0xbfffe460) = -1 EPERM (Operation not permitted)
ioctl(4, TCFLSH, 0x2) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_START or TCSETS, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
close(4) = 0
write(3, "--> ", 4--> ) = 4
write(3, "Cannot open /dev/ttyS0: Cannot s"..., 63Cannot open /dev/ttyS0: Cannot set information for serial port.) = 63write(3, "\n", 1
) = 1
unlink("/var/lock/LCK..ttyS0") = 0
....
So this seems to fail during an ioctl call giving an EPERM result.
(just to clarify, my user is part of dialout group so no problem of access permission to /dev/ttyS0)
--
Jérôme
