On Fri, Jan 4, 2013 at 6:56 AM, Bob Copeland <[email protected]> wrote:
> On Mon, Oct 15, 2012 at 09:47:07AM -0700, Javier Cardona wrote: > > On Mon, Oct 15, 2012 at 6:20 AM, Bob Copeland <[email protected]> > wrote: > > > On Sat, Oct 13, 2012 at 02:18:35AM -0400, fred veldini wrote: > > >> [ 562.522699] XXX: frame: 00000000: d0 00 00 00 ff ff ff ff ff ff 00 > 15 6d > > >> 94 5a 39 ............m.Z9 > > >> [ 562.522705] XXX: frame: 00000010: 00 15 6d 94 5a 39 00 00 0d 01 84 > 0f 1f > > >> 01 ..m.Z9........ > > > > That 0d 01 is a mesh action is a peer link open frame, sent from > > authsae. But authsae does not fill out the rate info; it just uses > > the NL80211_CMD_FRAME to send management frames from userspace. See > > Actually this looks like a PERR frame (0x84 = 132 = PERR eid), so > perhaps this one originated in the kernel? > Indeed! The next bytes confirm it: 0f: ie_len (15) 1f: ttl (31) 01: num_destinations (1) I sent Fred this patch off-list (note, I think the memset is unneeded > since dev_alloc_skb zeroes the cb). The missing flag would explain why > there are no rates in the packet and might account for the ath9k crash > on 5 ghz-only cards (zero band would be interpreted as 2 ghz). > > diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c > index f0b384e..93c9648 100644 > --- a/net/mac80211/mesh_hwmp.c > +++ b/net/mac80211/mesh_hwmp.c > @@ -214,7 +214,10 @@ static void prepare_frame_for_deferred_tx(struct > ieee80211_sub_if_data *sdata, > skb_set_queue_mapping(skb, IEEE80211_AC_VO); > skb->priority = 7; > > + memset(info, 0, sizeof(*info)); > info->control.vif = &sdata->vif; > + info->control.jiffies = jiffies; > + info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING; > ieee80211_set_qos_hdr(sdata, skb); > } > > Looks like a valid fix. > ... however, he now reports this error: > > [ 220.838000] ------------[ cut here ]------------ > [ 220.838908] WARNING: at > /devel/compat-drivers-3.7-rc1-6-noHT5Gig/net/mac80211/wpa.c:427 > ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]() > [ 221.532067] Call Trace: > [ 221.546693] [<c011c5e7>] warn_slowpath_common+0x63/0x78 > [ 221.578517] [<e090621d>] ? ccmp_encrypt_skb.isra.5+0x7b/0x1a0 > [mac80211] > [ 221.619159] [<c011c60b>] warn_slowpath_null+0xf/0x13 > [ 221.649433] [<e090621d>] ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211] > [ 221.689055] [<e092a3f7>] ? minstrel_ht_get_rate+0x23/0x276 [mac80211] > [ 221.728134] [<c034dc3c>] ? kfree_skb+0x24/0x26 > [ 221.755296] [<e090e151>] ? rate_control_get_rate+0x8d/0x202 [mac80211] > [ 221.794907] [<e090685c>] ieee80211_crypto_ccmp_encrypt+0x1f/0x37 > [mac80211] > [ 221.837127] [<e0917113>] invoke_tx_handlers+0xcad/0x10bd [mac80211] > [ 221.875186] [<e0915335>] ? ieee80211_prepare_and_rx_handle+0x7dd/0x85b > [mac80211] > [ 221.920523] [<e0917665>] ieee80211_tx+0x87/0xb3 [mac80211] > [ 221.953904] [<e0918932>] ieee80211_tx_pending+0xcc/0x170 [mac80211] > [ 221.991939] [<c0121c43>] tasklet_action+0x3e/0x65 > [ 222.020635] [<c0121e0d>] __do_softirq+0x75/0x104 > [ 222.048786] [<c0121d98>] ? send_remote_softirq+0x22/0x22 > [ 222.081096] <IRQ> [<c0121f4c>] ? irq_exit+0x34/0x8a > [ 222.111410] [<c010349f>] ? do_IRQ+0x76/0x89 > [ 222.136939] [<c03f8f2c>] ? common_interrupt+0x2c/0x31 > [ 222.167668] [<c015007b>] ? audit_receive+0x20e/0x834 > [ 222.197927] [<c01073cb>] ? default_idle+0x21/0x3b > [ 222.226623] [<c0107a5b>] ? cpu_idle+0x3f/0x72 > [ 222.253197] [<c03ed717>] ? rest_init+0x63/0x65 > [ 222.280332] [<c05288bc>] ? start_kernel+0x297/0x29c > [ 222.310017] [<c05282ae>] ? i386_start_kernel+0x78/0x7d > [ 222.341261] ---[ end trace 958482fcd072de83 ]--- > > I believe this is: > > if (WARN_ON(skb_tailroom(skb) < tail || > skb_headroom(skb) < CCMP_HDR_LEN)) > return -1; > > ... but offhand I'm not sure what is the right approach here, whether > we should be adding IEEE80211_ENCRYPT_HEADROOM in the initial allocation > or whether there's something missing such that ieee80211_skb_resize() > path isn't encountered. > Mesh mgmt frames are transmitted in to ways: 1. immediately, via ieee80211_tx_skb(), which eventually calls ieee80211_xmit(), which sets IEEE80211_ENCRYPT_HEADROOM OR 2. deferred, via ieee80211_add_pending_skb(), then ieee80211_tx_pending() -> ieee80211_tx_pending_skb(), which will process the frame differently depending on IEEE80211_TX_INTFL_NEED_TXPROCESSING, and eventually __ieee80211_tx(). PERR frames belong to the second type, and yes, probably we need to add IEEE80211_ENCRYPT_HEADROOM/TAILROOM on allocation and skb_reserve() > Just for grins, Fred, can you try this on top of the original patch? > > diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c > index 47aeee2..c59a265 100644 > --- a/net/mac80211/mesh_hwmp.c > +++ b/net/mac80211/mesh_hwmp.c > @@ -246,11 +246,13 @@ int mesh_path_error_tx(u8 ttl, u8 *target, __le32 > target_sn, > return -EAGAIN; > > skb = dev_alloc_skb(local->tx_headroom + > + IEEE80211_ENCRYPT_HEADROOM + > + IEEE80211_ENCRYPT_TAILROOM + > hdr_len + > 2 + 15 /* PERR IE */); > if (!skb) > return -1; > - skb_reserve(skb, local->tx_headroom); > + skb_reserve(skb, local->tx_headroom + IEEE80211_ENCRYPT_HEADROOM); > mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len); > memset(mgmt, 0, hdr_len); > mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT | > This looks like the right fix. Thanks! Javier
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
