On Mon, 2007-06-11 at 12:11 +0800, Zhu Yi wrote:
> > > + case WIFI_OUI_STYPE_WMM_TSPEC:
> > > + if (elen != 61) {
> > > + printk(KERN_ERR "Wrong "
> > > + "TSPEC size.\n");
> > > + break;
> >
> > That printk should be rate limited.
>
> Umm, I followed the same way as other MLME parsing functions ie.
> ieee80211_rx_mgmt_assoc_resp. It seems they also didn't rate limit these
> cases. This only happens on broken APs. Do you think we really need to
> rate limit here?
Ok, wrt. all the rate limiting I thought of. You rightfully pointed out
that the current code is just as broken, hence I'm ok with adding these
like this and I'll go through and fix them later. My rationale with many
of these is that somebody could inject random packets appearing to come
from our AP and cause us to write a log line for every packet they
inject by intentionally injecting malformed packets. We should protect
against that.
> I got a lot of this message during my testing. The APs use some
> (private) OUIs we don't support now. I guess there will be quite a lot
> messages even if we rate limit here.
Oh right, like those Broadcom IEs they use for a-mpdu even on .11G...
> Yes we can do this. But free it here helps to shrink the hash table
> size. The problem is: the original sta_info doesn't a status -- if a
> sta_info appears in the hash table, it is active; otherwise it is not.
> But since DLS requires setup stage, I added the status code to
> distinguish setuping and active. But for inactive state, we can either
> set the DLS status to inactive or remove the sta_info completely. Since
> normally a DLS connection won't be setup and teardown that often, I
> select to free the sta_info to indicate it as inactive.
Makes sense. I thought we had a sta info item for each peer we ever
discovered but I guess that isn't true.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
