[debian-non-standard] connection problems to wl500gP

[Russel]

>> I had a different default settings after my first boot of your
>> system+kernel.
>> I had eth0 and eth0.1 configured, only LAN ports were working and
>> "robocfg show" gave this output
>>
>> asus-debian:~/robocfg# ./robocfg show
>> Switch: enabled
>> Port 0(W):  DOWN enabled stp: none vlan: 1 mac: 00:00:00:00:00:00
>> Port 1(4):  10HD enabled stp: none vlan: 0 mac: 00:00:00:00:00:00
>> Port 2(3):  DOWN enabled stp: none vlan: 0 mac: 00:00:00:00:00:00
>> Port 3(2):  DOWN enabled stp: none vlan: 0 mac: 00:00:00:00:00:00
>> Port 4(1):  DOWN enabled stp: none vlan: 0 mac: 00:00:00:00:00:00
>> Port 5(C): 100FD enabled stp: none vlan: 0 mac: 00:00:00:00:00:00
>> VLANs: BCM5325/535x enabled mac_check mac_hash
>> vlan0: 1 2 3 4 5u
>> vlan1: 0 5u


According to robocfg, Port 1 is linking at only 10 mbps half duplex. I 
looked at your previous posts, but didn't see the speed of your other 
network switch/hub. (Your Asus is connected to another switch, right?) My 
bet is that you have a bad cable between your other switch and the Asus. If 
your other hub/switch is only 10mbps, then the link speed should be 10mbps 
only (and maybe just half duplex), but if it is 100mbps, then this should 
definitely be 100mbps.

Network devices will often negotiate a slower speed in order to work with a 
bad cable. If your cable has the pairs out of order, it may still work, but 
not very well. Normally, the orange pair and the green pair are used for 
transmit and receive. However, a common mistake is to wire the cables like 
this (there is a name for this mistake, but I can't remember it):
orange/white
orange
green/white
green
blue/white
blue
brown/white
brown

In this scenario, the TX+/TX- wires (orange/white and orange) are correct, 
but the RX wires are messed up. RX+ is going down the green/white wire, 
which is good, but RX- is going down the blue wire. Your RX signal would be 
using two different twisted pairs, which would not offer very much 
protection from signal loss.

I am probably just repeating information you already know -- after all, 
you're hacking a wireless router using a more obscure method than most 
hackers would try. However, your robocfg output caught my eye.

For what it's worth, here is the output from my router:
server:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:15:F2:6A:E5:C2
          inet addr:10.240.5.1  Bcast:10.240.5.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:421239 errors:0 dropped:0 overruns:0 frame:0
          TX packets:278462 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:434029732 (413.9 MiB)  TX bytes:37671624 (35.9 MiB)
          Interrupt:4

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)

server:~# robocfg show
Switch: enabled
Port 0(W):  DOWN enabled stp: disable vlan: 1 mac: 00:00:00:00:00:00
Port 1(4):  DOWN enabled stp: none vlan: 1 mac: 00:00:00:00:00:00
Port 2(3):  DOWN enabled stp: none vlan: 1 mac: 00:00:00:00:00:00
Port 3(2): 100FD enabled stp: none vlan: 1 mac: 08:00:37:31:7a:b0
Port 4(1): 100FD enabled stp: none vlan: 1 mac: 00:0e:35:15:c1:43
Port 5(C): 100FD enabled stp: none vlan: 1 mac: 00:15:f2:6a:e5:c2
VLANs: BCM536x disabled mac_check mac_hash


(I just have VLAN support disabled on my switch)

server:~# cat /proc/net/vlan/*
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD


Mine works fine 100% of the time.
Good luck!

--Rusel Riley