Yevgeniy Litvinenko | 4 Dec 10:34 2009
Picon

Err#22 EINVAL when call ioctl(..,SIOCGIFHWADDR, ...);

Hi.

I've built Nmap 5.10BETA1 from source.
When I run it I get an error:
Failed to determine the MAC address of bge0!: Invalid argument (22)

truss nmap gives:
...
11146:   1.6062 so_socket(PF_INET, SOCK_DGRAM, IPPROTO_IP, 0x00000000, SOV_XPG4_2) = 4
11146:   1.6063 ioctl(4, SIOCGIFCONF, 0x08043358)               = 0
11146:   1.6063 ioctl(4, SIOCGIFNETMASK, 0x08043308)            = 0
11146:   1.6064 ioctl(4, SIOCGIFFLAGS, 0x08043308)              = 0
11146:   1.6064 ioctl(4, SIOCGIFNETMASK, 0x08043308)            = 0
11146:   1.6064 ioctl(4, SIOCGIFFLAGS, 0x08043308)              = 0
11146:   1.6065 ioctl(4, _IOWRN('i', 185, 4), 0x08043308)       Err#22 EINVAL
11146:   1.6065 fstat64(2, 0x08042300)                          = 0
...

In the source files of nmap I found this ioctl:
...
#ifdef SIOCGIFHWADDR
      memcpy(&tmpifr.ifr_addr, sin, MIN(sizeof(tmpifr.ifr_addr), sizeof(*sin)));
      rc = ioctl(sd, SIOCGIFHWADDR, &tmpifr); 
      if (rc < 0 && errno != EADDRNOTAVAIL)
        pfatal("Failed to determine the MAC address of %s!", tmpifr.ifr_name);
      else if (rc >= 0)
        memcpy(devs[count].mac, &tmpifr.ifr_addr.sa_data, 6);
#else
...

(Continue reading)

Darren Reed | 4 Dec 11:03 2009
Picon

Re: Err#22 EINVAL when call ioctl(..,SIOCGIFHWADDR, ...);

Yevgeniy Litvinenko wrote:
> Hi.
>
> I've built Nmap 5.10BETA1 from source.
> When I run it I get an error:
> Failed to determine the MAC address of bge0!: Invalid argument (22)
>
> truss nmap gives:
> ...
> 11146:   1.6062 so_socket(PF_INET, SOCK_DGRAM, IPPROTO_IP, 0x00000000, SOV_XPG4_2) = 4
> 11146:   1.6063 ioctl(4, SIOCGIFCONF, 0x08043358)               = 0
> 11146:   1.6063 ioctl(4, SIOCGIFNETMASK, 0x08043308)            = 0
> 11146:   1.6064 ioctl(4, SIOCGIFFLAGS, 0x08043308)              = 0
> 11146:   1.6064 ioctl(4, SIOCGIFNETMASK, 0x08043308)            = 0
> 11146:   1.6064 ioctl(4, SIOCGIFFLAGS, 0x08043308)              = 0
> 11146:   1.6065 ioctl(4, _IOWRN('i', 185, 4), 0x08043308)       Err#22 EINVAL
> 11146:   1.6065 fstat64(2, 0x08042300)                          = 0
> ...
>
> In the source files of nmap I found this ioctl:
> ...
> #ifdef SIOCGIFHWADDR
>       memcpy(&tmpifr.ifr_addr, sin, MIN(sizeof(tmpifr.ifr_addr), sizeof(*sin)));
>       rc = ioctl(sd, SIOCGIFHWADDR, &tmpifr); 
>       if (rc < 0 && errno != EADDRNOTAVAIL)
>         pfatal("Failed to determine the MAC address of %s!", tmpifr.ifr_name);
>       else if (rc >= 0)
>         memcpy(devs[count].mac, &tmpifr.ifr_addr.sa_data, 6);
> #else
> ...
(Continue reading)

