当前位置: 技术问答>linux和unix
求助:为什么我我在MAC OS上 执行ioctl 函数SIOCGIFADDR的命令获取IP地址失败呢?
来源: 互联网 发布时间:2016-05-27
本文导语: ...... struct ifconf ifc; char devid[256]={0}; char is_find_dev = 0; struct ifreq buf[MAXINTERFACES]; ifc.ifc_len = sizeof(buf); ifc.ifc_buf = (caddr_t) buf; if (!ioctl(*sockfd, SIOCGIFCONF, (char *) &ifc)) { int interfac...
......
struct ifconf ifc;
char devid[256]={0};
char is_find_dev = 0;
struct ifreq buf[MAXINTERFACES];
ifc.ifc_len = sizeof(buf);
ifc.ifc_buf = (caddr_t) buf;
if (!ioctl(*sockfd, SIOCGIFCONF, (char *) &ifc))
{
int interface = ifc.ifc_len / sizeof(struct ifreq);
while (interface-- > 0)
{
if (!(ioctl(*sockfd, SIOCGIFADDR, (char *) &buf[interface])))
{
if(0 == strncmp(deviceIP->address, (char*)inet_ntoa(((struct sockaddr_in*) (&buf[interface].ifr_addr))->sin_addr),16)){
strcpy(devid,buf[interface].ifr_name);
is_find_dev = 1;
break;
}
}
else
perror("ioctl SIOCGIFADDR");
}
}
...........
interface 为15.while (interface-- > 0) 循环后,而所有设备显示ioctl SIOCGIFADDR:Device not configured.但是我用ifconfig现实有两个网卡在工作啊,一个LAN一个WIFI网卡。能上网。
struct ifconf ifc;
char devid[256]={0};
char is_find_dev = 0;
struct ifreq buf[MAXINTERFACES];
ifc.ifc_len = sizeof(buf);
ifc.ifc_buf = (caddr_t) buf;
if (!ioctl(*sockfd, SIOCGIFCONF, (char *) &ifc))
{
int interface = ifc.ifc_len / sizeof(struct ifreq);
while (interface-- > 0)
{
if (!(ioctl(*sockfd, SIOCGIFADDR, (char *) &buf[interface])))
{
if(0 == strncmp(deviceIP->address, (char*)inet_ntoa(((struct sockaddr_in*) (&buf[interface].ifr_addr))->sin_addr),16)){
strcpy(devid,buf[interface].ifr_name);
is_find_dev = 1;
break;
}
}
else
perror("ioctl SIOCGIFADDR");
}
}
...........
interface 为15.while (interface-- > 0) 循环后,而所有设备显示ioctl SIOCGIFADDR:Device not configured.但是我用ifconfig现实有两个网卡在工作啊,一个LAN一个WIFI网卡。能上网。
|
Most of the Mac OS X networking subsystem is derived from that of 4.4BSD, although there are some important differences, such as in the handling of timers and the interaction of network devices with the higher layers of the networking stack.
The I/O Kit's Network family provides various classes that together constitute the low-level layers of the Mac OS X networking subsystem. For example, if you wish to create a network controller driver, you use the framework defined by the Network family. Moreover, the networking subsystem has a data link interface layer (DLIL) that connects the Network family with the BSD networking code. Specifically, the DLIL is used for communication between the Network family's IONetworkInterface class and higher-level components such as the protocols.
A notable feature of the Mac OS X implementation is the Network Kernel Extensions (NKE) mechanism, which provides ways to extend the system's networking architecture through loadable kernel modules that interact with the networking stack. Examples of applications of NKEs include implementation of new protocols, modification of existing protocols, creation of link-layer encryption mechanisms, and attachment of filters at various layers of the stack.
Before Mac OS X 10.4, a kernel extension had to be explicitly designated as an NKE. Beginning with version 10.4, the kernel exports several kernel programming interfaces (KPIs) that make NKE functionality available to kernel extensions.
The I/O Kit's Network family provides various classes that together constitute the low-level layers of the Mac OS X networking subsystem. For example, if you wish to create a network controller driver, you use the framework defined by the Network family. Moreover, the networking subsystem has a data link interface layer (DLIL) that connects the Network family with the BSD networking code. Specifically, the DLIL is used for communication between the Network family's IONetworkInterface class and higher-level components such as the protocols.
A notable feature of the Mac OS X implementation is the Network Kernel Extensions (NKE) mechanism, which provides ways to extend the system's networking architecture through loadable kernel modules that interact with the networking stack. Examples of applications of NKEs include implementation of new protocols, modification of existing protocols, creation of link-layer encryption mechanisms, and attachment of filters at various layers of the stack.
Before Mac OS X 10.4, a kernel extension had to be explicitly designated as an NKE. Beginning with version 10.4, the kernel exports several kernel programming interfaces (KPIs) that make NKE functionality available to kernel extensions.