alpha rt-n firmware releases

[wpte]

Anyone ever had the problem that the wifi goes down?

It happened to me twice now.
once it kept broadcasting but didn't respond to any connection requests.
the second time right now it didn't broadcasted at all, while according to the router, the network was up.

I did wl down and wl up, after that it worked again

[necrolatry]

What is your firmware version?

[wpte]

What is your firmware version?

1.9.2.7-rtn-r1633

my friend has similair problems since R1484
http://code.google.com/p/wl500g/source/detail?r=1484
it's not that frequent, but now and then, it just stops working

[lly]

I don't observe such behavior on my RT-N16, probably I never load WiFi as much as you. Anyway, WiFi driver itself wasn't modified, only many patches against kernel.

It will be best, if you can trace starting on which revision problem appears.

[wpte]

I don't observe such behavior on my RT-N16, probably I never load WiFi as much as you. Anyway, WiFi driver itself wasn't modified, only many patches against kernel.

It will be best, if you can trace starting on which revision problem appears.

I know only the settings changed, and it does deliver a slightly better performance, at least better compatibility with older wifi products

I do have a wireless ethernet bridge (my old wl500w) which does try to keep the link alive, but it's nothing like a high load.

As I said, its since that revision I had those problems, just like a friend of mine

I'm not sure... can you advice me some commands I should run when it happens? to check the status etc? "wl status" probably, but maybe some advanced things I'm not aware of

[lly]

In other words, you want to say me that r1478 is OK, and r1484 has problems?

[wpte]

In other words, you want to say me that r1478 is OK, and r1484 has problems?

sorry to disappoint you, but yes, I guess so
I Hate to bring things up like that

I mean, I don't think I configured it wrong: just everything on auto basicly, 40mhz, wpa-personal aes and wmm enabled.

I enabled wmm since it tripled the max speed on my wireless ethernet bridge

Maybe it's better to analyze it before jumping into actions? lly, what would you like to know when wifi stops working?

[lly]

Maybe it's better to analyze it before jumping into actions? lly, what would you like to know when wifi stops working?

I will agree with you, in case of I have some debugging instruments.
Unfortunately, we can use only ioctl calls (wl binary).

First of all, check that are nas + eapd processes are in memory. Second, issue "wl status" - maybe is shows something. Also try to set wl0_obss_coex=0 - it is major change in r1484 commit

[wpte]

I will agree with you, in case of I have some debugging instruments.
Unfortunately, we can use only ioctl calls (wl binary).

First of all, check that are nas + eapd processes are in memory. Second, issue "wl status" - maybe is shows something. Also try to set wl0_obss_coex=0 - it is major change in r1484 commit

it just happened again this morning.
wl status:

SSID: "*******"
Mode: Managed   RSSI: 0 dBm     noise: -76 dBm  Channel: 4
BSSID: ***************        Capability: ESS ShortSlot
Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
802.11N Capable:
        Chanspec: 2.4GHz channel 4 40MHz (0x2e04)
        Control channel: 6
        802.11N Capabilities:
        Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 32 ]

eapd and nas are running.
wlan led is on, but doesn't blink when I try to connect.

seems to be happening overnight all the time

[lly]

it just happened again this morning.

Unfortunately wl diagnostic is very poor, I apologize that "wl isup" also will return 1. In case of we suspect r1484 commit, can you revert it on your side for tests?

[wpte]

Unfortunately wl diagnostic is very poor, I apologize that "wl isup" also will return 1. In case of we suspect r1484 commit, can you revert it on your side for tests?

I haven't tried "wl0_obss_coex=0" yet, but that's pretty much the same as R1448 I guess.
Anyway, my router was running for over 9 days, so maybe I need to wait that long again before it happens

I have an active laptop cooler under my router, so everything of this shouldn't happen because of the overheating in the summer

[ecaddict]

I wanted to try out of switching on GSO has some good impact to TCP performance but noticed that ethtool does not exist for the router. Is it really so?

So my plan was something like:

ethtool -K eth0 gso on

I've checked in include/linux/netdevice.h that GSO flag exists (NETIF_F_GSO):

	/* Net device features */
	unsigned long		features;
#define NETIF_F_SG		1	/* Scatter/gather IO. */
#define NETIF_F_IP_CSUM		2	/* Can checksum only TCP/UDP over IPv4. */
#define NETIF_F_NO_CSUM		4	/* Does not require checksum. F.e. loopack. */
#define NETIF_F_HW_CSUM		8	/* Can checksum all the packets. */
#define NETIF_F_HIGHDMA		32	/* Can DMA to high memory. */
#define NETIF_F_FRAGLIST	64	/* Scatter/gather IO. */
#define NETIF_F_HW_VLAN_TX	128	/* Transmit VLAN hw acceleration */
#define NETIF_F_HW_VLAN_RX	256	/* Receive VLAN hw acceleration */
#define NETIF_F_HW_VLAN_FILTER	512	/* Receive filtering on VLAN */
#define NETIF_F_VLAN_CHALLENGED	1024	/* Device cannot handle VLAN packets */
#define NETIF_F_GSO		2048	/* Enable software GSO. */
#define NETIF_F_LLTX		4096	/* LockLess TX */

and this should work without ethernet driver/HW support.

Also ethtool_set_gso function exists in net/core/ethtool.c

Is there any way to switch it on without writing code for ioctl call?

[lly]

I wanted to try out of switching on GSO has some good impact to TCP performance but noticed that ethtool does not exist for the router. Is it really so?

It (ethtool) simply don't included into bundle yet. You can compile it yourself at this time, with toolchain published. Or wait some time, we will include it in future.

[theMIROn]

It (ethtool) simply don't included into bundle yet. You can compile it yourself at this time, with toolchain published. Or wait some time, we will include it in future.

Seems like ethtool 2.6.34 doesn't work on rt-n16

[admin@router-n /tmp]$ ./ethtool -K eth0 gso on
Cannot set device generic segmentation offload settings: Invalid argument

[admin@router-n /tmp]$ ./ethtool -K vlan2 gso on
Cannot set device generic segmentation offload settings: Invalid argument

[admin@router-n /tmp]$ ./ethtool -k vlan2
Offload parameters for vlan2:
Cannot get device rx csum settings: Invalid argument
Cannot get device tx csum settings: Invalid argument
Cannot get device scatter-gather settings: Invalid argument
Cannot get device tcp segmentation offload settings: Invalid argument
Cannot get device udp large send offload settings: Invalid argument
Cannot get device generic segmentation offload settings: Invalid argument
Cannot get device flags: Invalid argument
Cannot get device GRO settings: Invalid argument
no offload info available

it works only for br0

[admin@router-n /tmp]$ ./ethtool -K br0 gso on
[admin@router-n /tmp]$ ./ethtool -k br0
Offload parameters for br0:
Cannot get device rx csum settings: Operation not supported
Cannot get device udp large send offload settings: Operation not supported
Cannot get device flags: Operation not supported
Cannot get device GRO settings: Operation not supported
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

so, ethtool doesn't support broadcom eth devices

[lly]

Seems like ethtool 2.6.34 doesn't work on rt-n16

Seems to be, et driver missing most modern ethtool ioctl's