Modify

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#3507 closed defect (fixed)

ethernet doesn't work on fonera+

Reported by: matteo Owned by: developers
Priority: high Milestone:
Component: kernel Version:
Keywords: Cc:

Description

Ethernet doesn't work on FOnera with the Marvell switch:

Marvell 88E6060: Registered new driver
eth0: Atheros AR231x: 00:18:84:d0:01:88, irq 4
ar2313_eth_mii: probed
eth0: Marvell 88E6060 PHY driver attached.
eth0: attached PHY driver [Marvell 88E6060] (mii_bus:phy_addr=0:1f)

but I can't ping nothing

Attachments (0)

Change History (23)

comment:1 Changed 9 years ago by offiziell@…

Same Problem on Netgear WGT624v2 and svn 11595:

Marvell 88E6060: Registered new driver
eth0: Atheros AR231x: 00:0f:b5:6f:18:eb, irq 4
ar2313_eth_mii: probed
eth0: Marvell 88E6060 PHY driver attached.
eth0: attached PHY driver [Marvell 88E6060] (mii_bus:phy_addr=0:1f)
...
br-lan: port 1(eth0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0) entering forwarding state
[sighandler]: No more events to be processed, quitting.
[cleanup]: Waiting for children.
[cleanup]: All children terminated.
- preinit -

Please press Enter to activate this console. br-lan: port 1(eth0) entering disabled state
device eth0 left promiscuous mode
br-lan: port 1(eth0) entering disabled state
device eth0 entered promiscuous mode
br-lan: port 1(eth0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0) entering forwarding state
br-lan: port 1(eth0) entering disabled state
device eth0 left promiscuous mode
br-lan: port 1(eth0) entering disabled state
device eth0 entered promiscuous mode
br-lan: port 1(eth0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0) entering forwarding state
root@OpenWrt:/# ifconfig
br-lan    Link encap:Ethernet  HWaddr 00:0F:B5:6F:18:EB
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:320 (320.0 B)

eth0      Link encap:Ethernet  HWaddr 00:0F:B5:6F:18:EB
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:6804 (6.6 KiB)
          Interrupt:4 Base address:0x1000