Sebastien Roy | 4 Dec 13:53 2009
Picon

Re: Err#22 EINVAL when call ioctl(..,SIOCGIFHWADDR, ...);

On Fri, 2009-12-04 at 21:03 +1100, Darren Reed wrote:
> Yevgeniy Litvinenko wrote:
> > In OpenSolaris include files I found SIOCGIFHWADDR:
> > /usr/include/sys/sockio.h:#define	SIOCGIFHWADDR	_IOWR('i', 185, int)	/* PF_PACKET */
> >
> > Is this call (ioctl(SIOCGIFHWADDR)) valid? Or is this a bug?
> >   
> 
> At present, SIOCGIFHWADDR is only supported on PF_PACKET sockets, not 
> PF_INET sockets.

That should probably be fixed.  Since the introduction of SIOCGIFHWADDR
in build 128, all of those #ifdefs protecting its use on PF_INET sockets
in 3rd party software are now being compiled in and failing on Solaris.
This is the 2nd instance I've seen of this.

-Seb

Darren Reed | 4 Dec 14:10 2009
Picon

Re: Err#22 EINVAL when call ioctl(..,SIOCGIFHWADDR, ...);

Sebastien Roy wrote:
> On Fri, 2009-12-04 at 21:03 +1100, Darren Reed wrote:
>   
>> Yevgeniy Litvinenko wrote:
>>     
>>> In OpenSolaris include files I found SIOCGIFHWADDR:
>>> /usr/include/sys/sockio.h:#define	SIOCGIFHWADDR	_IOWR('i', 185, int)	/* PF_PACKET */
>>>
>>> Is this call (ioctl(SIOCGIFHWADDR)) valid? Or is this a bug?
>>>   
>>>       
>> At present, SIOCGIFHWADDR is only supported on PF_PACKET sockets, not 
>> PF_INET sockets.
>>     
>
> That should probably be fixed.  Since the introduction of SIOCGIFHWADDR
> in build 128, all of those #ifdefs protecting its use on PF_INET sockets
> in 3rd party software are now being compiled in and failing on Solaris.
> This is the 2nd instance I've seen of this.
>   

Given that SIOCGIFHWADDR has already been ARC'd, do you see a need to 
ARC it for use with PF_INET sockets?

Darren

James Carlson | 4 Dec 14:18 2009

Re: Err#22 EINVAL when call ioctl(..,SIOCGIFHWADDR, ...);

Darren Reed wrote:
> Sebastien Roy wrote:
>> That should probably be fixed.  Since the introduction of SIOCGIFHWADDR
>> in build 128, all of those #ifdefs protecting its use on PF_INET sockets
>> in 3rd party software are now being compiled in and failing on Solaris.
>> This is the 2nd instance I've seen of this.
>>   
> 
> Given that SIOCGIFHWADDR has already been ARC'd, do you see a need to
> ARC it for use with PF_INET sockets?

That sounds like an under-the-radar bug fix to me.

--

-- 
James Carlson         42.703N 71.076W         <carlsonj@...>
Darren Reed | 4 Dec 14:26 2009
Picon

Re: Err#22 EINVAL when call ioctl(..,SIOCGIFHWADDR, ...);

James Carlson wrote:
> Darren Reed wrote:
>   
>> Sebastien Roy wrote:
>>     
>>> That should probably be fixed.  Since the introduction of SIOCGIFHWADDR
>>> in build 128, all of those #ifdefs protecting its use on PF_INET sockets
>>> in 3rd party software are now being compiled in and failing on Solaris.
>>> This is the 2nd instance I've seen of this.
>>>   
>>>       
>> Given that SIOCGIFHWADDR has already been ARC'd, do you see a need to
>> ARC it for use with PF_INET sockets?
>>     
>
> That sounds like an under-the-radar bug fix to me.
>   

There's probably a bit of follow-on work to support it in linux branded 
zones, too.

Darren


Gmane