Michael Buesch wrote: > On Friday 18 August 2006 13:52, Michael Buesch wrote: >> Hm, I don't see anything special. >> There's only one packet retried once, but even that succeed after the retry. >> I would say that's normal noise. >> >> So, what's going on there? Did you try with another card and driver, but >> with the >> same AP? Did you try with another operating system on the same AP? >> Did you try another encryption algorithm or without encryption? > > Larry, we talked about the issue on IRC and we decided that it's > best if you could take a capture of the whole traffic. > So, please set up another card in monitor mode to capture the > broken traffic between your card in question and the AP. > > Best would probably be, if you post an ethereal log somewhere (in > private, as you might not want to post your network data here :) ) > > Thing is, we aren't able to reproduce the issue. > I just tried various things with my 4306 card and it works exactly > as relieable as under OSX here.
This is the only card I have. I have not tried with another set of firmware, but this driver works perfectly well with Windows XP, and it used to work with ndiswrapper. I stopped making kernels with 8K stacks, so cannot run ndiswrapper any more. > We also talked about interference. What type of interference could > be possible for you? Microwave ovens? If I put my laptop directly > on top of the uwave oven and switch it on, connection is destroyed. > But it recovers immediately, if I move away from the thing or > switch it off. Maybe there's some older oven somewhere? Or some > other device transmitting in the 2.4G band? Did you try to switch > to a different channel? Be aware of adjacent channel interference, > too. So, if you're currently on channel 1, try to switch to channel 13. I don't think it is interference. There are two other AP's that I can detect with "iwlist s". I'm on channel 1, and the other two are on channels 6 and 11. This should be the ideal case. I don't have any other 2.4 GHz equipment, and the microwave was off. I am in the US and cannot use ch. 13. My AP has regulatory restrictions and only goes to 11. > You could probably also try to play with the interference > mitigation code, which is provided by the driver. We are not sure > if it works correctly, but it's worth a try. > The interference mitigation mode can be selected through the bcm43xx > sysfs attributes. It defaults to OFF. See file bcm43xx_sysfs.c for > details on possible modes. > > Well, finally, I would like to look at some ethereal logs of the > whole thing. Especially looking at the retransmission bit and ack > packets could be interresting. I will set up a configuration that lets me capture packets in monitor mode using kismet and send you the capture file. The host I will be using is for the capture is rather low powered, so it doesn't have X, but it makes a good file server. Thanks, Larry _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
