> I don't know of NICs that would support this.
>
> When you run tcpdump, are you doing so such that it puts the interface
> in promiscuous mode? Without the "-p" option, tcpdump will put the
> interface in promiscuous mode (at least according to the man pages on
my
> machine).
>
> If not in promiscuous mode, then I would suspect that your hardware
> supports this and thus the problem is in the IP stack above it.
>
> If tcpdump is putting the NIC into promiscuous mode, then the
> observation that it receives packets to other MAC addresses proves
> nothing about the capabilities of your NIC other than it supports
> promiscuous mode, which in my experience just about all of them do.
Jeff,
Please find below description of "ping" test.
Toplogy:
A .4 <---192.168.1/24---> .2 / .20 B
Host "B" is acting as a device under test and has unicast address
added to multicast filter, by following program:
if((sock = socket(AF_INET, SOCK_DGRAM, 0)) == -1)
{
printf("%s",strerror(errno));
exit(1);
}
strcpy(req.ifr_name,"eth0");
req.ifr_hwaddr.sa_family = AF_UNSPEC;
req.ifr_hwaddr.sa_data[0] = 0x00;
//req.ifr_hwaddr.sa_data[0] = 0x01;
req.ifr_hwaddr.sa_data[1] = 0x01;
req.ifr_hwaddr.sa_data[2] = 0x01;
req.ifr_hwaddr.sa_data[3] = 0x01;
req.ifr_hwaddr.sa_data[4] = 0x01;
req.ifr_hwaddr.sa_data[5] = 0x01;
//res = ioctl(sock,SIOCADDMULTI,&req);
res = ioctl(sock,SIOCDELMULTI,&req);
if(res == -1)
{
printf("error: %s\n",strerror(errno));
exit(1);
}
B# ip m <- that's how I'm checking result of unicast mac addition
1: lo
inet 224.0.0.1
inet6 ff02::1
3: eth0
link 00:01:01:01:01:01 static <-- it's here
link 33:33:ff:b5:9c:4c
link 33:33:00:00:00:01
link 01:00:5e:00:00:01
inet 224.0.0.1
inet6 ff02::1:ffb5:9b4f
inet6 ff02::1
B# ip a l dev eth0
3: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0a:e4:b5:9c:4c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 scope global eth0
inet 192.168.1.20/24 scope global secondary eth0 <-- IP toward which A will transmit icmp echo requests
inet6 fe80::20a:e4ff:feb5:9b4f/64 scope link
valid_lft forever preferred_lft forever
tcpdump wuth and without "-p" flag:
B# tcpdump -pevvvni eth0 icmp <-- no output...
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
B# tcpdump -evvvni eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:39:35.362132 00:50:8b:0b:22:4c > 00:01:01:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 192.168.1.4 > 192.168.1.20: ICMP echo request, id 4611, seq 12, length 64
00:39:36.362100 00:50:8b:0b:22:4c > 00:01:01:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 192.168.1.4 > 192.168.1.20: ICMP echo request, id 4611, seq 13, length 64
00:39:37.362078 00:50:8b:0b:22:4c > 00:01:01:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 192.168.1.4 > 192.168.1.20: ICMP echo request, id 4611, seq 14, length 64
00:39:38.362070 00:50:8b:0b:22:4c > 00:01:01:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 192.168.1.4 > 192.168.1.20: ICMP echo request, id 4611, seq 15, length 64
00:39:39.362068 00:50:8b:0b:22:4c > 00:01:01:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 192.168.1.4 > 192.168.1.20: ICMP echo request, id 4611, seq 16, length 64
A# ip n | grep 192.168.1.2
192.168.1.2 dev eth0 lladdr 00:0a:e4:b5:9c:4c REACHABLE
192.168.1.20 dev eth0 lladdr 00:01:01:01:01:01 PERMANENT <-- static entry
B# ip n | grep 192.168.1.4
192.168.1.4 dev eth0 lladdr 00:50:8b:0b:22:4c REACHABLE
Once I will change unicast mac into multicast, i.e. add this entry using program listed above and
update static arp entry on host "A" this will work.
Can you based on this say something about nature of the problem, is it an issue with a NIC card?
Many Thanks,
--
Norman Baz
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
