[asterisk-dev] [svn-commits] russell: branch 1.8 r353077 - /branches/1.8/main/netsock.c
Russell Bryant
russell at russellbryant.net
Sat Jan 28 20:29:06 CST 2012
On Sat, Jan 28, 2012 at 7:45 PM, Jason Parker <jparker at digium.com> wrote:
> On 01/27/2012 10:25 PM, SVN commits to the Digium repositories wrote:
>>
>> Author: russell
>> Log:
>> Update ast_set_default_eid() to find more network interfaces.
>>
>> http://domsch.com/blog/?p=455
>>
>>
>> ==============================================================================
>> --- branches/1.8/main/netsock.c (original)
>> +++ branches/1.8/main/netsock.c Fri Jan 27 22:25:25 2012
>> @@ -243,10 +243,22 @@
>> if (s< 0)
>> return;
>> for (x = 0; x< 10; x++) {
>> + static const char *prefixes[] = { "eth", "em", "pci" };
>> + unsigned int i;
>> +
>> memset(&ifr, 0, sizeof(ifr));
>> - snprintf(ifr.ifr_name, sizeof(ifr.ifr_name), "eth%d", x);
>> - if (ioctl(s, SIOCGIFHWADDR,&ifr))
>> +
>> + for (i = 0; i< ARRAY_LEN(prefixes); i++) {
>> + snprintf(ifr.ifr_name, sizeof(ifr.ifr_name),
>> "%s%d", prefixes[i], x);
>> + if (!ioctl(s, SIOCGIFHWADDR,&ifr)) {
>> + break;
>> + }
>> + }
>> +
>> + if (i == ARRAY_LEN(prefixes)) {
>> continue;
>> + }
>> +
>> memcpy(eid, ((unsigned char *)&ifr.ifr_hwaddr) + 2,
>> sizeof(*eid));
>> ast_debug(1, "Seeding global EID '%s' from '%s' using
>> 'siocgifhwaddr'\n", ast_eid_to_str(eid_str, sizeof(eid_str), eid),
>> ifr.ifr_name);
>> close(s);
>>
> This looks weird.
>
> ifr is only being reset between x iterations. ioctl may be doing weird
> things to it.
Meh ... I don't think it needs to be reset at all. It only gets read
after a successful ioctl(), so that's what matters most.
> According to the link, em is [1...N], pci is pci[1...N]#[1...N], while eth
> is still [0...N]. The pci loop can't be made efficient - would it make
> sense to loop over the lists in the opposite order? eth0, eth1, ..., em1,
> em2, ..., pci1#1, pci1#2, ..., pci2#1, ...
>
> I'm surprised the POSIX folks haven't added SIOCGIFCONF. That would be a
> much better solution to this problem.
Oops. The pci checks are wrong, then. It's doing pci0, pci1, etc.
It won't hurt anything, it's just very unlikely to do anything useful.
I'll fix it.
Efficiency here isn't a huge deal (unless it gets ridiculous). It
only runs once at startup.
--
Russell Bryant
More information about the asterisk-dev
mailing list