Discussion:
scanning ...wiconfig: ioctl: No such file or directory
(too old to reply)
Sverre Froyen
2009-06-20 00:37:29 UTC
Permalink
Hi,

There have been a couple of reports about wiconfig -D failing on USB devices
with the error given in the subject. See

http://mail-index.netbsd.org/tech-net/2008/03/17/msg000294.html

The problem is not a failed ioctl call but rather that an already set errno is
caught after the while loop in wi_apscan. Initializing errno before the loop
avoids the problem:


diff -u -r1.42 wiconfig.c
--- wiconfig.c 19 Apr 2009 01:52:09 -0000 1.42
+++ wiconfig.c 20 Jun 2009 00:01:19 -0000
@@ -201,6 +201,7 @@

printf("scanning ...");
fflush(stdout);
+ errno = 0;
while (ioctl(s, SIOCGWAVELAN, &ifr) == -1) {
retries--;
if (retries >= 0) {


Strangly, errno gets set by the printf("scanning...") statement just before
the loop.

Regards,
Sverre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Iain Hibbert
2009-06-20 09:56:17 UTC
Permalink
Post by Sverre Froyen
There have been a couple of reports about wiconfig -D failing on USB devices
with the error given in the subject. See
http://mail-index.netbsd.org/tech-net/2008/03/17/msg000294.html
The problem is not a failed ioctl call but rather that an already set errno is
caught after the while loop in wi_apscan. Initializing errno before the loop
diff -u -r1.42 wiconfig.c
--- wiconfig.c 19 Apr 2009 01:52:09 -0000 1.42
+++ wiconfig.c 20 Jun 2009 00:01:19 -0000
@@ -201,6 +201,7 @@
printf("scanning ...");
fflush(stdout);
+ errno = 0;
while (ioctl(s, SIOCGWAVELAN, &ifr) == -1) {
retries--;
if (retries >= 0) {
Strangly, errno gets set by the printf("scanning...") statement just before
the loop.
Good catch, though imo its unclean to use errno in this way as it only
indicates what error occurred, not the presence of an error. Although the
change is bigger, is it better to do

*** wiconfig.c.orig Thu Apr 23 19:20:46 2009
--- wiconfig.c Sat Jun 20 10:43:39 2009
***************
*** 203,220 ****
fflush(stdout);
while (ioctl(s, SIOCGWAVELAN, &ifr) == -1) {
retries--;
! if (retries >= 0) {
! printf("."); fflush(stdout);
! sleep(1);
! } else
! break;
! errno = 0;
! }

! if (errno) {
! set_if_flags(s, iface, flags);
! close(s);
! err(1, "ioctl");
}

naps = *(int *)wreq.wi_val;
--- 203,217 ----
fflush(stdout);
while (ioctl(s, SIOCGWAVELAN, &ifr) == -1) {
retries--;
! if (retries < 0) {
! set_if_flags(s, iface, flags);
! close(s);
! err(1, "ioctl");
! }

! printf(".");
! fflush(stdout);
! sleep(1);
}

naps = *(int *)wreq.wi_val;

?

iain

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Laight
2009-06-23 17:15:24 UTC
Permalink
Post by Iain Hibbert
Good catch, though imo its unclean to use errno in this way as it only
indicates what error occurred, not the presence of an error. Although the
change is bigger, is it better to do
...
Post by Iain Hibbert
while (ioctl(s, SIOCGWAVELAN, &ifr) == -1) {
retries--;
! if (retries < 0) {
! set_if_flags(s, iface, flags);
! close(s);
! err(1, "ioctl");
! }
! printf(".");
! fflush(stdout);
! sleep(1);
}
That is still (ate least IMHO) buggy sine the err() call needs to
be made before the set_if_flags() and close() since either could,
at least potentially, change errno.

I've also just had a wicked thought that a signal handler might
also run and change errno!
I wonder how that affects the checking of errno for some libc functions!

David
--
David Laight: ***@l8s.co.uk

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Iain Hibbert
2009-06-23 17:34:09 UTC
Permalink
Post by David Laight
Post by Iain Hibbert
Good catch, though imo its unclean to use errno in this way as it only
indicates what error occurred, not the presence of an error. Although the
change is bigger, is it better to do
...
Post by Iain Hibbert
while (ioctl(s, SIOCGWAVELAN, &ifr) == -1) {
retries--;
! if (retries < 0) {
! set_if_flags(s, iface, flags);
! close(s);
! err(1, "ioctl");
! }
! printf(".");
! fflush(stdout);
! sleep(1);
}
That is still (ate least IMHO) buggy sine the err() call needs to
be made before the set_if_flags() and close() since either could,
at least potentially, change errno.
I vaguely did think of that but since err() exits and does not return, if
either of set_if_flags() or close() caused an error the worst that would
happen in this case would be that the wrong error was reported..

In fact the whole loop is probably bogus anyway, I don't think
SIOCGWAVELAN will fail unless the device does not support it, in which
case its not really worth retrying.. I didn't look into that at any depth
though and I could be mistaken.
Post by David Laight
I've also just had a wicked thought that a signal handler might
also run and change errno!
luckily this program doesn't use any signal handlers :)
Post by David Laight
I wonder how that affects the checking of errno for some libc functions!
thats another reason to not examine the value of errno to detect an error

iain

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Sverre Froyen
2009-06-23 21:56:29 UTC
Permalink
Post by David Laight
Post by Iain Hibbert
Good catch, though imo its unclean to use errno in this way as it only
indicates what error occurred, not the presence of an error. Although the
change is bigger, is it better to do
...
Post by Iain Hibbert
while (ioctl(s, SIOCGWAVELAN, &ifr) == -1) {
retries--;
! if (retries < 0) {
! set_if_flags(s, iface, flags);
! close(s);
! err(1, "ioctl");
! }
! printf(".");
! fflush(stdout);
! sleep(1);
}
That is still (ate least IMHO) buggy sine the err() call needs to
be made before the set_if_flags() and close() since either could,
at least potentially, change errno.
I've also just had a wicked thought that a signal handler might
also run and change errno!
I wonder how that affects the checking of errno for some libc functions!
The errno that is set after the call to printf is from malloc calling readlink
on /etc/malloc.conf. ENOENT is exactly right.

Sverre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...