Link Quality stats not updating, recieved_channel

Link Quality stats not updating, recieved_channel

[Andrew Lunn]

Hi Folks

I found a problem with the IPW2100/ieee80211 drivers which i think
also affects other users of ieee80211 in stock 2.6.24 and earlier.

The function net/ieee80211/ieee80211_rx.c:update_network() gets called
in response to a beacon or a probe response. It is responsible for
updating the information we already have about the network described
by the beacon or the probe response. At the beginning of the function
is:

        /* We only update the statistics if they were created by receiving
         * the network information on the actual channel the network is on.
         *
         * This keeps beacons received on neighbor channels from bringing
         * down the signal level of an AP. */
        if (dst->channel == src->stats.received_channel)
                memcpy(&dst->stats, &src->stats,
                       sizeof(struct ieee80211_rx_stats));
        else
                IEEE80211_DEBUG_SCAN("Network %s info received "
                        "off channel (%d vs. %d)\n", print_mac(mac, src->bssid),
                        dst->channel, src->stats.received_channel);

The problem is that the ipw2100 driver never fills in the
stats.received_channel. So the RSSI and other link quality parameters
never get updated. The RSSI is always the RSSI of the first frame
which caused the network record to be created. 

I have an application which triggers periodic scans and prints out the
results and clearly shows this problem if you walk around. Using
iwlist ethX scan should also demonstrate the problem and enabling
IEEE80211_DEBUG_SCAN can demonstrate the problem as well.

I took a quick look at some of the drivers. As far as i can see, only
the IPW2200 driver fills in stats.received_channel before calling
80211_rx().

To get my application working i changed the test above. I update the
stats if src->stats.received_channel is zero, or if
src->stats.received_channel is not zero it must equal dst->channel.

However i don't know the big picture, so i don't know if this is the
correct fix. If it is correct, i would be happy to submit a patch.  

        Thanks
                Andrew

Re: Link Quality stats not updating, recieved_channel

[Dan Williams]

On Fri, 2008-02-22 at 15:26 +0100, Andrew Lunn wrote:
> Hi Folks
> 
> I found a problem with the IPW2100/ieee80211 drivers which i think
> also affects other users of ieee80211 in stock 2.6.24 and earlier.
> 
> The function net/ieee80211/ieee80211_rx.c:update_network() gets called
> in response to a beacon or a probe response. It is responsible for
> updating the information we already have about the network described
> by the beacon or the probe response. At the beginning of the function
> is:
> 
>         /* We only update the statistics if they were created by receiving
>          * the network information on the actual channel the network is on.
>          *
>          * This keeps beacons received on neighbor channels from bringing
>          * down the signal level of an AP. */
>         if (dst->channel == src->stats.received_channel)
>                 memcpy(&dst->stats, &src->stats,
>                        sizeof(struct ieee80211_rx_stats));
>         else
>                 IEEE80211_DEBUG_SCAN("Network %s info received "
>                         "off channel (%d vs. %d)\n", print_mac(mac, src->bssid),
>                         dst->channel, src->stats.received_channel);
> 
> The problem is that the ipw2100 driver never fills in the
> stats.received_channel. So the RSSI and other link quality parameters
> never get updated. The RSSI is always the RSSI of the first frame
> which caused the network record to be created. 

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?

Dan



diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index 5bf9e00..8a3ce3a 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -2654,6 +2654,8 @@ static void __ipw2100_rx_process(struct ipw2100_priv *priv)
 			stats.mask |= IEEE80211_STATMASK_RSSI;
 		stats.freq = IEEE80211_24GHZ_BAND;
 
+		stats.received_channel = priv->channel;
+
 		IPW_DEBUG_RX("%s: '%s' frame type received (%d).\n",
 			     priv->net_dev->name, frame_types[frame_type],
 			     stats.len);

Re: Link Quality stats not updating, recieved_channel

[Andrew Lunn]

> 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.

But i will try it for in case i'm wrong.

    Andrew

Re: Link Quality stats not updating, recieved_channel

[Dan Williams]

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

Re: Link Quality stats not updating, recieved_channel

[Andrew Lunn]

> 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.

There is nothing obvious in the structures in the header file. That
was my first plan of attack to fix the problem.

> 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.

Well i would prefer to have lower strengths than way outdated
strengths from the first packet received.

          Andrew