On Fri, 2008-02-22 at 22:21 +0100, Andrew Lunn wrote: > > Can you try the attached patch instead? stats.received_channel really > > should be filled by the hardware driver itself. This patch essentially > > does what bcm43xx does. Can you test it please? > > I can try it, but i suspect it will not work. The firmware in the > ipw2100 does the scan, not the driver. So priv->channel will not be > the frequency the probe_resp corresponds to when the firmware is off > scanning on other frequencies. Yeah; you're right. I'm not sure there's a good way to do this unless there's some way the ipw2100 passes back the channel number each frame was received on. We can't use IPW_ORD_OUR_FREQ because we can't guarantee that when the interrupt for received frame occurs the frame the driver is handed was received on the same channel that the card is now on. But also ignoring the check in update_network() will cause the signal strength of networks to be lower than they should be, because the frame bled over to a different channel. Intel devs; does the ipw2100 firmware stick the channel into the frame header anywhere like ipw2200? Perhaps the ipw2100 driver just never got updated for that feature? If not, is there another way this could be fixed? Dan - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
