Greets,
Still using my 32bit machine fitted with this card and finding
a couple of strange quirks. Current 'state of play' on this machine is
as follows;
linux-2.6.25
compat-wireless-2008-04-20 + Michael's patch series 'mb-wl-20080420-1630'
rewrote original ssb_sprom image back into card
The card now initializes fine with original (shipped) sprom, caveat the rx/tx
leds ;
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
b43-phy0 debug: Chip initialized
b43-phy0 debug: 32-bit DMA initialized
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
ff:ff:ff:ff:ff:ff
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:1e:2a:61:7d:2c
wlan0: RX authentication from 00:1e:2a:61:7d:2c (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:1e:2a:61:7d:2c
wlan0: RX AssocResp from 00:1e:2a:61:7d:2c (capab=0x431 status=0 aid=2)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present
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?
Previously I had mentioned dropped/duplicate packets being observed (I think
Stefanik noted likewise), and at the time I thought it was my error -- late
night,
running on autopilot, typed in a conflicting IP address...something like this. I
have since discovered something else is at play here.
[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)
[from the remote box pinging host box via netgear wgr614 AP]
1175 packets transmitted, 1161 received, 1% packet loss, time 1174031ms
rtt min/avg/max/mdev = 0.943/1.180/7.979/0.469 ms
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 ;
354 packets transmitted, 348 packets received, +115 duplicates, 1% packet loss
round-trip min/avg/max/stddev = 1.126/1.861/17.681/1.222 ms
..and from the host machine pinging the same route back to me;
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?
Otherwise the card seems to be working 'as expected', although the duplicates
& dropped packets *only* via that specific hardware route make for a jerky
ride if one tries to (eg) stream video across it.
Regards,
Donald
_________________________________________________________________
Are you paid what you're worth? Find out: SEEK Salary Centre
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2Fcareer%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%3Ahet%3Asc%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_salary&_m=EXT
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
