* Re: mac80211 interprets missing TX_ACK flag as tx fail [not found] ` <1218822632.22679.73.camel@virkkmi-linux> @ 2008-08-15 17:58 ` Ivo van Doorn 2008-08-15 18:08 ` Mikko Virkkilä 0 siblings, 1 reply; 3+ messages in thread From: Ivo van Doorn @ 2008-08-15 17:58 UTC (permalink / raw) To: Mikko Virkkilä; +Cc: linux-wireless, rt2400-devel, Stephen Blackheath On Friday 15 August 2008, Mikko Virkkil=E4 wrote: > I'm moving the conversation over from rt2400-devel to linux-wireless. > The last message (as of this writing) from the earlier conversation a= t > rt2400-devel can be found at http://tinyurl.com/6p9n7g with some more > details. >=20 > So to summarize the situation:=20 >=20 > - the rt73usb driver (in rt2x00) doesn't set IEEE80211_TX_STAT_ACK > because "frames which are uploaded to the hardware are not guarente= ed > to be acked". rt2500usb suffers from the same issue. > - The mac80211 layer will set the IEEE80211_RADIOTAP_F_TX_FAIL if the= =20 > IEEE80211_TX_STAT_ACK flag is missing.=20 > - hostapd will interpret the IEEE80211_RADIOTAP_F_TX_FAIL as a failur= e > to send >=20 > This all results in hostapd reporting "MGMT (TX callback) fail" and > making rt73usb not work in AP mode.=20 >=20 > I'm hoping that some decision can be reached on how to fix this so th= at > AP mode will work with the rt73.=20 >=20 > Just off the top of my head, one way of fixing this would be to make > IEEE80211_TX_CTL_NO_ACK also work the other way around: Now it is use= d > to tell the lower level not to wait for an ACK. Perhaps it could also= be > used by the lower level to tell higher levels that no ACK is ever goi= ng > to come e.g. because the hardware is incapable of supplying TX ACKs. = The > mac80211 layer would be changed to check for IEEE80211_TX_CTL_NO_ACK.= If > the flag was set it would skip setting IEEE80211_RADIOTAP_F_TX_FAIL e= ven > when the IEEE80211_TX_STAT_ACK is missing. Actually this isn't the complete picture, what you might need is a new = flag IEEE80211_TX_CTL_UNKNOWN which then informs mac80211 that the frame has an unknown status, and that is something that could be passed= on to userspace through radiotap later. This is better then setting a global "supports ACK reporting" flag, bec= ause in case of rt61 one every x frames also has an unknown status because the txdon= e interrupt isn't happening for that frame. So that means you definately need a per= -frame flag to tell if the frame was acked, not-acked or if the status was unknown. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: mac80211 interprets missing TX_ACK flag as tx fail 2008-08-15 17:58 ` mac80211 interprets missing TX_ACK flag as tx fail Ivo van Doorn @ 2008-08-15 18:08 ` Mikko Virkkilä 2008-08-15 23:18 ` Ivo van Doorn 0 siblings, 1 reply; 3+ messages in thread From: Mikko Virkkilä @ 2008-08-15 18:08 UTC (permalink / raw) To: Ivo van Doorn; +Cc: linux-wireless, rt2400-devel, Stephen Blackheath On Fri, 2008-08-15 at 19:58 +0200, Ivo van Doorn wrote: > On Friday 15 August 2008, Mikko Virkkil=C3=A4 wrote: > > I'm moving the conversation over from rt2400-devel to linux-wireles= s. > > The last message (as of this writing) from the earlier conversation= at > > rt2400-devel can be found at http://tinyurl.com/6p9n7g with some mo= re > > details. > >=20 > > So to summarize the situation:=20 > >=20 > > - the rt73usb driver (in rt2x00) doesn't set IEEE80211_TX_STAT_ACK > > because "frames which are uploaded to the hardware are not guaren= teed > > to be acked". >=20 > rt2500usb suffers from the same issue. >=20 > > - The mac80211 layer will set the IEEE80211_RADIOTAP_F_TX_FAIL if t= he=20 > > IEEE80211_TX_STAT_ACK flag is missing.=20 > > - hostapd will interpret the IEEE80211_RADIOTAP_F_TX_FAIL as a fail= ure > > to send > >=20 > > This all results in hostapd reporting "MGMT (TX callback) fail" and > > making rt73usb not work in AP mode.=20 > >=20 > > I'm hoping that some decision can be reached on how to fix this so = that > > AP mode will work with the rt73.=20 > >=20 > > Just off the top of my head, one way of fixing this would be to mak= e > > IEEE80211_TX_CTL_NO_ACK also work the other way around: Now it is u= sed > > to tell the lower level not to wait for an ACK. Perhaps it could al= so be > > used by the lower level to tell higher levels that no ACK is ever g= oing > > to come e.g. because the hardware is incapable of supplying TX ACKs= =2E The > > mac80211 layer would be changed to check for IEEE80211_TX_CTL_NO_AC= K. If > > the flag was set it would skip setting IEEE80211_RADIOTAP_F_TX_FAIL= even > > when the IEEE80211_TX_STAT_ACK is missing. >=20 > Actually this isn't the complete picture, what you might need is a ne= w flag > IEEE80211_TX_CTL_UNKNOWN which then informs mac80211 that the > frame has an unknown status, and that is something that could be pass= ed on to > userspace through radiotap later. >=20 > This is better then setting a global "supports ACK reporting" flag, b= ecause in case > of rt61 one every x frames also has an unknown status because the txd= one interrupt > isn't happening for that frame. So that means you definately need a p= er-frame flag > to tell if the frame was acked, not-acked or if the status was unknow= n. >=20 > Ivo >From what I understand the IEEE80211_TX_CTL_NO_ACK which is in the flags of the ieee80211_tx_info struct, could be set from the driver for each frame just as currently (not) done with the IEEE80211_TX_STAT_ACK flag.=20 - Mikko -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: mac80211 interprets missing TX_ACK flag as tx fail 2008-08-15 18:08 ` Mikko Virkkilä @ 2008-08-15 23:18 ` Ivo van Doorn 0 siblings, 0 replies; 3+ messages in thread From: Ivo van Doorn @ 2008-08-15 23:18 UTC (permalink / raw) To: Mikko Virkkilä; +Cc: linux-wireless, rt2400-devel, Stephen Blackheath On Friday 15 August 2008, Mikko Virkkil=C3=A4 wrote: > On Fri, 2008-08-15 at 19:58 +0200, Ivo van Doorn wrote: > > On Friday 15 August 2008, Mikko Virkkil=C3=A4 wrote: > > > I'm moving the conversation over from rt2400-devel to linux-wirel= ess. > > > The last message (as of this writing) from the earlier conversati= on at > > > rt2400-devel can be found at http://tinyurl.com/6p9n7g with some = more > > > details. > > >=20 > > > So to summarize the situation:=20 > > >=20 > > > - the rt73usb driver (in rt2x00) doesn't set IEEE80211_TX_STAT_AC= K > > > because "frames which are uploaded to the hardware are not guar= enteed > > > to be acked". > >=20 > > rt2500usb suffers from the same issue. > >=20 > > > - The mac80211 layer will set the IEEE80211_RADIOTAP_F_TX_FAIL if= the=20 > > > IEEE80211_TX_STAT_ACK flag is missing.=20 > > > - hostapd will interpret the IEEE80211_RADIOTAP_F_TX_FAIL as a fa= ilure > > > to send > > >=20 > > > This all results in hostapd reporting "MGMT (TX callback) fail" a= nd > > > making rt73usb not work in AP mode.=20 > > >=20 > > > I'm hoping that some decision can be reached on how to fix this s= o that > > > AP mode will work with the rt73.=20 > > >=20 > > > Just off the top of my head, one way of fixing this would be to m= ake > > > IEEE80211_TX_CTL_NO_ACK also work the other way around: Now it is= used > > > to tell the lower level not to wait for an ACK. Perhaps it could = also be > > > used by the lower level to tell higher levels that no ACK is ever= going > > > to come e.g. because the hardware is incapable of supplying TX AC= Ks. The > > > mac80211 layer would be changed to check for IEEE80211_TX_CTL_NO_= ACK. If > > > the flag was set it would skip setting IEEE80211_RADIOTAP_F_TX_FA= IL even > > > when the IEEE80211_TX_STAT_ACK is missing. > >=20 > > Actually this isn't the complete picture, what you might need is a = new flag > > IEEE80211_TX_CTL_UNKNOWN which then informs mac80211 that the > > frame has an unknown status, and that is something that could be pa= ssed on to > > userspace through radiotap later. > >=20 > > This is better then setting a global "supports ACK reporting" flag,= because in case > > of rt61 one every x frames also has an unknown status because the t= xdone interrupt > > isn't happening for that frame. So that means you definately need a= per-frame flag > > to tell if the frame was acked, not-acked or if the status was unkn= own. > >=20 > > Ivo >=20 > >From what I understand the IEEE80211_TX_CTL_NO_ACK which is in the > flags of the ieee80211_tx_info struct, could be set from the driver f= or > each frame just as currently (not) done with the IEEE80211_TX_STAT_AC= K > flag.=20 Yes, but my comment was regarding your proposal regarding the "driver is incapable of supplying TX Acks to upper layer" which would suggest it would be a global setting instead of a per-frame setting. And my point was that you want this to be a per-frame setting similar to IEEE80211_TX_CTL_NO_ACK Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-08-15 23:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1218813764.22679.11.camel@virkkmi-linux>
[not found] ` <200808151844.13657.IvDoorn@gmail.com>
[not found] ` <1218822632.22679.73.camel@virkkmi-linux>
2008-08-15 17:58 ` mac80211 interprets missing TX_ACK flag as tx fail Ivo van Doorn
2008-08-15 18:08 ` Mikko Virkkilä
2008-08-15 23:18 ` Ivo van Doorn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).