just my $0.02: ethertap interfaces has fake mac addresses, generated somehow by the tun/tap driver, and they are same on both sides in your case. Don't know why. -- Nikolay Datchev On Fri, 16 Jan 2004, Christopher S. Aker wrote: > Hello, > > I manage a number of servers all running 2.4 (same problem exists with 2.6). My > problem is that since a few bridge versions ago, I've had to modify > net/bridge/br_fdb.c in the br_fdb_insert() function -- to get rid of the checks > that produce this error: > > Jan 16 10:35:31 host15 kernel: tap_0: received packet with own address as source > address > Jan 16 10:35:33 host15 kernel: tap_0: received packet with own address as source > address > > My specific setup is: br0 assigned an IP, with eth0 added to the bridge with no > IP. I create tap devices, assign them no IP address but a unique MAC. On the > other end of each tap device is an UML virtual machine's eth0. My machines are > SuperMicro 6013 dual xeon boxes with e1000, and a 5012 box with e100 NICs. I > don't believe this is a checksum issue raised a while back. STP is off. Settings > for setfd and sethello make no difference. As soon as UML brings up its eth0 > interface, the messages appear. > > I'm really not a kernel hacker, but I was able to look at previous versions of the > file and more or less just comment out the "if (unlikely(fdb->is_local))" > statement. This is what I've been using for the past few months. It seems to > work as it did before this new check was put in place. But, I still have a > problem where showmacs displays this for each tap interface: > > 2 fe:fd:45:38:ad:f1 no 4.88 > 2 fe:fd:45:38:ad:f1 yes 0.00 > > Two entries for the same interface -- a local, non-expiring fdb entry, and a > non-local expiring fdb entry. Once the non-local fdb entry times out, the tap > loses connectivity from the world. If I log into the host machine locally and > ping an IP on the TAP interface, it comes back alive. Same goes for logging into > the UML's console and pinging the host. I've had this problem even with the older > bridge code. I think all this is related to the real problem. Looks like > something isn't detecting traffic as local, or perhaps it needs special handling > for this case? > > Others have been using the identical bridge setup, minus the e100/1000 cards, and > haven't reported either of these problems. Any advice would be appreciated. > > Regards, > -Chris > > _______________________________________________ > Bridge mailing list > Bridge@xxxxxxxxxxxxxx > http://lists.osdl.org/mailman/listinfo/bridge >
