Am Dienstag, 24. Februar 2009 schrieb Zhu Yi: [...] > Thanks for the analysis. Are you sure noop_qdisc is still used when we > are about to netif_carrier_on() after receiving the association success > response? Yes, had a printk in noop_enqueue. > From dev_open(), dev_activate() is called after netdev->open. > So the txq->qdisc_sleeping should be already replaced with pfifo_fast. > But the state is still DEACTIVATED. Right. But for example when a connection cannot be established by ipw2100 it will call netif_carrier_off on disassociation which in turn leads to a call to dev_deavtivate. Hence, it is possible that a noop_qdisc is assigned while the device is up and carrier is off. > Should the packet from > wpa_supplicant be dropped by dev_queue_xmit()? > > > So, how should I proceed here? > > > > Some possibilities that come to mind: > > > > 1) let the noop_qdisc return NET_XMIT_DROP instead of NET_XMIT_CN and extend > > wpa_supplicant to retry after a short timeout. Already tried this approach > > and it works fine for me. wpa_supplicant typically needs one retry (200ms > > delay) until the frame is successfully send out. > > > > 2) Run activate_dev somehow without a delay. I guess this could be achieved by > > changing linkwatch_urgent_event. I haven't tested this yet. But I guess we > > would still have a small race here. > > > > 3) Wait until activate_dev was called in ipw2100 before replaying the cached > > frames. > > I think making a sync version of netif_carrier_on/activate_dev should be > the way to go. This could be a requirement from wireless. In wired > network, netif_carrier_on() is called after a network cable plug event > is detected. Some delay should be OK. Maybe, but I can imagine a similar race when using a wired 802.1x secured network. The switch might send an EAP-request very quickly after the carrier was detected. > But in wireless, > netif_carrier_on() is usually called after an association is succeeded. > The driver has already some management frames transfered with AP. Now > it's the time to open the data frame transmission. The driver requires > to get the activate_dev() result (synchronously or via callback) because > otherwise the driver has no idea when the Qdisc is ready and then it can > start to deliver data frames to network stack and user space. Exactly. [...] Helmut -- 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
