* attempting mesh on ath10k
@ 2015-04-24 12:50 Bob Copeland
2015-04-24 17:55 ` Yeoh Chun-Yeow
0 siblings, 1 reply; 24+ messages in thread
From: Bob Copeland @ 2015-04-24 12:50 UTC (permalink / raw)
To: ath10k
Hi all,
I have played around a little bit with the raw mode patches trying to
get mesh working on ath10k. I've hacked the driver slightly to use an
AP vif in the firmware in "mesh" mode, which seems to produce proper looking
beacons over the air.
However, when I bring up a second mesh node, the ath10k device crashes
upon trying to send the first mesh peering action frame. Here's what
dmesg looks like:
[ 43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140
[ 44.310000] XXX trying to create peer 00:03:7f:10:4e:2d
[ 44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d
[ 44.320000] XXX sending WMI cmd 36892
[ 44.320000] XXX sending WMI cmd nowait 36892
[ 44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d
[ 44.330000] XXX peer 00:03:7f:10:4e:2d added
[ 44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new)
[ 44.350000] XXX sending WMI cmd 36896
[ 44.350000] XXX sending WMI cmd nowait 36896
[ 44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented
[ 44.360000] mesh: sending popen to 00:03:7f:10:4e:2d
[ 44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0
[ 44.390000] XXX sending WMI cmd 36905
[ 44.390000] XXX sending WMI cmd nowait 36905
[ 44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c
[ 44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a
[ 44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
[ 44.420000] ath10k_pci 0000:01:00.0: firmware register dump:
[ 44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31
[ 44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00
[ 44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078
[ 44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B
[ 44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000
[ 44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677
[ 44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE
[ 44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04
[ 44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04
[ 44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8
[ 44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688
[ 44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44
[ 44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000
[ 44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350
[ 44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001
My hacky compat-wireless snapshot is over here, any suggestions on what to
try next to debug further are welcome:
https://github.com/bcopeland/ath10k-mesh
[Also I tried skipping the mgmt tx datapath and use normal datapath,
as seen in the final patch, but that doesn't change things, it crashes
either way.]
Maybe I'm not setting up peers correctly or something like that?
--
Bob Copeland %% http://bobcopeland.com/
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: attempting mesh on ath10k 2015-04-24 12:50 attempting mesh on ath10k Bob Copeland @ 2015-04-24 17:55 ` Yeoh Chun-Yeow 2015-04-25 1:38 ` Ben Greear 2015-04-28 12:41 ` Bob Copeland 0 siblings, 2 replies; 24+ messages in thread From: Yeoh Chun-Yeow @ 2015-04-24 17:55 UTC (permalink / raw) To: Bob Copeland, Ben Greear; +Cc: ath10k@lists.infradead.org Hi, Bob I have tried converting the "adhoc" mode on the firmware-2.bin_999.999.0.636 as mesh interface. You can find my patches here: https://github.com/chunyeow/ath/commits/mesh But probably too many workaround and won't be able to interoperate with other mesh interface. I have also found out the immediate crashes when peer mesh STA is added by the firmware if using "AP" mode. https://github.com/chunyeow/ath/commit/c09a7ef83a5912d1965756b9ce4c9a22ae1dcf08 Hi, Ben You have any updates on CT firmware to support the mesh mode? Please advice. Thanks --- Chun-Yeow On Fri, Apr 24, 2015 at 8:50 PM, Bob Copeland <me@bobcopeland.com> wrote: > Hi all, > > I have played around a little bit with the raw mode patches trying to > get mesh working on ath10k. I've hacked the driver slightly to use an > AP vif in the firmware in "mesh" mode, which seems to produce proper looking > beacons over the air. > > However, when I bring up a second mesh node, the ath10k device crashes > upon trying to send the first mesh peering action frame. Here's what > dmesg looks like: > > [ 43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140 > [ 44.310000] XXX trying to create peer 00:03:7f:10:4e:2d > [ 44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d > [ 44.320000] XXX sending WMI cmd 36892 > [ 44.320000] XXX sending WMI cmd nowait 36892 > [ 44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d > [ 44.330000] XXX peer 00:03:7f:10:4e:2d added > [ 44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new) > [ 44.350000] XXX sending WMI cmd 36896 > [ 44.350000] XXX sending WMI cmd nowait 36896 > [ 44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented > [ 44.360000] mesh: sending popen to 00:03:7f:10:4e:2d > [ 44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0 > [ 44.390000] XXX sending WMI cmd 36905 > [ 44.390000] XXX sending WMI cmd nowait 36905 > [ 44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c > [ 44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a > [ 44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1 > [ 44.420000] ath10k_pci 0000:01:00.0: firmware register dump: > [ 44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31 > [ 44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00 > [ 44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078 > [ 44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B > [ 44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000 > [ 44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677 > [ 44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE > [ 44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04 > [ 44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04 > [ 44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8 > [ 44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688 > [ 44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44 > [ 44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000 > [ 44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350 > [ 44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001 > > My hacky compat-wireless snapshot is over here, any suggestions on what to > try next to debug further are welcome: > > https://github.com/bcopeland/ath10k-mesh > > [Also I tried skipping the mgmt tx datapath and use normal datapath, > as seen in the final patch, but that doesn't change things, it crashes > either way.] > > Maybe I'm not setting up peers correctly or something like that? > > -- > Bob Copeland %% http://bobcopeland.com/ > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-24 17:55 ` Yeoh Chun-Yeow @ 2015-04-25 1:38 ` Ben Greear 2015-04-26 14:15 ` Bob Copeland 2015-04-28 12:41 ` Bob Copeland 1 sibling, 1 reply; 24+ messages in thread From: Ben Greear @ 2015-04-25 1:38 UTC (permalink / raw) To: Yeoh Chun-Yeow, Bob Copeland; +Cc: ath10k@lists.infradead.org On 04/24/2015 10:55 AM, Yeoh Chun-Yeow wrote: > Hi, Bob > > I have tried converting the "adhoc" mode on the > firmware-2.bin_999.999.0.636 as mesh interface. > > You can find my patches here: > https://github.com/chunyeow/ath/commits/mesh > > But probably too many workaround and won't be able to interoperate > with other mesh interface. > > I have also found out the immediate crashes when peer mesh STA is > added by the firmware if using "AP" mode. > https://github.com/chunyeow/ath/commit/c09a7ef83a5912d1965756b9ce4c9a22ae1dcf08 > > Hi, Ben > > You have any updates on CT firmware to support the mesh mode? > > Please advice. Thanks I have IBSS support working, and at least non-encrypted raw transmit can work in my firmware, though raw tx requires Michal's RFC patch he posted some time ago. Don't know about mesh, but if you can crash my firmware, please send me the debug info and I'll see if I can figure out why. I am not sure raw tx with encryption is possible...and at the least, it is probably not something I'll attempt to do for fun anytime soon. Thanks, Ben > > --- > Chun-Yeow > > > On Fri, Apr 24, 2015 at 8:50 PM, Bob Copeland <me@bobcopeland.com> wrote: >> Hi all, >> >> I have played around a little bit with the raw mode patches trying to >> get mesh working on ath10k. I've hacked the driver slightly to use an >> AP vif in the firmware in "mesh" mode, which seems to produce proper looking >> beacons over the air. >> >> However, when I bring up a second mesh node, the ath10k device crashes >> upon trying to send the first mesh peering action frame. Here's what >> dmesg looks like: >> >> [ 43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140 >> [ 44.310000] XXX trying to create peer 00:03:7f:10:4e:2d >> [ 44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d >> [ 44.320000] XXX sending WMI cmd 36892 >> [ 44.320000] XXX sending WMI cmd nowait 36892 >> [ 44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d >> [ 44.330000] XXX peer 00:03:7f:10:4e:2d added >> [ 44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new) >> [ 44.350000] XXX sending WMI cmd 36896 >> [ 44.350000] XXX sending WMI cmd nowait 36896 >> [ 44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented >> [ 44.360000] mesh: sending popen to 00:03:7f:10:4e:2d >> [ 44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0 >> [ 44.390000] XXX sending WMI cmd 36905 >> [ 44.390000] XXX sending WMI cmd nowait 36905 >> [ 44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c >> [ 44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a >> [ 44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1 >> [ 44.420000] ath10k_pci 0000:01:00.0: firmware register dump: >> [ 44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31 >> [ 44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00 >> [ 44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078 >> [ 44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B >> [ 44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000 >> [ 44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677 >> [ 44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE >> [ 44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04 >> [ 44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04 >> [ 44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8 >> [ 44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688 >> [ 44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44 >> [ 44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000 >> [ 44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350 >> [ 44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001 >> >> My hacky compat-wireless snapshot is over here, any suggestions on what to >> try next to debug further are welcome: >> >> https://github.com/bcopeland/ath10k-mesh >> >> [Also I tried skipping the mgmt tx datapath and use normal datapath, >> as seen in the final patch, but that doesn't change things, it crashes >> either way.] >> >> Maybe I'm not setting up peers correctly or something like that? >> >> -- >> Bob Copeland %% http://bobcopeland.com/ >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-25 1:38 ` Ben Greear @ 2015-04-26 14:15 ` Bob Copeland 2015-04-26 15:42 ` Ben Greear 2015-04-27 13:00 ` Bob Copeland 0 siblings, 2 replies; 24+ messages in thread From: Bob Copeland @ 2015-04-26 14:15 UTC (permalink / raw) To: Ben Greear; +Cc: Yeoh Chun-Yeow, ath10k@lists.infradead.org On Fri, Apr 24, 2015 at 06:38:02PM -0700, Ben Greear wrote: > I have IBSS support working, and at least non-encrypted raw transmit > can work in my firmware, though raw tx requires Michal's RFC patch > he posted some time ago. (Michal's RFC patch is in my repo.) So I got a bit further. I was still getting a crash with CT firmware, but, suspecting that we pass something invalid in assoc message for mesh, I forced peer->aid = 1 and then it no longer crashes shortly after adding the first peer on either CT or QCA firmware. I pushed that hack into my repo for now -- I think we want to rethink how and when AIDs are generated in mesh. # iw dev wlan0 station dump Station 00:03:7f:10:4e:2d (on wlan0) inactive time: 400 ms rx bytes: 34019 rx packets: 959 tx bytes: 152 tx packets: 3 tx retries: 0 tx failed: 0 signal: -27 dBm signal avg: -26 dBm tx bitrate: 6.0 MBit/s rx bitrate: 9.0 MBit/s mesh llid: 220 mesh plid: 455 mesh plink: ESTAB mesh local PS mode: ACTIVE mesh peer PS mode: ACTIVE mesh non-peer PS mode: ACTIVE authorized: yes authenticated: yes preamble: long WMM/WME: yes MFP: no TDLS peer: no So, progress! There's still an issue with datapath -- while it looks like we can establish plinks, I couldn't get unicast traffic flowing even if manually setting up mpaths and arp table entries. I haven't yet got all of my 5 ghz capable gear in the same room to monitor and see where the problem lies. -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-26 14:15 ` Bob Copeland @ 2015-04-26 15:42 ` Ben Greear 2015-04-27 13:00 ` Bob Copeland 1 sibling, 0 replies; 24+ messages in thread From: Ben Greear @ 2015-04-26 15:42 UTC (permalink / raw) To: Bob Copeland; +Cc: Yeoh Chun-Yeow, ath10k@lists.infradead.org On 04/26/2015 07:15 AM, Bob Copeland wrote: > On Fri, Apr 24, 2015 at 06:38:02PM -0700, Ben Greear wrote: >> I have IBSS support working, and at least non-encrypted raw transmit >> can work in my firmware, though raw tx requires Michal's RFC patch >> he posted some time ago. > > (Michal's RFC patch is in my repo.) > > So I got a bit further. I was still getting a crash with CT firmware, but, > suspecting that we pass something invalid in assoc message for mesh, I forced > peer->aid = 1 and then it no longer crashes shortly after adding the first > peer on either CT or QCA firmware. Please send me the crash dump...and let me know the firmware version if the info is not in the dump. Thanks, Ben > > I pushed that hack into my repo for now -- I think we want to rethink how and > when AIDs are generated in mesh. > > # iw dev wlan0 station dump > Station 00:03:7f:10:4e:2d (on wlan0) > inactive time: 400 ms > rx bytes: 34019 > rx packets: 959 > tx bytes: 152 > tx packets: 3 > tx retries: 0 > tx failed: 0 > signal: -27 dBm > signal avg: -26 dBm > tx bitrate: 6.0 MBit/s > rx bitrate: 9.0 MBit/s > mesh llid: 220 > mesh plid: 455 > mesh plink: ESTAB > mesh local PS mode: ACTIVE > mesh peer PS mode: ACTIVE > mesh non-peer PS mode: ACTIVE > authorized: yes > authenticated: yes > preamble: long > WMM/WME: yes > MFP: no > TDLS peer: no > > So, progress! > > There's still an issue with datapath -- while it looks like we can establish > plinks, I couldn't get unicast traffic flowing even if manually setting up > mpaths and arp table entries. I haven't yet got all of my 5 ghz capable gear > in the same room to monitor and see where the problem lies. > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-26 14:15 ` Bob Copeland 2015-04-26 15:42 ` Ben Greear @ 2015-04-27 13:00 ` Bob Copeland 2015-04-28 5:47 ` Michal Kazior 1 sibling, 1 reply; 24+ messages in thread From: Bob Copeland @ 2015-04-27 13:00 UTC (permalink / raw) To: Ben Greear; +Cc: Yeoh Chun-Yeow, ath10k@lists.infradead.org On Sun, Apr 26, 2015 at 10:15:52AM -0400, Bob Copeland wrote: > So, progress! > > There's still an issue with datapath -- while it looks like we can establish > plinks, I couldn't get unicast traffic flowing even if manually setting up > mpaths and arp table entries. I haven't yet got all of my 5 ghz capable gear > in the same room to monitor and see where the problem lies. Now I had a chance to monitor it, and in so doing, rediscovered this patch of Chun-Yeow's: http://lists.infradead.org/pipermail/ath10k/2014-September/003206.html In fact my broadcasts were truncated and the above change makes the broadcast ARPs look correct over the air. The (non-ath10k) target mesh STA replies with broadcast PREQ but that is not received / processed / replied-to by the ath10k device. Perhaps there is a BSSID filter enabled or something like that (in mesh there's no BSSID, just individual addresses on group addressed frames). -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-27 13:00 ` Bob Copeland @ 2015-04-28 5:47 ` Michal Kazior 2015-04-28 12:25 ` Bob Copeland 0 siblings, 1 reply; 24+ messages in thread From: Michal Kazior @ 2015-04-28 5:47 UTC (permalink / raw) To: Bob Copeland; +Cc: Ben Greear, Yeoh Chun-Yeow, ath10k@lists.infradead.org On 27 April 2015 at 15:00, Bob Copeland <me@bobcopeland.com> wrote: > On Sun, Apr 26, 2015 at 10:15:52AM -0400, Bob Copeland wrote: >> So, progress! >> >> There's still an issue with datapath -- while it looks like we can establish >> plinks, I couldn't get unicast traffic flowing even if manually setting up >> mpaths and arp table entries. I haven't yet got all of my 5 ghz capable gear >> in the same room to monitor and see where the problem lies. > > Now I had a chance to monitor it, and in so doing, rediscovered this patch of > Chun-Yeow's: > > http://lists.infradead.org/pipermail/ath10k/2014-September/003206.html > > In fact my broadcasts were truncated and the above change makes the broadcast > ARPs look correct over the air. The (non-ath10k) target mesh STA replies with > broadcast PREQ but that is not received / processed / replied-to by the > ath10k device. > > Perhaps there is a BSSID filter enabled or something like that (in mesh > there's no BSSID, just individual addresses on group addressed frames). In that case try creating a monitor interface and bring it up. This should prompt ath10k to create monitor vdev and subsequently disable most Rx filters in firmware. Michał _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-28 5:47 ` Michal Kazior @ 2015-04-28 12:25 ` Bob Copeland 2015-05-27 6:51 ` Bartosz Markowski 0 siblings, 1 reply; 24+ messages in thread From: Bob Copeland @ 2015-04-28 12:25 UTC (permalink / raw) To: Michal Kazior; +Cc: Ben Greear, Yeoh Chun-Yeow, ath10k@lists.infradead.org On Tue, Apr 28, 2015 at 07:47:40AM +0200, Michal Kazior wrote: > > Perhaps there is a BSSID filter enabled or something like that (in mesh > > there's no BSSID, just individual addresses on group addressed frames). > > In that case try creating a monitor interface and bring it up. This > should prompt ath10k to create monitor vdev and subsequently disable > most Rx filters in firmware. Indeed, that did the trick, thanks! So mesh is functional now with raw mode patch and a few hacks: root@archer:~# iw dev phy#0 Interface mon0 ifindex 8 wdev 0x2 addr e8:de:27:d6:9c:d0 type monitor Interface wlan0 ifindex 4 wdev 0x1 addr e8:de:27:d6:9c:d0 type mesh point channel 149 (5745 MHz), width: 20 MHz (no HT), center1: 5745 MHz root@archer:~# ping 10.10.10.13 PING 10.10.10.13 (10.10.10.13): 56 data bytes 64 bytes from 10.10.10.13: seq=0 ttl=64 time=10.031 ms 64 bytes from 10.10.10.13: seq=1 ttl=64 time=1.074 ms 64 bytes from 10.10.10.13: seq=2 ttl=64 time=1.074 ms 64 bytes from 10.10.10.13: seq=3 ttl=64 time=1.082 ms 64 bytes from 10.10.10.13: seq=4 ttl=64 time=1.032 ms 64 bytes from 10.10.10.13: seq=5 ttl=64 time=2.905 ms 64 bytes from 10.10.10.13: seq=6 ttl=64 time=1.093 ms 64 bytes from 10.10.10.13: seq=7 ttl=64 time=1.205 ms 64 bytes from 10.10.10.13: seq=8 ttl=64 time=1.057 ms 64 bytes from 10.10.10.13: seq=9 ttl=64 time=1.039 ms 64 bytes from 10.10.10.13: seq=10 ttl=64 time=1.107 ms 64 bytes from 10.10.10.13: seq=11 ttl=64 time=1.040 ms ^C --- 10.10.10.13 ping statistics --- 12 packets transmitted, 12 packets received, 0% packet loss round-trip min/avg/max = 1.032/1.978/10.031 ms root@archer:~# iw dev wlan0 mpath dump DEST ADDR NEXT HOP IFACE SN METRIC QLEN EXPTIME DTIM DRET FLAGS 00:03:7f:10:4e:2d 00:03:7f:10:4e:2d wlan0 2427 1366 0 0 100 0 0x4 -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-28 12:25 ` Bob Copeland @ 2015-05-27 6:51 ` Bartosz Markowski 2015-05-27 11:12 ` Bob Copeland 0 siblings, 1 reply; 24+ messages in thread From: Bartosz Markowski @ 2015-05-27 6:51 UTC (permalink / raw) To: Bob Copeland; +Cc: ath10k@lists.infradead.org On 28 April 2015 at 14:25, Bob Copeland <me@bobcopeland.com> wrote: > On Tue, Apr 28, 2015 at 07:47:40AM +0200, Michal Kazior wrote: >> > Perhaps there is a BSSID filter enabled or something like that (in mesh >> > there's no BSSID, just individual addresses on group addressed frames). >> >> In that case try creating a monitor interface and bring it up. This >> should prompt ath10k to create monitor vdev and subsequently disable >> most Rx filters in firmware. Are there any plans to push this work upstream? Regards, Bartosz _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-05-27 6:51 ` Bartosz Markowski @ 2015-05-27 11:12 ` Bob Copeland 2015-05-27 11:15 ` Bartosz Markowski 0 siblings, 1 reply; 24+ messages in thread From: Bob Copeland @ 2015-05-27 11:12 UTC (permalink / raw) To: Bartosz Markowski; +Cc: ath10k@lists.infradead.org On Wed, May 27, 2015 at 08:51:05AM +0200, Bartosz Markowski wrote: > On 28 April 2015 at 14:25, Bob Copeland <me@bobcopeland.com> wrote: > > On Tue, Apr 28, 2015 at 07:47:40AM +0200, Michal Kazior wrote: > >> > Perhaps there is a BSSID filter enabled or something like that (in mesh > >> > there's no BSSID, just individual addresses on group addressed frames). > >> > >> In that case try creating a monitor interface and bring it up. This > >> should prompt ath10k to create monitor vdev and subsequently disable > >> most Rx filters in firmware. > > Are there any plans to push this work upstream? Hi Bartosz, Yes, I plan to upstream it. I'm waiting on a hardware to arrive so I can implement VHT mesh with two ath10k chips; once that's in and working I'll clean it up and submit. -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-05-27 11:12 ` Bob Copeland @ 2015-05-27 11:15 ` Bartosz Markowski 0 siblings, 0 replies; 24+ messages in thread From: Bartosz Markowski @ 2015-05-27 11:15 UTC (permalink / raw) To: Bob Copeland; +Cc: ath10k@lists.infradead.org On 27 May 2015 at 13:12, Bob Copeland <me@bobcopeland.com> wrote: > On Wed, May 27, 2015 at 08:51:05AM +0200, Bartosz Markowski wrote: [...] >> Are there any plans to push this work upstream? > > Hi Bartosz, > > Yes, I plan to upstream it. I'm waiting on a hardware to arrive so I can > implement VHT mesh with two ath10k chips; once that's in and working I'll > clean it up and submit. Great! Thanks for your effort. -- Bartosz _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-24 17:55 ` Yeoh Chun-Yeow 2015-04-25 1:38 ` Ben Greear @ 2015-04-28 12:41 ` Bob Copeland 2015-04-28 12:50 ` Yeoh Chun-Yeow 1 sibling, 1 reply; 24+ messages in thread From: Bob Copeland @ 2015-04-28 12:41 UTC (permalink / raw) To: Yeoh Chun-Yeow; +Cc: Ben Greear, ath10k@lists.infradead.org On Sat, Apr 25, 2015 at 01:55:32AM +0800, Chun-Yeow Yeoh wrote: > Hi, Bob > > I have tried converting the "adhoc" mode on the > firmware-2.bin_999.999.0.636 as mesh interface. > > You can find my patches here: > https://github.com/chunyeow/ath/commits/mesh > > But probably too many workaround and won't be able to interoperate > with other mesh interface. Yeah, I think adhoc will not work so well due to TSF sync and the distributed beacon algorithm. So I'm happy that AP approach seems viable; of course dedicated mesh vdev type would be nice :) -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-28 12:41 ` Bob Copeland @ 2015-04-28 12:50 ` Yeoh Chun-Yeow 2015-04-28 12:57 ` Bob Copeland 0 siblings, 1 reply; 24+ messages in thread From: Yeoh Chun-Yeow @ 2015-04-28 12:50 UTC (permalink / raw) To: Bob Copeland; +Cc: Ben Greear, ath10k@lists.infradead.org Great works, Bob. Which AP firmware that you have tested with? ---- Chun-Yeow On Tue, Apr 28, 2015 at 8:41 PM, Bob Copeland <me@bobcopeland.com> wrote: > On Sat, Apr 25, 2015 at 01:55:32AM +0800, Chun-Yeow Yeoh wrote: >> Hi, Bob >> >> I have tried converting the "adhoc" mode on the >> firmware-2.bin_999.999.0.636 as mesh interface. >> >> You can find my patches here: >> https://github.com/chunyeow/ath/commits/mesh >> >> But probably too many workaround and won't be able to interoperate >> with other mesh interface. > > Yeah, I think adhoc will not work so well due to TSF sync and the > distributed beacon algorithm. So I'm happy that AP approach seems > viable; of course dedicated mesh vdev type would be nice :) > > -- > Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-28 12:50 ` Yeoh Chun-Yeow @ 2015-04-28 12:57 ` Bob Copeland 2015-04-28 14:47 ` Ben Greear 0 siblings, 1 reply; 24+ messages in thread From: Bob Copeland @ 2015-04-28 12:57 UTC (permalink / raw) To: Yeoh Chun-Yeow; +Cc: Ben Greear, ath10k@lists.infradead.org On Tue, Apr 28, 2015 at 08:50:01PM +0800, Chun-Yeow Yeoh wrote: > Great works, Bob. > > Which AP firmware that you have tested with? That is with: [ 16.670000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.45 api 4 htt 2.1 wmi 5 cal otp max_sta 128 I think it should work with CT too. I need to go back and validate that, and also make sure I can repro the AID crash on CT. A confounding factor is that every time I build new drivers for OpenWRT, it overwrites the firmware again... -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-04-28 12:57 ` Bob Copeland @ 2015-04-28 14:47 ` Ben Greear 0 siblings, 0 replies; 24+ messages in thread From: Ben Greear @ 2015-04-28 14:47 UTC (permalink / raw) To: Bob Copeland, Yeoh Chun-Yeow; +Cc: ath10k@lists.infradead.org On 04/28/2015 05:57 AM, Bob Copeland wrote: > On Tue, Apr 28, 2015 at 08:50:01PM +0800, Chun-Yeow Yeoh wrote: >> Great works, Bob. >> >> Which AP firmware that you have tested with? > > That is with: > > [ 16.670000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, > 0x043202ff) fw 10.2.4.45 api 4 htt 2.1 wmi 5 cal otp max_sta 128 > > I think it should work with CT too. I need to go back and validate > that, and also make sure I can repro the AID crash on CT. A confounding > factor is that every time I build new drivers for OpenWRT, it overwrites > the firmware again... If you feel adventurous, and want to apply some of my ath10k patches, I have a way to dump some of the interesting registers in CT firmware, including the rx-filter register. Maybe I can figure out what needs to be twiddled w/out having to add a monitor device. I could also potentially add a vdev type or flag for mesh interface, but that would definitely require driver hacks to enable the new flag and it would not be compatible with other upstream firmware. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k
@ 2015-07-06 21:25 Freddy Lee
2015-07-06 21:49 ` Bob Copeland
0 siblings, 1 reply; 24+ messages in thread
From: Freddy Lee @ 2015-07-06 21:25 UTC (permalink / raw)
To: me; +Cc: ath10k
Hi Bob,
I applied the mesh fix to OpenWRT (r45590 and r62020). It works great
(thanks, Bob!), but with a potentially unforeseen consequence: When an
Archer C7 with these changes is configured to be a 5GHz AP, clients
are unable to connect normally. Experiments show that the client is
registered as a station, but pings don't complete (in many cases, not
even DHCP completes). Tested clients include one commercial phone
(Samsung Galaxy S5 running Lollipop) and another Archer C7.
Without these changes, these same clients can connect to the AP all day long.
Below are sections of verbose output of an access point test script
both without and with the mesh fix.
======= Without ath10k mesh fix =======
+ iw dev wlan0 station dump
Station 30:b5:c2:b2:69:14 (on wlan0)
inactive time: 1390 ms
rx bytes: 1106
rx packets: 3
tx bytes: 1168
tx packets: 4
tx retries: 0
tx failed: 0
signal: -31 dBm
signal avg: -32 dBm
tx bitrate: 6.0 MBit/s
rx bitrate: 156.0 MBit/s VHT-MCS 5 VHT-NSS 3
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
+ cat /tmp/dhcp.leases
+ dhcp_lease=1434658717 30:b5:c2:b2:69:14 192.168.1.104 * *
+ cut -d -f 3
+ echo 1434658717 30:b5:c2:b2:69:14 192.168.1.104 bcopeland_test.sh
bcopeland_test.sh
+ ip=192.168.1.104
+ echo Client IP = 192.168.1.104
Client IP = 192.168.1.104
+ ping -c 10 192.168.1.104
PING 192.168.1.104 (192.168.1.104) 56(84) bytes of data.
64 bytes from 192.168.1.104: icmp_req=1 ttl=64 time=1.50 ms
64 bytes from 192.168.1.104: icmp_req=2 ttl=64 time=0.673 ms
64 bytes from 192.168.1.104: icmp_req=3 ttl=64 time=0.888 ms
64 bytes from 192.168.1.104: icmp_req=4 ttl=64 time=0.694 ms
64 bytes from 192.168.1.104: icmp_req=5 ttl=64 time=0.662 ms
64 bytes from 192.168.1.104: icmp_req=6 ttl=64 time=0.670 ms
64 bytes from 192.168.1.104: icmp_req=7 ttl=64 time=0.664 ms
64 bytes from 192.168.1.104: icmp_req=8 ttl=64 time=0.759 ms
64 bytes from 192.168.1.104: icmp_req=9 ttl=64 time=1.29 ms
64 bytes from 192.168.1.104: icmp_req=10 ttl=64 time=0.665 ms
--- 192.168.1.104 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9003ms
rtt min/avg/max/mdev = 0.662/0.847/1.508/0.290 ms
======= With ath10k mesh fix =======
+ iw dev wlan0 station dump
Station 30:b5:c2:b2:69:14 (on wlan0)
inactive time: 2560 ms
rx bytes: 382
rx packets: 1
tx bytes: 444
tx packets: 2
tx retries: 0
tx failed: 0
signal: -29 dBm
signal avg: -33 dBm
tx bitrate: 6.0 MBit/s
rx bitrate: 156.0 MBit/s VHT-MCS 5 VHT-NSS 3
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
+ cat /tmp/dhcp.leases
+ dhcp_lease=
+ cut -d -f 3
+ echo
+ ip=
+ echo Client IP =
Client IP =
+ ping -c 10
Usage: ping [-LRUbdfnqrvVaAD] [-c count] [-i interval] [-w deadline]
[-p pattern] [-s packetsize] [-t ttl] [-I interface]
[-M pmtudisc-hint] [-m mark] [-S sndbuf]
[-T tstamp-options] [-Q tos] [hop1 ...] destination
Does this work on your end? If not, is there a patch that will fix it?
Please advise.
Thanks in advance,
Freddy Lee
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: attempting mesh on ath10k 2015-07-06 21:25 Freddy Lee @ 2015-07-06 21:49 ` Bob Copeland 2015-07-06 21:54 ` Bob Copeland 2015-07-12 14:25 ` Bob Copeland 0 siblings, 2 replies; 24+ messages in thread From: Bob Copeland @ 2015-07-06 21:49 UTC (permalink / raw) To: Freddy Lee; +Cc: ath10k On Mon, Jul 06, 2015 at 02:25:36PM -0700, Freddy Lee wrote: > Hi Bob, > > I applied the mesh fix to OpenWRT (r45590 and r62020). It works great > (thanks, Bob!), but with a potentially unforeseen consequence: When an > Archer C7 with these changes is configured to be a 5GHz AP, clients > are unable to connect normally. Experiments show that the client is > registered as a station, but pings don't complete (in many cases, not > even DHCP completes). Tested clients include one commercial phone > (Samsung Galaxy S5 running Lollipop) and another Archer C7. > > Without these changes, these same clients can connect to the AP all day long. Hmm, well, there were definitely some hacks in that version, like setting the SSID to "A" for all vif types :) Here's the latest patch-in-progress but I haven't tested it; it also requires the AID series I sent to l-w last week (and still requires the filters be disabled). Once I get an hour to run it through the paces and also fix the filter issue then I plan to send upstream. From 2b7ad687190dce02bd3082b6e7145a4e01f9fb11 Mon Sep 17 00:00:00 2001 From: Bob Copeland <me@bobcopeland.com> Date: Sun, 5 Jul 2015 08:03:28 -0400 Subject: [PATCH] ath10k: implement mesh support Add support for mesh to ath10k. We simply use an AP virtual interface in the firmware in order to enable beaconing without TSF adoption, and use the raw (802.11) transmit mode. Some basic tests with TCP iperf using 2 ath10k devices and a couple of ath9k devices: 2-node VHT mesh: 4-node linear multihop HT20 (ath9k -> ath10k -> ath9k -> ath10k): Signed-off-by: Bob Copeland <me@bobcopeland.com> --- drivers/net/wireless/ath/ath10k/mac.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 609ca86..2501c47 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3136,7 +3136,8 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct ieee80211_vif *vif, const struct ieee80211_hdr *hdr = (void *)skb->data; __le16 fc = hdr->frame_control; - if (!vif || vif->type == NL80211_IFTYPE_MONITOR) + if (!vif || vif->type == NL80211_IFTYPE_MONITOR || + vif->type == NL80211_IFTYPE_MESH_POINT) return ATH10K_HW_TXRX_RAW; if (ieee80211_is_mgmt(fc)) @@ -4184,6 +4185,9 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, case NL80211_IFTYPE_ADHOC: arvif->vdev_type = WMI_VDEV_TYPE_IBSS; break; + case NL80211_IFTYPE_MESH_POINT: + arvif->vdev_type = WMI_VDEV_TYPE_AP; + break; case NL80211_IFTYPE_AP: arvif->vdev_type = WMI_VDEV_TYPE_AP; @@ -4550,6 +4554,13 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw, if (ret) ath10k_warn(ar, "failed to update beacon template: %d\n", ret); + + if (vif->type == NL80211_IFTYPE_MESH_POINT) { + /* mesh doesn't use SSID but firmware needs it */ + strlcpy(arvif->u.ap.ssid, "mesh", + sizeof(arvif->u.ap.ssid)); + arvif->u.ap.ssid_len = 4; + } } if (changed & BSS_CHANGED_AP_PROBE_RESP) { @@ -5285,6 +5296,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw, } else if (old_state == IEEE80211_STA_AUTH && new_state == IEEE80211_STA_ASSOC && (vif->type == NL80211_IFTYPE_AP || + vif->type == NL80211_IFTYPE_MESH_POINT || vif->type == NL80211_IFTYPE_ADHOC)) { /* * New association. @@ -5320,6 +5332,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw, } else if (old_state == IEEE80211_STA_ASSOC && new_state == IEEE80211_STA_AUTH && (vif->type == NL80211_IFTYPE_AP || + vif->type == NL80211_IFTYPE_MESH_POINT || vif->type == NL80211_IFTYPE_ADHOC)) { /* * Disassociation. @@ -6572,6 +6585,9 @@ static const struct ieee80211_iface_limit ath10k_if_limits[] = { { .max = 7, .types = BIT(NL80211_IFTYPE_AP) +#ifdef CONFIG_MAC80211_MESH + | BIT(NL80211_IFTYPE_MESH_POINT) +#endif }, }; @@ -6579,6 +6595,9 @@ static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = { { .max = 8, .types = BIT(NL80211_IFTYPE_AP) +#ifdef CONFIG_MAC80211_MESH + | BIT(NL80211_IFTYPE_MESH_POINT) +#endif }, }; @@ -6871,6 +6890,7 @@ int ath10k_mac_register(struct ath10k *ar) ar->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) | + BIT(NL80211_IFTYPE_MESH_POINT) | BIT(NL80211_IFTYPE_AP); ar->hw->wiphy->available_antennas_rx = ar->supp_rx_chainmask; -- 2.1.4 -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-07-06 21:49 ` Bob Copeland @ 2015-07-06 21:54 ` Bob Copeland 2015-07-12 14:25 ` Bob Copeland 1 sibling, 0 replies; 24+ messages in thread From: Bob Copeland @ 2015-07-06 21:54 UTC (permalink / raw) To: Freddy Lee; +Cc: ath10k On Mon, Jul 06, 2015 at 05:49:21PM -0400, Bob Copeland wrote: > Some basic tests with TCP iperf using 2 ath10k devices and a couple > of ath9k devices: > > 2-node VHT mesh: > 4-node linear multihop HT20 (ath9k -> ath10k -> ath9k -> ath10k): Obviously these tests are as yet incomplete :) -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-07-06 21:49 ` Bob Copeland 2015-07-06 21:54 ` Bob Copeland @ 2015-07-12 14:25 ` Bob Copeland 2015-07-13 1:43 ` Bob Copeland 1 sibling, 1 reply; 24+ messages in thread From: Bob Copeland @ 2015-07-12 14:25 UTC (permalink / raw) To: Freddy Lee; +Cc: ath10k On Mon, Jul 06, 2015 at 05:49:21PM -0400, Bob Copeland wrote: > Here's the latest patch-in-progress but I haven't tested it; it also > requires the AID series I sent to l-w last week (and still requires the > filters be disabled). Once I get an hour to run it through the paces > and also fix the filter issue then I plan to send upstream. Ok, so I've tested it now and I'm having some problems with raw mode on latest driver. On top of previously posted patch, I have the following (not sure if the various checksum changes are really needed, but tried to have it match last working patch). It looks like unicast self-protected action frames (peering) works fine, but broadcast multihop action frames (PREQs) never go over the air. Does this sound familiar to anyone? diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c index a60ef7d..6da3952 100644 --- a/drivers/net/wireless/ath/ath10k/htt_tx.c +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c @@ -513,7 +513,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu) flags1 |= SM((u16)vdev_id, HTT_DATA_TX_DESC_FLAGS1_VDEV_ID); flags1 |= SM((u16)tid, HTT_DATA_TX_DESC_FLAGS1_EXT_TID); - if (msdu->ip_summed == CHECKSUM_PARTIAL) { + if (msdu->ip_summed == CHECKSUM_PARTIAL && + skb_cb->txmode != ATH10K_HW_TXRX_RAW) { flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L3_OFFLOAD; flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L4_OFFLOAD; } diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index aa81880..e136e9c 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3636,12 +3636,9 @@ static void ath10k_tx(struct ieee80211_hw *hw, ath10k_tx_h_8023(skb); break; case ATH10K_HW_TXRX_RAW: - /* FIXME: Packet injection isn't implemented. It should be - * doable with firmware 10.2 on qca988x. - */ - WARN_ON_ONCE(1); - ieee80211_free_txskb(hw, skb); - return; + ath10k_tx_h_add_p2p_noa_ie(ar, vif, skb); + ath10k_tx_h_seq_no(vif, skb); + break; } if (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN) { @@ -4053,6 +4050,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, struct ath10k *ar = hw->priv; struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif); enum wmi_sta_powersave_param param; + enum ath10k_hw_txrx_mode tx_mode = ATH10K_HW_TXRX_NATIVE_WIFI; int ret = 0; u32 value; int bit; @@ -4109,6 +4107,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, arvif->vdev_type = WMI_VDEV_TYPE_IBSS; break; case NL80211_IFTYPE_MESH_POINT: + tx_mode = ATH10K_HW_TXRX_RAW; arvif->vdev_type = WMI_VDEV_TYPE_AP; break; case NL80211_IFTYPE_AP: @@ -4193,7 +4192,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, vdev_param = ar->wmi.vdev_param->tx_encap_type; ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, - ATH10K_HW_TXRX_NATIVE_WIFI); + tx_mode); /* 10.X firmware does not support this VDEV parameter. Do not warn */ if (ret && ret != -EOPNOTSUPP) { ath10k_warn(ar, "failed to set vdev %i TX encapsulation: %d\n", @@ -6969,7 +6968,7 @@ int ath10k_mac_register(struct ath10k *ar) goto err_free; } - ar->hw->netdev_features = NETIF_F_HW_CSUM; + /* ar->hw->netdev_features = NETIF_F_HW_CSUM; */ if (config_enabled(CPTCFG_ATH10K_DFS_CERTIFIED)) { /* Init ath dfs pattern detector */ -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-07-12 14:25 ` Bob Copeland @ 2015-07-13 1:43 ` Bob Copeland 2015-07-13 8:13 ` Michal Kazior 0 siblings, 1 reply; 24+ messages in thread From: Bob Copeland @ 2015-07-13 1:43 UTC (permalink / raw) To: ath10k [trimmed CC to list] On Sun, Jul 12, 2015 at 10:25:32AM -0400, Bob Copeland wrote: > It looks like unicast self-protected action frames (peering) works fine, but > broadcast multihop action frames (PREQs) never go over the air. Does > this sound familiar to anyone? Actually, it's any group addressed frame. I tried playing with various values for htt_data_tx_ext_tid as well as just using the tid on the frame (in mesh group addressed frames still have a qos header with tid=0). [ 662.170000] XXX htt tx completion msdu_id 0 discard 0 no_ack 0 success 1 [ 662.470000] XXX tx seq: 264 txmode 0 [ 662.470000] XXX htt tx flags0 5 flags1 3136 len 39 id 0 frags_paddr 07337028, msdu_paddr 06513e2e vdev 0 tid 17 freq 0 [ 662.480000] XXX htt tx completion msdu_id 0 discard 0 no_ack 0 success 1 [ 662.600000] XXX tx seq: 265 txmode 0 [ 662.600000] XXX htt tx flags0 5 flags1 2048 len 156 id 0 frags_paddr 07337028, msdu_paddr 06932028 vdev 0 tid 0 freq 0 [ 662.620000] XXX tx seq: 266 txmode 0 [ 662.620000] XXX htt tx flags0 5 flags1 2048 len 116 id 1 frags_paddr 07337000, msdu_paddr 06921028 vdev 0 tid 0 freq 0 [ 662.630000] XXX htt tx completion msdu_id 0 discard 0 no_ack 1 success 0 [ 662.640000] XXX htt tx completion msdu_id 1 discard 0 no_ack 1 success 0 [ 663.090000] XXX tx seq: 267 txmode 0 The 'success 1' ones are unicast, the success 0 are mcast (in this case using the frame's tid, otherwise it would be 16.) Kind of odd that it's not working, since my earlier snapshot worked... I guess at worst I can bisect compat-wireless versions but that will take some time. -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-07-13 1:43 ` Bob Copeland @ 2015-07-13 8:13 ` Michal Kazior 2015-07-13 10:57 ` Bob Copeland ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Michal Kazior @ 2015-07-13 8:13 UTC (permalink / raw) To: Bob Copeland; +Cc: ath10k@lists.infradead.org On 13 July 2015 at 03:43, Bob Copeland <me@bobcopeland.com> wrote: > [trimmed CC to list] > > On Sun, Jul 12, 2015 at 10:25:32AM -0400, Bob Copeland wrote: >> It looks like unicast self-protected action frames (peering) works fine, but >> broadcast multihop action frames (PREQs) never go over the air. Does >> this sound familiar to anyone? > > Actually, it's any group addressed frame. I tried playing with various > values for htt_data_tx_ext_tid as well as just using the tid on the frame > (in mesh group addressed frames still have a qos header with tid=0). Just a quick question: did you try applying the sw crypto/raw mode patch[1] and using it for mesh? [1]: https://patchwork.kernel.org/patch/6600721/ Michał _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-07-13 8:13 ` Michal Kazior @ 2015-07-13 10:57 ` Bob Copeland 2015-07-20 13:57 ` Bob Copeland 2015-08-13 3:14 ` Bob Copeland 2 siblings, 0 replies; 24+ messages in thread From: Bob Copeland @ 2015-07-13 10:57 UTC (permalink / raw) To: Michal Kazior; +Cc: ath10k@lists.infradead.org On Mon, Jul 13, 2015 at 10:13:59AM +0200, Michal Kazior wrote: > > Actually, it's any group addressed frame. I tried playing with various > > values for htt_data_tx_ext_tid as well as just using the tid on the frame > > (in mesh group addressed frames still have a qos header with tid=0). > > Just a quick question: did you try applying the sw crypto/raw mode > patch[1] and using it for mesh? > > [1]: https://patchwork.kernel.org/patch/6600721/ Thanks for the pointer, will give it a try. -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-07-13 8:13 ` Michal Kazior 2015-07-13 10:57 ` Bob Copeland @ 2015-07-20 13:57 ` Bob Copeland 2015-08-13 3:14 ` Bob Copeland 2 siblings, 0 replies; 24+ messages in thread From: Bob Copeland @ 2015-07-20 13:57 UTC (permalink / raw) To: Michal Kazior; +Cc: ath10k@lists.infradead.org On Mon, Jul 13, 2015 at 10:13:59AM +0200, Michal Kazior wrote: > On 13 July 2015 at 03:43, Bob Copeland <me@bobcopeland.com> wrote: > > Actually, it's any group addressed frame. I tried playing with various > > values for htt_data_tx_ext_tid as well as just using the tid on the frame > > (in mesh group addressed frames still have a qos header with tid=0). > > Just a quick question: did you try applying the sw crypto/raw mode > patch[1] and using it for mesh? > > [1]: https://patchwork.kernel.org/patch/6600721/ I gave this a try and still no luck. But I have working and non-working snapshots with only a few months of changes between them so I can bisect it. -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: attempting mesh on ath10k 2015-07-13 8:13 ` Michal Kazior 2015-07-13 10:57 ` Bob Copeland 2015-07-20 13:57 ` Bob Copeland @ 2015-08-13 3:14 ` Bob Copeland 2 siblings, 0 replies; 24+ messages in thread From: Bob Copeland @ 2015-08-13 3:14 UTC (permalink / raw) To: Michal Kazior; +Cc: ath10k@lists.infradead.org On Mon, Jul 13, 2015 at 10:13:59AM +0200, Michal Kazior wrote: > On 13 July 2015 at 03:43, Bob Copeland <me@bobcopeland.com> wrote: > > [trimmed CC to list] > > > > On Sun, Jul 12, 2015 at 10:25:32AM -0400, Bob Copeland wrote: > >> It looks like unicast self-protected action frames (peering) works fine, but > >> broadcast multihop action frames (PREQs) never go over the air. Does > >> this sound familiar to anyone? > > > > Actually, it's any group addressed frame. I tried playing with various > > values for htt_data_tx_ext_tid as well as just using the tid on the frame > > (in mesh group addressed frames still have a qos header with tid=0). > > Just a quick question: did you try applying the sw crypto/raw mode > patch[1] and using it for mesh? > > [1]: https://patchwork.kernel.org/patch/6600721/ Ok, I have this working again against the latest driver, including that patch -- I don't think anything was wrong with it, just didn't have both raw tx and decap set properly and had some baggage from the original patch to jettison. Still a bit WIP but this patchset against openwrt r46584 seems to work for me: http://bobcopeland.com/kernel/wl/20150812/ The mac80211 bits (except for VHT) are upstream but openwrt doesn't have them yet. (BTW thanks to Cococorp for sending me a few APs to make testing a lot easier!) -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2015-08-13 3:15 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-04-24 12:50 attempting mesh on ath10k Bob Copeland 2015-04-24 17:55 ` Yeoh Chun-Yeow 2015-04-25 1:38 ` Ben Greear 2015-04-26 14:15 ` Bob Copeland 2015-04-26 15:42 ` Ben Greear 2015-04-27 13:00 ` Bob Copeland 2015-04-28 5:47 ` Michal Kazior 2015-04-28 12:25 ` Bob Copeland 2015-05-27 6:51 ` Bartosz Markowski 2015-05-27 11:12 ` Bob Copeland 2015-05-27 11:15 ` Bartosz Markowski 2015-04-28 12:41 ` Bob Copeland 2015-04-28 12:50 ` Yeoh Chun-Yeow 2015-04-28 12:57 ` Bob Copeland 2015-04-28 14:47 ` Ben Greear -- strict thread matches above, loose matches on Subject: below -- 2015-07-06 21:25 Freddy Lee 2015-07-06 21:49 ` Bob Copeland 2015-07-06 21:54 ` Bob Copeland 2015-07-12 14:25 ` Bob Copeland 2015-07-13 1:43 ` Bob Copeland 2015-07-13 8:13 ` Michal Kazior 2015-07-13 10:57 ` Bob Copeland 2015-07-20 13:57 ` Bob Copeland 2015-08-13 3:14 ` Bob Copeland
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.