Info regarding "WAN dies"

[Krypt]

Antiloop; could we combine some testing?

You can contact me at my ICQ/MSN..

First I'll try to reproduce the WAN-die with a direct connection, and then try the same with the hub connected. And finaly I'll try it again with the suggestion of GJAman.

I'm off to home now, and will test it right away..

[Oleg]

My WAN port dies soon enouth (1-5 min) during FTP transfer from WAN to LAN at speed ~4 MBytes/s, but it takes much more time to kill it at a lower speed (<2 MBytes/s).

This is probably due to cable length and number of errors - your cabling is about 120 meters as seems.

[Oleg]

No, `et -i eth1 phywr 0 0x8000 ; et -i eth1 up` doesn't restore WAN port.

Only two things help:
1 `et -i eth1 speed auto`
or
2 `ifconfig IP ; route add default gw gw_IP`

wierd... ok, I will post you exact sequence later.

[Nominus]

This is probably due to cable length and number of errors - your cabling is about 120 meters as seems.

But direct (i.e. without WL-500g) connection works fine - no port deaths and no packet loss, even at higher speed rate (7-8 Mbytes/s).

[Oleg]

yet another attempt Does

et -i eth1 promisc 0

helps you?

[GJAman]

I have no modem, i have 100MBit ethernet connection and the most strange thing is that hard speed lock doesn't work (100full, 100half, 10 full and 10half), only speed auto.

It's importent that you do the following commands BEFORE the WAN port dies accures, and then test if the WAN port dies with datatransfer

For halfduplex 10Mbit: /usr/sbin/et -i eth1 speed 10half
For fullduplex 10Mbit: /usr/sbin/et -i eth1 speed 10full

Off course hou have a 100Mbit connection at your WAN port, but it can help the poeple who haven't a higer connection than 10Mbit availble.

I can't test it write now at my WL-500g because it stands by my neighbours (where the ADSL conection is comming in, wich my WL-300g recieves at home from the WL-500g)

[Nominus]

It's importent that you do the following commands BEFORE the WAN port dies accures, and then test if the WAN port dies with datatransfer

For halfduplex 10Mbit: /usr/sbin/et -i eth1 speed 10half
For fullduplex 10Mbit: /usr/sbin/et -i eth1 speed 10full

WAN port DIES just after any `et -t eth1 speed` command, exept `et -i eth1 speed auto`. And i don't need 10Mbit connection, i need 100Mbit.

[Antiloop]

WAN port DIES just after any `et -t eth1 speed` command, exept `et -i eth1 speed auto`. And i don't need 10Mbit connection, i need 100Mbit.

your WAN can't achieve any higher than around 20-25MBit (this is the same max of wireless too.. )

[GJAman]

WAN port DIES just after any `et -t eth1 speed` command, exept `et -i eth1 speed auto`. And i don't need 10Mbit connection, i need 100Mbit.

Off course it dies, you use a 100Mbit connection
Sorry for asking

I hope to try it for my situation tommorow. I will post my findings here and at http://got.tweakers.net

[Nominus]

yet another attempt Does

et -i eth1 promisc 0

helps you?

Very strange but Yes, it restores the connection and not so painfully (`et -i eth1 speed auto` do much as i tested it while live connection and i lose 2-3 ping packets during it, but no one during `et -i eth1 promisc 0`) though promiscuous mode is usually turned off and how could switching it off again help? I'm cunfused...

[Nominus]

your WAN can't achieve any higher than around 20-25MBit (this is the same max of wireless too.. )

Hmm, I can transfer (wired) through WL-500g at 4.6 MBytes/s - it's about 37 Mbits, higher speed is limited by slow router's CPU.

[Oleg]

Very strange but Yes, it restores the connection and not so painfully (`et -i eth1 speed auto` do much as i tested it while live connection and i lose 2-3 ping packets during it, but no one during `et -i eth1 promisc 0`) though promiscuous mode is usually turned off and how could switching it off again help? I'm cunfused...

