you negotiate it as an extension, and then it's used to switch STA keys without dropping frames.

oh, you have a jupiter card with eeprom, rather than just OTP? ooer. Good catch! I likely only have OTP AR9462s :(

looks like it was kip's TOE work from way back when? Maybe there was an out of tree driver / multi-platform driver that used it at some point.

ooo!

Aha i remember now. Ok, so.

In D43634#1007535, @bz wrote:

In D43634#1007529, @adrian wrote:

err, lemme double check this first. SWDECRYPT is not related to hardware encryption offload; it's an earlier thing where you could have RX STA keys in the hardware (to accelerate knowing which STA it belongs to) but it still passes it through untouched requiring one to do encrypt/decrypt in software.

For the ath NICs, the keycache served both as a encryption/decryption key cache and also as a way of marking known STAs in hardware for doing things like auto-ACK, block-ACK tracking, hardware antenna diversity in the older NICs, etc. It doesn't /have/ to contain encryption keys - that's why SWDECRYPT is a thing.

Is IEEE80211_KEY_SWDECRYPT being set somewhere in the linux kpi layer?

I don't think so but that means we need an extra bit of logic. The HW decrypted packets come in and hit ccmp_decrypt() which they definitively shouldn't anymore. So pseudo-code:

if (!IEEE80211_RX_F_DECRYPTED && IEEE80211_KEY_SWDECRYPT) error = xxx_decrypt();  Handle error accrodingly.

Something like this?

err, lemme double check this first. SWDECRYPT is not related to hardware encryption offload; it's an earlier thing where you could have RX STA keys in the hardware (to accelerate knowing which STA it belongs to) but it still passes it through untouched requiring one to do encrypt/decrypt in software.

honestly we should defer rx in net80211, it'd make a whole lot of packet handling w/ state transitions easier

lol well yeah, i think after 10+ years of the software transmit queue handling in ath(4) I can say "ok this shit just works now"

Yeah, thee's no reason not to enable it by default nowdays. :-)

oh wow, howd this get missed :( lemme see if it's still relevant?

nice catch! The iv_bss reference issues strike again! :P

sorry! looks good, I was sick the last couple weeks and missed that. :(

I think it's fine, it just means we can't batch a single epoch call inside the driver when it does encap/decap for us!

Oh I remember some stupid corner cases waaaay back that needed this for stupid reasons? because some (temp) nodes only had one reference at that point that shouldn't? or something with the bssnode handling continuing to be stupid?

lets hold off on removing the /HAL/ support just right now. If we start stripping this stuff out then i'll make it harder to sync this code up with what I'm slowly hacking up in netbsd...

fiiine :-P

Hi! I know this is a long shot, but if someone wants to do AR9271/AR7010 support (which is USB) it'll need this bus abstraction still.

i know this keeps happening for unaligned-unhappy platforms, but can we please at least try to "fix" this in the L3 path too? Do an explicit pull-up and counter on the input path just in case something sneaks through?

nice!

I think having a separate dedicated allocator for netlink messages is the better call. Don't make your control plane reliant on your data plane's memory management.

ping! what's left before we can have a lwjgl3 port landed?

In D39476#899586, @misha wrote:

In D39476#899553, @adrian wrote:

oh wait err, i recall when bernard and i were debugging this in 2010/2011 time we found that "what the spec said" and "what devices actually needed because of bugs" were very different. so let's be careful with these.

(gosh I wish we had all of that in the commit logs or bug report logs somewhere..)

I think that adjusting to bugs of some devices in cost of contradicting to the standard for every device around is counter-productive, especially considering time which has passed since 2010.

What were consequences of these bugs and what were the vendors?

oh wait err, i recall when bernard and i were debugging this in 2010/2011 time we found that "what the spec said" and "what devices actually needed because of bugs" were very different. so let's be careful with these.

oh hm! good catch, let's see!

i understand the fix, but the whole code layout for rtwn is to avoid the HW code knowing too much about the bus/transport.

(also I thought we had a program somewhere in tools/tools/net80211 that would listen to the routing socket for all net80211 messages, to make debugging this easier? if not, we should write one :-)

iirc, and don't quote me on this, the "scan done + restart" stuff can happen when the software scanner is doing things like background scans (which break softmac 11n/11ac/etc devices, sigh, someone needs to employ me for 6 months to properly fix that for softmac devices already) it can start and stop a scan, push up scan results, but not complete it. background scans can be interrupted by active traffic, which means it'll try to do a piecemeal scan before pushing things up.

ok, try this one!

oops

corrections!

addressed nits

amusingly I'm actually neck deep in figuring it out for my macbook air, so sure. Why not. ;)

Thanks for the cleanup!

They're all used in the ath10k driver port I'm working on. They're available in the linuxkpi for liinux drivers too :-)

i think it's fine to nuke it?

update

update

update

update

update

address comments from imp

update