在过去的5天里,我一直被困在网上寻找这个问题,我找不到答案,每次我启动ettercap并选择我的界面为wlan0时,它就会给我一个错误,就像这个错误一样。
ERROR: 9, Bad file descriptor
[/build/ettercap-jPFHOw/ettercap-08.2/src/ec_network.c:source_init:245]
libnet_init: unknown physical layer type 0x323我甚至没有ec_network.c文件,或者libnet文件(如果这与这个问题相关),如果我需要下载它,我可以从哪里下载它?
谢谢
发布于 2016-07-23 18:12:03
您可能已经发现了一个内核错误。也许我不应该把它命名为一个bug,因为它可能只是对卡的特定标识符的支持从来没有添加到内核代码中。
处理物理层的ettercap代码如下:
switch (ifr.ifr_hwaddr.sa_family)
{
case ARPHRD_ETHER:
case ARPHRD_METRICOM:
#ifdef ARPHRD_LOOPBACK
case ARPHRD_LOOPBACK:
#endif
l->link_type = DLT_EN10MB;
l->link_offset = 0xe;
break;
case ARPHRD_SLIP:
case ARPHRD_CSLIP:
case ARPHRD_SLIP6:
case ARPHRD_CSLIP6:
case ARPHRD_PPP:
l->link_type = DLT_RAW;
break;
case ARPHRD_FDDI:
l->link_type = DLT_FDDI;
l->link_offset = 0x15;
break;
/* Token Ring */
case ARPHRD_IEEE802:
case ARPHRD_IEEE802_TR:
case ARPHRD_PRONET:
l->link_type = DLT_PRONET;
l->link_offset = 0x16;
break;
default:
snprintf(l->err_buf, LIBNET_ERRBUF_SIZE,
"unknown physical layer type 0x%x",
ifr.ifr_hwaddr.sa_family);
goto bad;
}您可以检查/usr/include/net/if_arp.h中所有定义的值。是的,0x323被证明不是他们中的任何一个。此外,对于net/if_arp.h来说,0x323并不是任何已知的设备。
下面是一个用于填充ifr.ifr_hwaddr.sa_family并打印它的测试程序:
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <arpa/inet.h>
#include <sys/ioctl.h>
#include <stropts.h>
#include <net/if.h>
#include <netinet/if_ether.h>
#include <net/if_arp.h>
int
main(int argc, char** argv)
{
struct ifreq ifr;
int fd = -1;
char *iface = argv[1];
fd = socket(PF_INET, SOCK_PACKET, htons(ETH_P_ALL));
if (fd == -1)
{
if (errno == EPERM) {
printf("UID/EUID 0 or capability CAP_NET_RAW required\n");
} else {
printf("socket: %s\n", strerror(errno));
}
return 1;
}
memset(&ifr, 0, sizeof (ifr));
strncpy(ifr.ifr_name, iface, sizeof (ifr.ifr_name) -1);
ifr.ifr_name[strlen(iface)] = '\0';
if (ioctl(fd, SIOCGIFHWADDR, &ifr) < 0 )
{
printf("SIOCGIFHWADDR: %s\n", strerror(errno));
return 1;
}
printf( "IFR: [%08x] sa_family [%02x]\n"
, ifr.ifr_hwaddr, ifr.ifr_hwaddr.sa_family);
return 0;
}其中的一半仅仅是从ettercap的代码中复制出来的。无论如何,编译应该是非常简单的gcc -o prog prog.c (假定源名为prog.c),并且必须使用接口名作为其第一个参数来运行它。例如:
[root@haps ~]# /home/grochmal/tmp/libnet/test enp3s0
IFR: [24240001] sa_family [00]
[root@haps ~]# /home/grochmal/tmp/libnet/test wlp2s0
IFR: [22000001] sa_family [00](在我的机器上)
我们可以看到,sa_family由以下内容填充:
ioctl(fd, SIOCGIFHWADDR, &ifr)它运行如下:
struct net_device *dev = dev_get_by_name_rcu(net, ifr->ifr_name);
...
case SIOCGIFHWADDR:
if (!dev->addr_len)
memset(ifr->ifr_hwaddr.sa_data, 0,
sizeof(ifr->ifr_hwaddr.sa_data));
else
memcpy(ifr->ifr_hwaddr.sa_data, dev->dev_addr,
min(sizeof(ifr->ifr_hwaddr.sa_data),
(size_t)dev->addr_len));
ifr->ifr_hwaddr.sa_family = dev->type;
return 0;其中dev_get_by_name_rcu是填充struct net_device的内核宏。既然我们有ifr->ifr_hwaddr.sa_family = dev->type;,也有sa_family。
我找到了一个关于这个Kali Linux页面上的错误报告的sa_family,但是kali没有使用最新的内核。
因此,我将运行上面的测试程序以确保它打印:
IFR: [********] sa_family [323]测试程序需要以根用户身份运行,因为它使用的是原始套接字。
然后,我尝试使用一个更新的内核版本来检查这个bug是否已经修复在4.x内核分支中(例如gentoo或arch)。例如,使用gcc运行一张活动CD。测试程序没有库要求,因此它可以很容易地编译在一个活CD上。
这是一个S的深度,因为我可以进入内核代码。sa_family究竟是如何从设备哈希中确定的,这是我无法理解的。
https://unix.stackexchange.com/questions/297818
复制相似问题