/bugzilla3/ Bug 339 – peth0: received packet with own address as source address
Bug 339 - peth0: received packet with own address as source address
: peth0: received packet with own address as source address
Status: NEW
Product: Xen
Hypervisor
: unstable
: All Linux
: P2 normal
Assigned To: Xen Bug List
:
:
:
  Show dependency treegraph
 
Reported: 2005-10-17 20:07 CDT by David F Barrera
Modified: 2012-06-19 09:10 CDT (History)
9 users (show)

See Also:


Attachments
diff of network-bridge script (851 bytes, patch)
2007-04-19 23:57 CDT, Cyrus Katrak
Details
Full file (8.21 KB, text/plain)
2007-04-19 23:57 CDT, Cyrus Katrak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David F Barrera 2005-10-17 20:07:01 CDT
I am seeing the message "peth0: received packet with  own address as source
address" on several machines, most of which have one only NIC and bridged
networking for the guests. I am not sure what the impact is, but it could be a
problem with networking.
Comment 1 David F Barrera 2005-10-17 20:08:01 CDT
I posted the question to the xen-devel lists, and Arnd Schmitter responded:

From: 	Arnd Schmitter <arnd_xen@yahoo.de>
To: 	David F Barrera <dfbp@us.ibm.com>
Cc: 	xen-devel <xen-devel@lists.xensource.com>
Subject: 	Re: [Xen-devel] peth1: received packet with own address as source address
Date: 	Mon, 17 Oct 2005 20:50:31 +0200  (13:50 CDT)

David F Barrera wrote:
> I am seeing a series of messages (below):
>
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
> peth1: received packet with  own address as source address
>
> Is this something that I should care about? I don't see an obvious
> impact to the machine. 
>
>   

This means normaly two things: Packets you send out are returning or 
there is another PC with the same address.
The Linuxkernel drops this packets as he think its a knd of address 
spoofing.
If all networking is working fine you will only have a minimal impact on 
performance. But it could indicate that something with your network 
configuration is wrong

Arnd
Comment 2 David F Barrera 2005-10-21 14:17:42 CDT
Has anyone been able to determine whether this is a bug or not? I don't see any
apparent effect on my machines, but my machines have very simple network setups.
Comment 3 Ewan Mellor 2005-10-23 22:53:28 CDT
This is believed to have been caused by the machine's routing tables getting 
into a state where they claim to be going through peth0 rather than eth0.  If 
this happened with two Xen machines on the network, then one would complain 
about packets coming from the other.

This problem is believed fixed with changeset 7436:18eb059ae471.
Comment 4 lge 2005-10-24 19:04:21 CDT
I don't see the message in any "xm dmesg" and "dmesg". So I am closing the bug.
Comment 5 F. Lassmann 2006-06-22 04:28:32 CDT
I doubt that it is fixed with 7436 because I've installed 9726 (compiled from
xen-3.0-testing-src.tgz some days ago) and now I see the same thing in my
syslog / dmesg output:

peth0: received packet with  own address as source address
peth0: received packet with  own address as source address
...

But I'm neither a Xenist nor can I guarantee that this is the same problem, so
I do not dare to reopen this bug. Let me know if someone needs additional info.
Unfortunately this is not really reproducable: I've only got 13 messages of
that sort in my syslog over the last days. 

BTW 'ifconfig' shows "HWaddr FE:FF:FF:FF:FF:FF" for peth0, vif0.0 and xenbr0.
I don't know whether this is normal.
Comment 6 Russell McOrmond 2006-08-19 11:38:55 CDT
I am running Xen via the Fedora Core 5 kernels.  Unfortunately I don't know how
to deterine what version of Xen I'm running, but 'xm dmesg' say Xen version 

3.0-unstable (brewbuilder@build.redhat.com) (gcc version 4.1.1 20060525 (Red
Hat 4.1.1-1)) Tue Aug  8 15:25:20 EDT 2006


These are messages that come out of the xen0's 'dmesg', (IE: not the 'xm
dmesg'), and unless there is something wrong in the default scripts from RedHat
it isn't a network config problem (IE: the XenU's and Xen0's on this LAN are
all unique addresses).   I do have two Xen servers if that might be the source
of the problem.  The other LAN I administrate Xen machines on also has more
than one Xen server, and each of them are issuing similar warnings.