Internally broadcom driver perform like the following. Then it receives "speed" request from et utility it sets appropriate flags (speed, duplex, autoneg), then resets phy and initializes ethernet chip itself. Autonegotiation took some times, so you are observing loose of packets.
Promisc thing works in the same way - i.e. set the flags, calls init, but does not touch phy.
So finally - there is no problem with link or it's speed, i.e. phy is operating normally. But there is a problem with driver - for some unknown reason it is got stuck at some time. During this time phy is operating normally - i.e. it's receiving packets, but chip as seems does not serve phy requests.
This bug is probably triggered in some circumstances. Also, this is not only the wl500g problem, i think wrt54g & other similar devices has this bug...
I'm thinking of recompiling et driver with debug info...

[Krypt]

Ok.. I'm home now and removed my hub and connected my WL500g directly onto my modem.. Transferred 2 Linux images at the same time; Emule and downloaded a 100MB test zip and my WL500g died in a matter of seconds..
[edit]
Hmm. unfortunately I cannot reproduse it.. I'll set my WL500g on 100Mbit Fullduplex fixed and check it tomorrow if it's still up and running.. If it doesn't I'll switch back to 100Halfduplex and so on.. and if it works; I'll set it back on Autosensing and check again..

[Oleg]

Internally broadcom driver perform like the following. Then it receives "speed" request from et utility it sets appropriate flags (speed, duplex, autoneg), then resets phy and initializes ethernet chip itself. Autonegotiation took some times, so you are observing loose of packets.
Promisc thing works in the same way - i.e. set the flags, calls init, but does not touch phy.
So finally - there is no problem with link or it's speed, i.e. phy is operating normally. But there is a problem with driver - for some unknown reason it is got stuck at some time. During this time phy is operating normally - i.e. it's receiving packets, but chip as seems does not serve phy requests.
This bug is probably triggered in some circumstances. Also, this is not only the wl500g problem, i think wrt54g & other similar devices has this bug...
I'm thinking of recompiling et driver with debug info...

Also, just a suggestion for everyone. You can avoid this by executing something like this in the custom firmware:

nvram set bootCmd0="(while sleep 60s; do (ping -c 1 your_dns_ip || et -i eth1 promisc 0) > /dev/null 2>&1; done)&"
nvram commit
reboot

Replace your_dns_ip with IP of your DNS server (from the status page) or something else, like a modem IP or gateway address. Once rebooted wl500g will check connection status every 60 seconds and knock et driver to recover connection.

To everyone: let me know if it helps. You may want to decrease 60 seconds to something like 15 - just replace 60s with 15s

[GJAman]

Also, just a suggestion for everyone. You can avoid this by executing something like this in the custom firmware:

nvram set bootCmd0="(while sleep 60s; do (ping -c 1 your_dns_ip || et -i eth1 promisc 0) > /dev/null 2>&1; done)&"
nvram commit
reboot

Replace your_dns_ip with IP of your DNS server (from the status page) or something else, like a modem IP or gateway address. Once rebooted wl500g will check connection status every 60 seconds and knock et driver to recover connection.

To everyone: let me know if it helps. You may want to decrease 60 seconds to something like 15 - just replace 60s with 15s

OK, I tried the following through telnet (remotely)
et -i eth1 promisc 0
result: WAN port dies

et -i eth1 promisc 1
result: WAN normaly

So in my situation is exactly the other way around

Situation:
. . . . . . . . . . .PC
. . . . . . . . . . ..^
. . . . . . . . . . . |
ST 510 ----> WL-500g --- wireless --> WL-300g --> Network
Router. . . . . . . AP. . . . . . . . . . . . . . . . AP. . . . . . . . . . .

Network = 4 PC's connected with a switch to the WL-300g and one Notebook wireless (at 11Mbps or 54Mbps)