eth0.1    Link encap:Ethernet  HWaddr 00:0F:B5:6F:18:EB
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:6804 (6.6 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  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:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
root@OpenWrt:/# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100): 56 data bytes

--- 192.168.1.100 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/# arp -n
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.100    0x1         0x0         00:00:00:00:00:00     *        br-lan
root@OpenWrt:/#

comment:2 Changed 9 years ago by nbd

please try a current build.

comment:3 follow-up: Changed 9 years ago by nbd

  • Resolution set to worksforme
  • Status changed from new to closed

bug timeout, works for me

comment:4 in reply to: ↑ 3 Changed 9 years ago by tran@…

Replying to nbd:

bug timeout, works for me

doesn't work here on Fonera 2201 with 2.6.26.7 from r13053.

root@OpenWrt:~# dmesg |grep eth
eth0: Atheros AR231x: 00:18:84:a3:42:4c, irq 4
ar2313_eth_mii: probed
eth0: Marvell 88E6060 PHY driver attached.
eth0: attached PHY driver [Marvell 88E6060] (mii_bus:phy_addr=0:1f)
eth0: Configuring MAC for full duplex
root@OpenWrt:~# lspci -vv
00:00.0 Ethernet controller: Atheros Communications, Inc. Device ff18 (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B+ DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at 81000000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at <ignored> (32-bit, non-prefetchable)
	Region 2: Memory at 80800000 (32-bit, non-prefetchable) [size=4M]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

00:03.0 Ethernet controller: Atheros Communications, Inc. Device ff18 (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B+ DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at 81020000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at <ignored> (32-bit, non-prefetchable)
	Region 2: Memory at 80c00000 (32-bit, non-prefetchable) [size=4M]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

/etc/config/network:

[...]
config 'interface' 'lan'
        option 'ifname' 'eth0.1'
        option 'proto' 'static'
        option 'ipaddr' '172.17.145.1'
        option 'netmask' '255.255.255.128'
[...]
config 'interface' 'wan'
        option 'ifname' 'eth0.0'
        option 'proto' 'dhcp'

ifconfig:

[...]
eth0.0    Link encap:Ethernet  HWaddr 00:18:84:A3:42:4C  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:459 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:184518 (180.1 KiB)

eth0.1    Link encap:Ethernet  HWaddr 00:18:84:A3:42:4C  
          inet addr:172.17.145.1  Bcast:172.17.145.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:220 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:9600 (9.3 KiB)
[...]

now i see BOOTP/DHCP, Request on: eth0.1, eth0 and my laptop connected to foneras
LAN (!?) port.
i configure my laptop 172.17.145.2/25, and ping it from fonera:

root@OpenWrt:~# tcpdump -ni eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
-5:-18:-43.770599 arp who-has 172.17.145.2 tell 172.17.145.1
-5:-18:-42.770285 arp who-has 172.17.145.2 tell 172.17.145.1
-5:-18:-41.660336 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:84:a3:42:4c, length 360

like expected,

root@OpenWrt:~# tcpdump -ni eth0.0
tcpdump: WARNING: eth0.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.0, link-type EN10MB (Ethernet), capture size 96 bytes
-5:-13:-47.430894 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:84:a3:42:4c, length 360
-5:-13:-44.490550 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:84:a3:42:4c, length 360

also, like expected, but:

root@OpenWrt:~# tcpdump -ni eth0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.1, link-type EN10MB (Ethernet), capture size 96 bytes

...silence.
and nothing on the WAN port.

So, i change /etc/config/network:

[...]
config 'interface' 'lan'
        option 'ifname' 'eth0.0'
        option 'proto' 'static'
        option 'ipaddr' '172.17.145.1'
        option 'netmask' '255.255.255.128'
[...]    
config 'interface' 'wan'
        option 'ifname' 'eth0.1'
        option 'proto' 'dhcp'

and get (!?):

root@OpenWrt:~# ifconfig
[...]
eth0      Link encap:Ethernet  HWaddr 00:18:84:A3:42:4C  
          inet addr:172.17.145.1  Bcast:172.17.145.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:58 dropped:58 overruns:0 frame:58
          TX packets:1381 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:484105 (472.7 KiB)
          Interrupt:255 Base address:0x1000 

eth0.0    Link encap:Ethernet  HWaddr 00:18:84:A3:42:4C  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1160 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:466320 (455.3 KiB)
[...]

i still get:

root@OpenWrt:~# tcpdump -ni eth0  
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
-4:-22:-31.930596 arp who-has 172.17.145.2 tell 172.17.145.1
-4:-22:-30.810541 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:84:a3:42:4c, length 360
-4:-22:-30.930326 arp who-has 172.17.145.2 tell 172.17.145.1

and:

root@OpenWrt:~# tcpdump -ni eth0.0
tcpdump: WARNING: eth0.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.0, link-type EN10MB (Ethernet), capture size 96 bytes
-4:-18:-40.310770 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:84:a3:42:4c, length 360
-4:-18:-37.370290 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:84:a3:42:4c, length 360

but still see ONLY the DHCP-Requests on the LAN (!?) port.
if i configure only eth0 manually, i see on my laptop conected to LAN port
the arp who-is and my laptops replies, but they don't make it to foneras eth0.

btw, the same setup worked just fine with redboot for flashing it (iirc, both, LAN and WAN port worked the same, just like one would expect from a switch/hub), and,
of course, firewall is off.

cheers

--Jan

comment:5 Changed 9 years ago by tran@…

so i tried 8.09rc1:
with a straight cable i see dhcp requests coming from fonera's wan port.
with a x-over cable, i see them coming from the lan port !?
to be continued...

--Jan

comment:6 Changed 9 years ago by matteo

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I run tcpdump from a pc to the other end, i can say that the fonera sends packets, but doesn't receive them.
Also, it receives or not by different hosts, eg:
it receives from a brcm63xx and an NGW100
it doesn't from an AR7 and a PC with an RTL8168c/8111c eth card

comment:7 Changed 9 years ago by matteo

I can reach the fonera by changing my PC MAC address: http://openwrt.pastebin.ca/1269662

have a try too and post your laptop MAC address please

comment:8 follow-up: Changed 9 years ago by matteo

Found, the fonera doesn't works when the ethernet on the other end has a MAC address where the 5th byte is compriseer by 01 and 05
eg.
xx:xx:xx:xx:xy:xx

where y is from 1 to 5 included.

comment:9 in reply to: ↑ 8 Changed 9 years ago by tran@…

Replying to matteo:

Found, the fonera doesn't works when the ethernet on the other end has a MAC address where the 5th byte is compriseer by 01 and 05
eg.
xx:xx:xx:xx:xy:xx

where y is from 1 to 5 included.

i can confirm exactly the same behavior here. so, at least we have a workaround :-)

thanks

comment:10 follow-up: Changed 9 years ago by anonymous

I can confirm this behaviour on a Fonera 2201, Openwrt trunk (rev 14400)
This seems to be driver related as arp responses work if the arp request is initiated by the client PC, but the fonera never hears the responses to it's own arp requests from the client PC.
Attempting to ping a client PC, then viewing the arp table on the fonera will show an unresolved mac address of 00:00:00:00:00:00
Attempting to ping the fonera from the client PC will resolve the correct mac address for the fonera in the client's arp cache
After changing the mac address on the client to the exact same mac address as the previous one, except editing byte 5 to be 06, communication works correctly.

comment:11 in reply to: ↑ 10 Changed 9 years ago by anonymous

Same problem with two Fonera+ (2201) using dd-wrt v24-SP1.

comment:12 Changed 9 years ago by anonymous

The 88E6060 switch chip does vlan to port mapping using either header or trailer mode, where data is added to the beginning or end of the packet respectively to indicate the src/dst port(s) for the packet.

  • The mvswitch.c driver defaults to header mode, but can be compiled for trailer mode.
  • Used in header mode this problem with the 5th byte of the mac address is seen. Used in trailer mode it isn't.

comment:13 Changed 9 years ago by Felix.Braun@…

One resolution could be to port the ar231x driver to the new Marvell Switch driver (/net/dsa/) included in linux 2.6.28 instead of our homegrown mvswitch driver. As far as I understand the DSA driver works exclusively in trail mode. Unfortunately, I don't understand nearly enough to do the porting myself :-(

comment:14 Changed 9 years ago by nbd

or you could try enabling the trailer mode in mvswitch.c
there's a define for that which you can simply enable and it might fix this bug.

comment:15 Changed 9 years ago by anonymous

Yes - when you enable trailer mode in mvswitch.c the bug goes away.

comment:16 Changed 9 years ago by jth@…

I've worked out the root cause of this.

On the Atheros chip the DMA engine for ethernet does a check on the 802.3 type/length field. If it's a length (< 0x600), and if it's wrong, a length error gets flagged in the rx descriptor and the packet is dropped by the driver (ar2313.c).

The Marvell 88e6060 in header mode adds 2 bytes to the head of the packet to indicate the source port of the rx-ed packet. This means the DMA engine will erroneously interpret the last 2 bytes of the source mac as being a type/length field. If the last two bytes are < 0x600 it will be treated as a length, will almost certainly be wrong, and will be dropped by the driver. If it's >= 0x600 it will be interpreted as a type and allowed through. Hence the observed behavior.

Solution: Ignore length errors in the driver.

--- ar2313.c.orig       2009-03-21 10:15:50.000000000 -0700
+++ ar2313.c    2009-03-21 10:16:28.000000000 -0700
@@ -922,7 +922,7 @@
                printk("RX descr  %08x\n", rxdesc->descr);
 #endif

-               if ((status & (DMA_RX_ERROR | DMA_RX_ERR_LENGTH)) &&
+               if ((status & DMA_RX_ERROR) &&
                        (!(status & DMA_RX_LONG))) {
 #if DEBUG_RX
                        printk("%s: rx ERROR %08x\n", __FUNCTION__, status);

comment:17 follow-up: Changed 8 years ago by anonymous

I can confirm this problem.

The only workaround I was able to find is to change my mac address with macchanger. Is there something else that can be done without having to deal with sources?

Thank you.

comment:18 in reply to: ↑ 17 Changed 8 years ago by jth@…

Is there something else that can be done without having to deal with sources?

Nope.

comment:19 Changed 8 years ago by anonymous

Has someone tested the given patch? As it is not working for me.

comment:20 Changed 8 years ago by nbd

  • Resolution set to fixed
  • Status changed from reopened to closed

fix added in r15185
header mode re-enabled in r15186

comment:21 Changed 8 years ago by anonymous

Actually with the new fix applied ethernet on my fonera+ is not working anymore.

Before I was able to make it work changing my mac-address.

How can I provide more useful debug info?

comment:22 Changed 8 years ago by me@…

This needs to be reopened. ar2313.c needs to have it's length error checking removed as suggested by jth. The switch currently doesn't work under 8.09.1 even with the mvswitch.c changes.

comment:23 Changed 8 years ago by anonymous

Probably is the same problem reported here.

I'm having the same problem. Can this be reopened?

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.