>> 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
|
|