----------------------------------------
> Subject: Re: Feedback on ASUS WL-138G V2
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: [email protected]; [EMAIL PROTECTED]
> Date: Tue, 22 Apr 2008 17:24:16 +0200
>
>
>> Notice the lack of led devices registering here (as I mentioned before).
>> Indeed,
>> the behaviour of the leds is totally different -- now, they come ON and stay
>> ON when the card is 'active'...ie; ifconfig wlan0 up. Converse is true ;
>> doing
>> 'ifconfig wlan0 down' turns the leds off again.
>>
>> If I dump the sprom image Stefanik provided back into the card, the led
>> device
>> registration lines reappear in debug, and the leds blink in that sympathetic
>> way
>> rx/tx leds do. Is there yet another funky value in sprom responsible for
>> this?
>
> Yes, the sprom determines how the card vendor wants the LEDs to behave.
> You can change this behaviour easily in sysfs.
>
.....good to know. Not that the blinking (or not) of leds is ever going to be a
'show stopper', and I suppose most users probably don't see the things at the
rear of their case anyhow....however, I can see mine and thought it a little bit
strange...(and worth mentioning). Mind you, the 'normal, average user' will be
expecting the things to flash on/off in empathy with network traffic, and having
the leds -not- flashing may confuse said 'normal, average users' into thinking
something is terribly wrong......ie; "someone is hacking my radioLAN" type of
paranoia....
>> [from the 'host' box with the asus card]
>>
>> 1212 packets transmitted, 1200 packets received, 0% packet loss
>> round-trip min/avg/max/stddev = 0.821/1.192/5.801/0.366 ms
>>
>> ...???.....I would've expected almost 1% packet loss (having lost 12 packets)
>
> Heh. May be a rounding error somewhere
>
>> If I ping the host box from my machine here, the packets have to go out
>> my eth0 interface into a netgear wr602 in client mode which is associated
>> with the wgr614 AP down the hall (which is the AP the host is associated
>> with also). In this case, I get ;
>
>> 350 packets transmitted, 344 packets received, +140 duplicates, 1% packet
>> loss
>> round-trip min/avg/max/stddev = 1.222/1.893/4.296/0.443 ms
>>
>> Has anyone any idea what's going on here?
>
> Eh, what exactly is your network setup? You normally can't bridge STA
> mode. This looks like something is not doing ieee 802.11 de-duplication.
That is true == normally you can't bridge STA mode, however this is exactly
-why- I purchased the netgear wg-602 (v3) unit, because it is capable of
'client hub' and 'repeater' modes....(or so say it's docs). Whether this
'client hub' mode is actually -working- correctly is another question again.
I too suspect using the wg-602 in this way is the cause of DUP! issues
here. however I'll need reconfigure the network and eliminate the unit
before I'll know for sure.
Understand, I only bought this unit to get around the fact that the ASUS
wl-138g v2 cards didn't initially work under linux -- given the progress made
here with these ASUS cards, I can set about removing this stop-gap measure.
Answering your question -- the remote end consists of the netgear wgr-614
AP unit ; it's WAN port connected to ADSL modem, and one workstation
connected to it's inbuilt 4-port hub. This is about 10metres down the hall
from my location.
This end consists of the netgear wr-602 unit in 'client hub' mode, associated
with said AP. This box is connected to the wr-602 by ethernet wire. The 32bit
machine fitted withthe ASUS card is also my end of things, associated to
said AP unit. There is also a winXP box this end of the house, associated to
the same AP (but using a netgear wg311 card, and displaying no errors)
The 32bit machine fitted with the ASUS card is about 2metres from the
wr-602 this end.
A section of the ping trace looks like this;
64 bytes from 172.16.1.112: icmp_seq=232 ttl=64 time=2.188 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=233 ttl=64 time=1.776 ms
64 bytes from 172.16.1.112: icmp_seq=234 ttl=64 time=1.893 ms
64 bytes from 172.16.1.112: icmp_seq=235 ttl=64 time=1.838 ms
64 bytes from 172.16.1.112: icmp_seq=236 ttl=64 time=1.750 ms
64 bytes from 172.16.1.112: icmp_seq=237 ttl=64 time=1.774 ms
64 bytes from 172.16.1.112: icmp_seq=238 ttl=64 time=2.648 ms
64 bytes from 172.16.1.112: icmp_seq=240 ttl=64 time=1.434 ms
64 bytes from 172.16.1.112: icmp_seq=240 ttl=64 time=1.997 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=241 ttl=64 time=3.371 ms
64 bytes from 172.16.1.112: icmp_seq=241 ttl=64 time=3.861 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=242 ttl=64 time=1.465 ms
64 bytes from 172.16.1.112: icmp_seq=242 ttl=64 time=3.112 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=243 ttl=64 time=1.321 ms
64 bytes from 172.16.1.112: icmp_seq=243 ttl=64 time=2.075 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=244 ttl=64 time=1.513 ms
64 bytes from 172.16.1.112: icmp_seq=244 ttl=64 time=2.151 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=245 ttl=64 time=1.650 ms
64 bytes from 172.16.1.112: icmp_seq=245 ttl=64 time=2.037 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=246 ttl=64 time=1.463 ms
64 bytes from 172.16.1.112: icmp_seq=246 ttl=64 time=2.319 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=247 ttl=64 time=1.488 ms
64 bytes from 172.16.1.112: icmp_seq=247 ttl=64 time=1.884 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=248 ttl=64 time=1.473 ms
64 bytes from 172.16.1.112: icmp_seq=248 ttl=64 time=2.797 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=249 ttl=64 time=1.906 ms
64 bytes from 172.16.1.112: icmp_seq=250 ttl=64 time=2.270 ms
64 bytes from 172.16.1.112: icmp_seq=251 ttl=64 time=1.983 ms
64 bytes from 172.16.1.112: icmp_seq=252 ttl=64 time=1.825 ms
64 bytes from 172.16.1.112: icmp_seq=253 ttl=64 time=1.772 ms
64 bytes from 172.16.1.112: icmp_seq=254 ttl=64 time=1.775 ms
64 bytes from 172.16.1.112: icmp_seq=255 ttl=64 time=1.801 ms
64 bytes from 172.16.1.112: icmp_seq=256 ttl=64 time=1.819 ms
64 bytes from 172.16.1.112: icmp_seq=256 ttl=64 time=2.424 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=257 ttl=64 time=2.481 ms
64 bytes from 172.16.1.112: icmp_seq=258 ttl=64 time=2.589 ms
64 bytes from 172.16.1.112: icmp_seq=259 ttl=64 time=2.126 ms
64 bytes from 172.16.1.112: icmp_seq=260 ttl=64 time=1.492 ms
64 bytes from 172.16.1.112: icmp_seq=260 ttl=64 time=2.081 ms (DUP!)
64 bytes from 172.16.1.112: icmp_seq=261 ttl=64 time=1.888 ms
64 bytes from 172.16.1.112: icmp_seq=262 ttl=64 time=1.765 ms
64 bytes from 172.16.1.112: icmp_seq=263 ttl=64 time=1.728 ms
64 bytes from 172.16.1.112: icmp_seq=263 ttl=64 time=2.270 ms (DUP!)
This is pinging back to my workstation here (172.16.1.112) from the
32bit machine/asus card setup. The ping trace from here back to the
32bit box looks pretty much identical.
Regards,
Donald
>
> johannes
_________________________________________________________________
It's simple! Sell your car for just $30 at CarPoint.com.au
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
