Re: HW address w/o connection in iphlpapi
Hi Michael,
When you boot a linux box without an ethernet connection, and eth0 configuration fails, GetAdaptersInfo does not return MAC address info for eth0. The problem seems to be that enumerateInterfaces (in dlls/iphlpapi/ifenum.c) doesn't create a record for eth0, because SIOCGIFCONF doesn't return one.
Mmm. Yeah, I think an alternative to SIOCGIFCONF might be the thing.
Wait. This works better than getifaddrs. It successfully returns info for "down" devices on my RH8 based linux box, with my creaky old wine-20050419. get_ifaddrs makes the same calls that you were, in its implementation. So it has the same problem. But it's alot easier to program with than the ioctl you used. You made comments in the source about if_indextoname having issues. So perhaps this patch won't be useful to you. But it works for us, so I'll apply it to our wine sources unless/until something better comes along. Have at it! Cheers... mo
Wait. This works better than getifaddrs. It successfully returns info for "down" devices on my RH8 based linux box, with my creaky old wine-20050419. (snip) You made comments in the source about if_indextoname having issues. So perhaps this patch won't be useful to you. But it works for us, so I'll apply it to our wine sources unless/until something better comes along.
Cool, thanks for that. Like I mention in the comments, if_nameindex has the disadvantage that it doesn't handle virtual interfaces. I'll try to hack this up to use a combination of if_nameindex and SIOCGIFCONF if I can, but feel free to beat me to it ;) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Wait. This works better than getifaddrs. It successfully returns info for "down" devices on my RH8 based linux box, with my creaky old wine-20050419. (snip)
Yikes! It turns out if_nameindex() doesn't return info for down devices, but if_indextoname() does. It's all so touchy... So, attached is an alternate patch using if_indextoname() that does work; my last one doesn't. Just for kicks I also attached a cpp file adapted from MSDN that can do a quick test. To build it do: $ wineg++ -c show-eths.cpp $ wineg++ -o show-eths.exe.so show-eths.o $ wine ./show-eths.exe.so You should get a listing for eth0 whether you boot with an ethernet connection or not. Note that to witness the problem you have to actually reboot with no ethernet connection. Just doing "ifdown eth0" isn't enough.
Cool, thanks for that. Like I mention in the comments, if_nameindex has the disadvantage that it doesn't handle virtual interfaces. I'll try to hack this up to use a combination of if_nameindex and SIOCGIFCONF if I can, but feel free to beat me to it ;)
I'm betting you'll get there first! %) ... mo
Yikes! It turns out if_nameindex() doesn't return info for down devices, but if_indextoname() does. It's all so touchy... So, attached is an alternate patch using if_indextoname() that does work; my last one doesn't.
Really? It works for me. You mean boot with no link, or what? I did that, and if_nameindex still returned eth0. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Really? It works for me. You mean boot with no link, or what? I did that, and if_nameindex still returned eth0.
Right. if_nameindex does not return eth0 if I boot up without an ethernet connection. Maybe this is a system dependent thing? I am running on a RH8 based system. The if_nameindex code looked a little nicer, but a loop on if_indextoname() is not so bad. - mo
Right. if_nameindex does not return eth0 if I boot up without an ethernet connection. Maybe this is a system dependent thing? I am running on a RH8 based system.
Or a libc thing? I'm running on FC2.
The if_nameindex code looked a little nicer, but a loop on if_indextoname() is not so bad.
Although I don't like the idea of predefined limits :) I'll probably submit a patch based on if_nameindex in the meantime, hopefully tomorrow if Alexandre commits the patch I already sent today. It removes a lot of the silliness of ifenum.c, so aside from not directly solving your problem, take a look at that and perhaps patch it. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tue, 2006-01-24 at 21:44 -0800, Juan Lang wrote:
Right. if_nameindex does not return eth0 if I boot up without an ethernet connection. Maybe this is a system dependent thing? I am running on a RH8 based system.
Or a libc thing? I'm running on FC2.
The if_nameindex code looked a little nicer, but a loop on if_indextoname() is not so bad.
Although I don't like the idea of predefined limits :) I'll probably
Me neither, which is why I used that prominent macro MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or 100?) ethernet interfaces? How about an application that needs more than 256K (showing my age with that one... %)?
submit a patch based on if_nameindex in the meantime, hopefully tomorrow
Well... that's not too thrilling since it doesn't actually fix the problem I found. Maybe we need to drill down into which systems if_nameindex works and doesn't work with and have alternate versions of enumerateInterfaces based on that. I have a FC4 system and I'll see how it behaves and let you know. ... mo
Although I don't like the idea of predefined limits :) I'll probably
Me neither, which is why I used that prominent macro MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or 100?) ethernet interfaces? How about an application that needs more than 256K (showing my age with that one... %)?
Yes, you're right, it is changeable, but it's less the number of interfaces than the value of the indexes. The interface implies that there will never be an interface with index 0, since if_nametoindex returns 0 to indicate no such interface, but what's to prevent interface indexes to be something other than 1, 2, 3, 4? They don't happen to be at the moment, but if some enterprising kernel guy decides to randomize them for some cute reason, this approach won't work.
Well... that's not too thrilling since it doesn't actually fix the problem I found.
Yep, that's the other side of the coin: your approach works on all known systems, whereas mine only works more often than the SIOCGIFCONF approach.
Maybe we need to drill down into which systems if_nameindex works and doesn't work with and have alternate versions of enumerateInterfaces based on that. I have a FC4 system and I'll see how it behaves and let you know. ... mo
Yeah, maybe so. Portability always sucks, doesn't it? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, 2006-01-25 at 10:42 -0800, Juan Lang wrote:
Although I don't like the idea of predefined limits :) I'll probably
Me neither, which is why I used that prominent macro MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or 100?) ethernet interfaces? How about an application that needs more than 256K (showing my age with that one... %)?
Yes, you're right, it is changeable, but it's less the number of interfaces than the value of the indexes. The interface implies that there will never be an interface with index 0, since if_nametoindex returns 0 to indicate no such interface, but what's to prevent interface indexes to be something other than 1, 2, 3, 4? They don't happen to be at the moment, but if some enterprising kernel guy decides to randomize them for some cute reason, this approach won't work.
Agreed. I can't find any docs explaining what indexes are legal or their order. I guess the reality is that it isn't specified. The function does seem to be provided by libc. And so the diff must be in the implementations of that. Is there any precedent in Wine of making a runtime decision based on the c library? Would you be OK with a patch that uses if_indextoname() only in the special case of glibc-2.2.93 (I believe that's the RH8 libc), but if_nameindex() otherwise? - mo
The function does seem to be provided by libc. And so the diff must be in the implementations of that. Is there any precedent in Wine of making a runtime decision based on the c library?
Probably, but see below..
Would you be OK with a patch that uses if_indextoname() only in the special case of glibc-2.2.93 (I believe that's the RH8 libc), but if_nameindex() otherwise?
I'm not the decider here, really. Alexandre is. While I'd like to see my recent patch get in because it removes a lot of unnecessary junk from ifenum.c and improves the situation for most people, it's not the end of the story. Wine's policy is to try to run on as many systems as possible, regardless of what system it was built on. From that perspective, using your approach is more correct. Assuming my patch from today gets in, feel free to improve on it. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, 2006-01-25 at 11:13 -0800, Juan Lang wrote:
I'm not the decider here, really. Alexandre is. While I'd like to see my recent patch get in because it removes a lot of unnecessary junk from ifenum.c and improves the situation for most people, it's not the end of the story. Wine's policy is to try to run on as many systems as possible, regardless of what system it was built on. From that perspective, using your approach is more correct. Assuming my patch from today gets in, feel free to improve on it.
Got it. I have something that works for my product (rh8 based, wine 20050419). I'll keep an eye on this when we get around to upgrading. I think what makes most sense is to use if_nameindex() unless it is known not to work, using if_indextoname() only as a work around. Seems like this could be done with a config flag, given that the only time you'll see the problem is on a system with the old libc which means that the wine was also built against the old libc. So a compile time flag would do the trick. Does that sound right, or does it have to be detected at runtime? - mo
participants (3)
-
Juan Lang -
Michael Ost -
most＠museresearch.com