I wish this bug were re-opened or at least further investigated.  Is the
problem that peth0 and all the vif?.0 interfaces all have the same HW address
of FE:FF:FF:FF:FF:FF and thus also have one of the IPv6 addresses on each of
these interfaces being fe80::fcff:ffff:feff:ffff/64 ?  Should the default
scripts that are setting up these interfaces discontinue setting up IPv6
addresses on these interfaces?
Comment 7 Ian Pratt 2006-08-19 14:05:21 CDT
The message is due to unwanted ipv6 router solicitations, and can be safely
ignored. There was some discussion on the mailing lists about a fix for this,
but I'm not sure it's made kernel.org yet.
Comment 8 Russell McOrmond 2006-08-20 06:59:20 CDT
(In reply to comment #7)
> The message is due to unwanted ipv6 router solicitations, and can be safely
> ignored. There was some discussion on the mailing lists about a fix for this,
> but I'm not sure it's made kernel.org yet.

Doesn't it make more sense to fix this in the supplied scripts that set up the
virtual ethernet interfaces, rather than in the kernel?  If an interface didn't
have an IPv6 address, it wouldn't send out router solicitations...

Or is this related to an enhancement to the tools to make it easier to indicate
not to set up the default IPv6 address when the interface is being brought up
(IE: we need more than a global setting).
Comment 9 Moses Leslie 2006-09-06 09:37:09 CDT
This says unstable, but I get it on 3.0-testing also.  Is there a way to make
it not happen, other than to ignore it?  It fills up dmesg and syslog, making
it hard to troubleshoot other problems.

There are no dom-Us active, just the dom0.
Comment 10 Ian Pratt 2006-09-06 21:54:14 CDT
If none of your interfaces have ipv6 addresses assigned it shouldn't be a
problem.
Comment 11 Moses Leslie 2006-09-07 00:45:16 CDT
None of them have ipv6 interfaces, I don't even have ipv6 support in the
kernel.

However, the eth0 nic that xen is using is still broadcasting it, and the cisco
switch complains about it as well:

2006 Sep 07 00:43:53 PDT -07:00 %SYS-4-P2_WARN: 1/Host fe:ff:ff:ff:ff:ff is
flapping between port 2/30 and port 2/44

Our network engineers sure don't like me doing things that create messages like
that :)

Thanks,

Moses
Comment 12 Adriaan Peeters 2007-02-08 02:39:43 CST
I also see these messages in dmesg when ipv6 is disabled running Debian
testing's xen.
Comment 13 Adriaan Peeters 2007-03-14 07:17:10 CDT
This seems to be caused by having two dom0 machines on the same network. Both
have HWaddr FE:FF:FF:FF:FF:FF for peth0.
Comment 14 Cyrus Katrak 2007-04-19 23:57:04 CDT
Created attachment 535 [details]
diff of network-bridge script

taken against:
http://xenbits.xensource.com/xen-3.0.5-testing.hg?raw-file/b9f579e2d6a7/tools/examples/network-bridge
Comment 15 Cyrus Katrak 2007-04-19 23:57:50 CDT
Created attachment 536 [details]
Full file
Comment 16 Cyrus Katrak 2007-04-19 23:59:39 CDT
I ran into this issue when placing two Dom0's on the same network.

I have attached a replacement for the network-bridge script that fixes this
issue.
The solution is to assign a unique MAC to the vif/peth devices, for every dom0
on your network. I also anticipated that a single dom0 with two physical NICs
plugged into the same switch would encounter this error, and thus based the MAC
off a combination of a unique identifier, and the eth number.

Files:
context.diff was created using:
diff -c network-bridge network-bridge-new > context.diff
network-bridge-new is the full file
Comment 17 Paul Rawson 2007-06-19 18:51:40 CDT
I've had the same problem -- two dom0s on the same network -- and the patch by
cyrus works very well. Thanks!
Comment 18 maze 2008-01-01 11:01:49 CST
I had the same problem - although there is only one dom0 with one NIC in my
network. This patch fixed it, thanks!
Comment 19 k.n 2008-01-09 20:28:58 CST
This might be a problem of hardware. 
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/165052
Comment 20 vivekpaliwal87 2011-11-04 03:05:26 CDT
Its quite tough to understand these codes. There is need to improve in
presentation....
http://scrabbleicious.com
Comment 21 vivekpaliwal87 2011-12-02 03:40:10 CST
The presentation and layout of the site is really good. I would like to show
this way of presentation to my friends...http://www.gta4cheat.org
Comment 22 vivekpaliwal87 2011-12-02 03:42:03 CST
 I appreciate your thought..
http://www.gta4cheat.org
(In reply to comment #3)
> This is believed to have been caused by the machine's routing tables getting 
> into a state where they claim to be going through peth0 rather than eth0.  If 
> this happened with two Xen machines on the network, then one would complain 
> about packets coming from the other.
> 
> This problem is believed fixed with changeset 7436:18eb059ae471.
Comment 23 Joseph Martin 2012-01-19 12:04:35 CST
(In reply to comment #20)
> Its quite tough to understand these codes. There is need to improve in
> presentation....
you are right. What type of bug this can be? Any answer?
http://www.anagrammer.com/scrabble/
Comment 24 Podryw 2012-06-19 09:10:08 CDT
It is very hard to understand these coded but I am doing my best and hope that
it will work out...
http://www.jakpoderwacdziewczyne.net/