For the record, here is the ping output: "PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=2 ttl=254 time=308 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=254 time=4.89 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=254 time=315 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=254 time=627 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=254 time=4.72 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=254 time=316 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=254 time=627 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=254 time=4.49 ms 64 bytes from 192.168.1.1: icmp_seq=11 ttl=254 time=334 ms 64 bytes from 192.168.1.1: icmp_seq=12 ttl=254 time=645 ms 64 bytes from 192.168.1.1: icmp_seq=16 ttl=254 time=3.44 ms 64 bytes from 192.168.1.1: icmp_seq=17 ttl=254 time=313 ms 64 bytes from 192.168.1.1: icmp_seq=18 ttl=254 time=623 ms 64 bytes from 192.168.1.1: icmp_seq=20 ttl=254 time=326 ms 64 bytes from 192.168.1.1: icmp_seq=21 ttl=254 time=638 ms 64 bytes from 192.168.1.1: icmp_seq=22 ttl=254 time=4.67 ms 64 bytes from 192.168.1.1: icmp_seq=23 ttl=254 time=322 ms 64 bytes from 192.168.1.1: icmp_seq=24 ttl=254 time=632 ms 64 bytes from 192.168.1.1: icmp_seq=25 ttl=254 time=3.30 ms 64 bytes from 192.168.1.1: icmp_seq=26 ttl=254 time=312 ms 64 bytes from 192.168.1.1: icmp_seq=29 ttl=254 time=317 ms 64 bytes from 192.168.1.1: icmp_seq=30 ttl=254 time=629 ms 64 bytes from 192.168.1.1: icmp_seq=31 ttl=254 time=4.66 ms 64 bytes from 192.168.1.1: icmp_seq=32 ttl=254 time=200 ms 64 bytes from 192.168.1.1: icmp_seq=33 ttl=254 time=510 ms 64 bytes from 192.168.1.1: icmp_seq=34 ttl=254 time=3.17 ms 64 bytes from 192.168.1.1: icmp_seq=35 ttl=254 time=314 ms 64 bytes from 192.168.1.1: icmp_seq=36 ttl=254 time=625 ms 64 bytes from 192.168.1.1: icmp_seq=37 ttl=254 time=4.92 ms 64 bytes from 192.168.1.1: icmp_seq=38 ttl=254 time=316 ms 64 bytes from 192.168.1.1: icmp_seq=39 ttl=254 time=626 ms 64 bytes from 192.168.1.1: icmp_seq=41 ttl=254 time=3.40 ms 64 bytes from 192.168.1.1: icmp_seq=42 ttl=254 time=313 ms 64 bytes from 192.168.1.1: icmp_seq=42 ttl=254 time=330 ms (DUP!) 64 bytes from 192.168.1.1: icmp_seq=43 ttl=254 time=3.30 ms 64 bytes from 192.168.1.1: icmp_seq=44 ttl=254 time=3.34 ms 64 bytes from 192.168.1.1: icmp_seq=45 ttl=254 time=313 ms 64 bytes from 192.168.1.1: icmp_seq=46 ttl=254 time=623 ms 64 bytes from 192.168.1.1: icmp_seq=47 ttl=254 time=3.88 ms ^C --- 192.168.1.1 ping statistics --- 47 packets transmitted, 38 received, +1 duplicates, 19% packet loss, time 46162ms rtt min/avg/max/mdev = 3.178/295.346/645.168/242.113 ms"
And the shutdown statistics of the driver: "b43-phy2 debug: Wireless interface stopped b43-phy2 debug: DMA-32 rx_ring: Used slots 2/64, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy2 debug: DMA-32 tx_ring_AC_BK: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy2 debug: DMA-32 tx_ring_AC_BE: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy2 debug: DMA-32 tx_ring_AC_VI: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy2 debug: DMA-32 tx_ring_AC_VO: Used slots 6/128, Failed frames 180/246 = 73.1%, Average tries 5.39 b43-phy2 debug: DMA-32 tx_ring_mcast: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00" On Fri, Apr 18, 2008 at 4:44 PM, Stefanik Gábor <[EMAIL PROTECTED]> wrote: > That's *exactly* what I am doing at this moment. Here are my findings so > far: > > WL-138G V2 comes with BoardFlags=0x0049. That would mean, no Afterburner > (among other things), even though Asus specifically advertises this card as > supporting Afterburner. When I set it > to0x6A49, the card suddenly comes to life to some extent, as I can > associate/DHCP and Radiotap injection works, but loading webpages is > eXXXXtremely slow, and pinging my AP results in an anomalous output, > where the return time of the pings cycles between > 3ms, 350ms and 600ms, with some packets dropped, and others received twice > (duplicates). When I flash the > entire SPROM that I sent to Larry and Kala Mazoo minus the MAC address and > the subsystem IDs, the card works much > better, web pages download fast, ping times don't cycle, but pinging my AP > still shows a lot of duplicates (although no packets get lost). This suggests > that the weird "ping cycling" bug and the extremely low throughput is > due to a mismatch between BoardFlags and the paXbY values, and not a driver > bug. I will do some more bisecting on the individual BoardFlags > values to see which one triggers the bug. > > > On 4/18/08, Johannes Berg <[EMAIL PROTECTED]> wrote: > > > On Fri, 2008-04-18 at 15:57 +0200, Michael Buesch wrote: > > > > > > Following up on this idea of substituting sprom images; > > > > > > > > > Oops, sorry, here is the attached SPROM file.> > > > > > > > > Using that sprom dump which Stefanik provided, the card in question > > here > > > > appears to be now working (although I've not yet tested it at any > > length) > > > > > > > > wlan0: associated > > > > phy0: Added STA 00:1e:2a:61:7d:2c > > > > ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > > > > > > That's interesting. I didn't expect this. > > > > > > Maybe one could "bisect" through the sprom to see which values > > break/make it? Certainly the MAC address won't matter :) > > > > > > johannes > > > > _______________________________________________ > > Bcm43xx-dev mailing list > > Bcm43xx-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > > > > > > > > > -- > Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
_______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
