[Bug 606684] New: skge: martian source: ll header: ff:ff:ff:ff:ff:ff:00:15:0c:bd:bb:81:08:00
http://bugzilla.novell.com/show_bug.cgi?id=606684 http://bugzilla.novell.com/show_bug.cgi?id=606684#c0 Summary: skge: martian source: ll header: ff:ff:ff:ff:ff:ff:00:15:0c:bd:bb:81:08:00 Classification: openSUSE Product: openSUSE 11.3 Version: Factory Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: koenig@linux.de QAContact: qa@suse.de Found By: --- Blocker: --- on my test PC I tried to use the onboard marvell gigabit ethernet chip instead of the e1000 pci card which is the default NIC (both connected to the same 100 Mbit switch). dhcp worked fine on eth1, but for every ping from remote PC I got this kernel msgs (ping, ssh or anything else did not work): [ 164.612753] martian source 192.168.178.27 from 192.168.178.31, on dev eth1 [ 164.612757] ll header: ff:ff:ff:ff:ff:ff:00:02:b3:b5:42:39:08:06 ^^^^^^^^^^^^^^^^^ where 00:02:b3:b5:42:39 is the MAC of the remote pc (source of ping, e100 with suse 11.1 32bit). here is some syslog from startup: a1 kernel: [ 58.308017] skge 0000:00:0a.0: eth1: Link is up at 100 Mbps, full duplex, flow control both a1 kernel: [ 58.308171] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready a1 avahi-daemon[2927]: Registering new address record for fe80::211:2fff:fea7:fa25 on eth1.*. a1 dhcpcd[4038]: eth1: offered 192.168.178.32 from 192.168.178.1 a1 kernel: [ 60.631793] martian source 255.255.255.255 from 192.168.178.1, on dev eth1 a1 kernel: [ 60.631797] ll header: ff:ff:ff:ff:ff:ff:00:15:0c:bd:bb:81:08:00 a1 dhcpcd[4038]: eth1: checking 192.168.178.32 is available on attached networks a1 kernel: [ 60.708055] martian source 255.255.255.255 from 192.168.178.1, on dev eth1 a1 kernel: [ 60.708058] ll header: ff:ff:ff:ff:ff:ff:00:15:0c:bd:bb:81:08:00 a1 dhcpcd[4038]: eth1: leased 192.168.178.32 for 864000 seconds a1 dhcpcd[4038]: eth1: adding IP address 192.168.178.32/24 a1 dhcpcd[4038]: eth1: adding default route via 192.168.178.1 metric 0 a1 dhcpcd[4038]: eth1: adding route to 169.254.0.0/16 metric 0 a1 dhcpcd[4038]: eth1: exiting later I had to reboot because of some suspend/resume problems, and now eth1 seems to work. at least I can ping now, but still I see some rare "matian source" messages -- so far 3 of them: [ 4178.788345] martian source 192.168.178.27 from 192.168.178.31, on dev eth1 [ 4178.788348] ll header: ff:ff:ff:ff:ff:ff:00:02:b3:b5:42:39:08:06 [ 4296.877154] martian source 192.168.178.32 from 192.168.178.31, on dev eth1 [ 4296.877157] ll header: ff:ff:ff:ff:ff:ff:00:02:b3:b5:42:39:08:06 [ 4781.998797] martian source 192.168.178.32 from 192.168.178.31, on dev eth1 [ 4781.998801] ll header: ff:ff:ff:ff:ff:ff:00:02:b3:b5:42:39:08:06 and from this startup: [ 56.566292] skge 0000:00:0a.0: eth1: enabling interface [ 56.569824] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 58.308017] skge 0000:00:0a.0: eth1: Link is up at 100 Mbps, full duplex, flow control both [ 58.308171] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 60.631793] martian source 255.255.255.255 from 192.168.178.1, on dev eth1 [ 60.631797] ll header: ff:ff:ff:ff:ff:ff:00:15:0c:bd:bb:81:08:00 [ 60.708055] martian source 255.255.255.255 from 192.168.178.1, on dev eth1 [ 60.708058] ll header: ff:ff:ff:ff:ff:ff:00:15:0c:bd:bb:81:08:00 [ 69.174008] eth1: no IPv6 routers present is this a known problem for the skge driver and/or marvell ethernet chip? first I was using the same ethernet cable for skge as before for e1000, so I don't think (hope?) it's a hardware problem with cable or switch port ?!? now I have two connections to be able to test skge -- but I need e1000 for safe remote access (I don't want to rely on the skge yet...;) hw info: 00:0c.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) Subsystem: Intel Corporation PRO/1000 GT Desktop Adapter 00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) Subsystem: ASUSTeK Computer Inc. Marvell 88E8001 Gigabit Ethernet Controller (Asus) 00:0c.0 0200: 8086:107c (rev 05) 00:0a.0 0200: 11ab:4320 (rev 13) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=606684
http://bugzilla.novell.com/show_bug.cgi?id=606684#c
Jeff Mahoney
http://bugzilla.novell.com/show_bug.cgi?id=606684
http://bugzilla.novell.com/show_bug.cgi?id=606684#c1
--- Comment #1 from Brandon Philips
http://bugzilla.novell.com/show_bug.cgi?id=606684
http://bugzilla.novell.com/show_bug.cgi?id=606684#c2
--- Comment #2 from Harald Koenig
The simplest explanation is that you have both cards plugged in and they are confusing each other when you are getting broadcast messages.
well, only the e1000 is "plugged in", the marvell chip is on the main board...
Basically a martian packet is a packet that comes in but Linux wasn't expecting that interface to get it.
Otherwise, if both cards aren't plugged in something else on your network is misconfigured.
any suggestions what to check or test ? it's a plain dump 100mbit switch with 2 PCs connected (the test PC with 11.3 and two nics, and the server which I use to probe running 11.1 with e100).
The warnings are harmless and can be ignored or disabled via /etc/sysctl.conf net.ipv4.conf.all.log_martians = 0.
at the first boot these "warnings" haven't been completely harmless as ping did not work at all (neither did ssh) but instead I got those messages for eveyr ping package being received! disabling those warnings likely won't make the ping work suddenly I guess ?!
What does /sbin/ifconfig, netstat -nr and arp read when these things happen?
I'll check when it completely blocks for the next time... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=606684
http://bugzilla.novell.com/show_bug.cgi?id=606684#c3
Brandon Philips
(In reply to comment #1)
The simplest explanation is that you have both cards plugged in and they are confusing each other when you are getting broadcast messages.
well, only the e1000 is "plugged in", the marvell chip is on the main board...
By plugged in I mean plugged in to the Ethernet. Not plugged into the system bus. Make sure only one card is on the ethernet at a time.
Basically a martian packet is a packet that comes in but Linux wasn't expecting that interface to get it.
Otherwise, if both cards aren't plugged in something else on your network is misconfigured.
any suggestions what to check or test ? it's a plain dump 100mbit switch with 2 PCs connected (the test PC with 11.3 and two nics, and the server which I use to probe running 11.1 with e100).
Start by making sure only one NIC is plugged into the Ethernet for this machine. Then you will want to check the route tables and IPs of the machines on the network using the ifconfig, netstat and arp commands I gave below.
The warnings are harmless and can be ignored or disabled via /etc/sysctl.conf net.ipv4.conf.all.log_martians = 0.
at the first boot these "warnings" haven't been completely harmless as ping did not work at all (neither did ssh) but instead I got those messages for eveyr ping package being received!
disabling those warnings likely won't make the ping work suddenly I guess ?!
What does /sbin/ifconfig, netstat -nr and arp read when these things happen?
I'll check when it completely blocks for the next time...
Alright, leaving NEEDINFO on you to gather this information. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=606684
http://bugzilla.novell.com/show_bug.cgi?id=606684#c4
Harald Koenig
Start by making sure only one NIC is plugged into the Ethernet for this machine. Then you will want to check the route tables and IPs of the machines on the network using the ifconfig, netstat and arp commands I gave below.
ok, now I understand what caused my network problems -- not sure if this explains the "martin" messages, but I don't care about those msgs as long as the network is working... lan connected only to eth1 (marvell), eth0 was not connected at boot time, but eth0 got configured and the default route got set via eth0 because there is a 10 day lease time from my fritz box as dhcp server and ifcfg-eth0 says STARTMODE='auto' (start at boot time, yast default). now I switched both ifcfg-eth[01] to STARTMODE='ifplugd' which makes my setup now work with either nic connection.... looks like STARTMODE='auto' is not always the best choice -- maybe yast should use STARTMODE='ifplugd' as default ?! thanks for your hints and questions -- ticket closed for me (except for the question of a different yast2 default for STARTMODE ?!?) ! before changing STARTMODE the runtime config looked like this: # grep dhcp.*eth0 /var/log/messages May 24 18:55:00 a1 dhcpcd[9790]: eth0: timed out May 24 18:55:00 a1 dhcpcd[9790]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info' May 24 18:55:00 a1 dhcpcd[9790]: eth0: adding IP address 192.168.178.27/24 May 24 18:55:00 a1 dhcpcd[9790]: eth0: adding default route via 192.168.178.1 metric 0 # ifconfig eth0 Link encap:Ethernet HWaddr 00:0E:0C:D9:60:B2 inet addr:192.168.178.27 Bcast:192.168.178.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth1 Link encap:Ethernet HWaddr 00:11:2F:A7:FA:25 inet addr:192.168.178.32 Bcast:192.168.178.255 Mask:255.255.255.0 inet6 addr: fe80::211:2fff:fea7:fa25/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1252 (1.2 Kb) TX bytes:3301 (3.2 Kb) Interrupt:17 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth0 # ll /var/lib/dhcpcd/dhcpcd-eth0.* -rw-r--r-- 1 root root 400 2010-05-19 00:23 /var/lib/dhcpcd/dhcpcd-eth0.info -rw-r--r-- 1 root root 0 2010-05-24 18:54 /var/lib/dhcpcd/dhcpcd-eth0.timestamp # cat /var/lib/dhcpcd/dhcpcd-eth0.info DHCPSIADDR='192.168.178.1' IPADDR='192.168.178.27' NETMASK='255.255.255.0' NETWORK='192.168.178.0' BROADCAST='192.168.178.255' ROUTES='' GATEWAYS='192.168.178.1' DNSSERVERS='192.168.178.1' DHCPSID='192.168.178.1' LEASEDFROM='1274221437' LEASETIME='864000' RENEWALTIME='432000' REBINDTIME='756000' INTERFACE='eth0' CLASSID='dhcpcd 3.2.3' CLIENTID='01:00:0e:0c:d9:60:b2' DHCPCHADDR='00:0e:0c:d9:60:b2' now the network setup is like this (only STARTMODE got changed): # cat ifcfg-eth0 BOOTPROTO='dhcp' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NAME='82541PI Gigabit Ethernet Controller' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='ifplugd' USERCONTROL='no' IFPLUGD_PRIORITY='20' -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=606684
http://bugzilla.novell.com/show_bug.cgi?id=606684#c5
Brandon Philips
thanks for your hints and questions -- ticket closed for me (except for the question of a different yast2 default for STARTMODE ?!?) !
Alright, I will close this out. Can you file a new bug about the STARTMODE issue and assign it to the Yast2 component? It is a separate issue from the Kernel's martian source messages. Thanks, Brandon -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com