[OpenWrt-Devel] ath9k: fix dynack in IBSS mode

Wed Feb 27 02:13:16 EST 2019

> On Tue, Feb 26, 2019 at 1:57 PM Lorenzo Bianconi
> <lorenzo.bianconi at redhat.com> wrote:
> >
> > > On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi
> > > <lorenzo.bianconi at redhat.com> wrote:
> > > >
> > > > >
> > > > > On 26.02.19 06:28, Joe Ayers wrote:
> > > > > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte
> > > > > > <koen.vandeputte at ncentric.com> wrote:
> > > > > > >
> > > > > > > On 25.02.19 17:33, Joe Ayers wrote:
> > > > > > > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi
> > > > > > > > <lorenzo.bianconi at redhat.com> wrote:
> > > > > > > > > > On 24.02.19 21:32, Joe Ayers wrote:
> > > > > > > > > Hi Joe,
> > > > > > > Hi Joe,
> > > > > > > > > > > First of all, thanks for contributing this fix.   I've incorporated
> > > > > > > > > > > into the http://www.arednmesh.org project, just getting into our
> > > > > > > > > > > nightly builds now.   A comment and a couple questions...
> > > > > > > > > > >
> > > > > > > > > > > The MAX_DELAY was way too short for our community, had to increase
> > > > > > > > > > > that significantly.  We commonly have long distance links over 50km.
> > > > > > > > > according to ath9k max configurable value in AR_TIME_OUT for acktimeout
> > > > > > > > > is 0x3fff. The max ack_to we can configure (assuming clockrate set to
> > > > > > > > > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km).
> > > > > > > > > We can try to set MAX_DELAY to 360 (max distance ~54km). If you confirm it
> > > > > > > > > works properly I can post a patch (or you can take care of it, up to you)
> > > > > > > > >
> > > > > > > > I have a current link in Southern California with settings of:
> > > > > > > >
> > > > > > > > distance 60000m  ( "463 S" )
> > > > > > > > channel width = 10MHz
> > > > > > > > channel = 176 (5880) Amateur Radio licensing
> > > > > > > > Ubiquiti Rocket M w/ RocketDish
> > > > > > > > xmit power 27dBm
> > > > > > > >
> > > > > > > > It is rock solid and streams multiple HD videos and voip calls
> > > > > > > > (without drop outs in the call) achieving 30db SNR and MCS15 rates.
> > > > > > > > It's been live for a couple years in this mode.  I don't understand
> > > > > > > > how this link could operate with the performance we see if the  ack_to
> > > > > > > > max was 372 -- the voip quality would be terrible.
> > > > > > > >
> > > > > > > > I have tested (limited tests) dynack on a link showing upwards of
> > > > > > > > ~"400 A", but the real distance to farthest node was about ~20km.
> > > > > > > > Was wondering the discrepancy (fading, etc.?)?   I had changed the
> > > > > > > > starting point to 20km to work, otherwise it was stuck on the original
> > > > > > > > starting point, "96 A", and didn't move.
> > > > > > > >
> > > > > > > > I just loaded dynack on this 60km link and it doesn't move from my new
> > > > > > > > starting point of "196 A".   Something in the calculation somewhere
> > > > > > > > goes out of bound--to big a jump?   I'll do some testing to get the
> > > > > > > > dynack working on this 60km link, then lets see what it tunes to.
> > > > > > > > Based on my earlier results, I'm wondering if it will push past 500.
> > > > > > > >     Maybe the vendor specs are only to the limit of what was tested,
> > > > > > > > does not appear to be a true physical limit?
> > > > > > > Could you add some debug logs from Dynack?
> > > > > > >
> > > > > > Debug logs test case 1 --   Ubiquiti LHG5 <8km to Rocket M5:
> > > > > > https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing
> > > > > >
> > > > > > Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another Rocket M5:
> > > > > > https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing
> > > > > >
> > > > > > Test case 3 (no debug data) -- Ubiquiti NanoStation link to another
> > > > > > tower at 7.68km distance
> > > > > >
> > > > > > Note:  test case 1, the auto distance is much higher than actual
> > > > > > (static set about 8km).
> > > > > >             test case 2, the auto distance does not change from initial
> > > > > > value, although I raised MAX_DELAY sufficiently high enough. What
> > > > > > dynack.c initial variable conditions would you recommend?
> > > > > >             test case 3, normally set as "115 S".  dynack  floated from
> > > > > > 196 to 344, then back to 197 A when manually monitoring the ack_to
> > > > > > value in debugfs.  I've seen this behavior on 3 links now.
> > > > > >
> > > > > > Joe AE6XE
> > > > >
> > > > > Hi Joe,
> > > > >
> > > > > In the "long" log, I'm seeing that dynack is not synced.
> > > > > I'm also not seeing any late ack's coming in.
> > > > >
> > > > > The "Short" log looks OK and is what you should see on proper syncing.
> > > > >
> > > > >
> > > > > Could you try following on the long link? (if possible)
> > > > >
> > > > > - Ensure dynack gets enabled on boot
> > > > > - Reboot both locations so they finish booting and setup IBSS at exactly the
> > > > > same time.
> > > > > - Provide these logs from both ends.
> > > > >
> > > > > This allows to compare both ends on a side-by-side fashion.
> > > > >
> > > > > fyi, I've attached logs from my setup (24.1km link)
> > > > >
> > > > > You will notice some prints about late-ack's coming in, which is required.
> > > >
> > > > Hi Joe,
> > > >
> > > > are you running wpa_supplicant on ibss links? IIRC wpa_supplicant is mandatory
> > > > for dynack to work properly on ibss links.
> > > >
> > > > Regards,
> > > > Lorenzo
> > > >
> > >
> > > We do not run wpa_supplicant on ibss.    Let's just say, the ~1950's
> > > regulations for Amateur Radio Licensing needs to be modernized :) .
> >
> > Hi Joe,
> >
> > wpa_supplicant is mandatory to use dynack on ibss links so you need to
> > run it (otherwise dynack will not be able to trigger 'late' acks and
> > the processing will not converge for very long links).
> > The other possibility is to convert the ibss links in AP-STA mode.
> >
> > Regards,
> > Lorenzo
> >
> 
> Ok, let me look at this to see if I can get wpa_supplicant running.
> It's not an option to move from ibss to ap-sta mode.   The design is
> such that any node can come online and extend the network
> autonomously.   ap-sta would generally mean a pre-designed network.

What I mean is just a p2p link running in AP-STA mode, I guess there is no
difference for users. Am I missing something?

> 
>  Is dynack going to receive the late acks if I manage to run
> wpa_supplicant (wpad-mini?) in plaintext or key_mgmt=NONE mode?

What we really needs are authentication packets to trigger 'late acks'
in ibss mode. I think wpa_supplicant in plaintext is enough but I am not
100% sure.
@Koen: could you please confirm it?

Regards,
Lorenzo

> 
> I appreciate the help and dialog.   We have a lot of people in our
> community eager for this capability.  One example is this group:
> http://www.landops.com/
> 
> Joe AE6XE
> 
> > >
> > > dynack is working fine for links up to ~30km right now, and we are
> > > seeing max ack_to values above 400.   My original testing for the
> > > short link failed exactly the same way (with the original MAX_DELAY
> > > and starting ack_to) as the long link is failing now.     I changed
> > > MAX_DELAY and starting ack_to values to get working in the short link.
> > >   Now, we are seeing proper syncing in this debug data.   Can we not
> > > do similar changes for the long link?  Seems to be something in the
> > > logic conditions vs. wpa_supplicant.
> > >
> > > We have 500+ node network here in  Southern CA spanning end to end
> > > probably over 400km.  This long link is a back bone between counties,
> > > so I need to be a little sensitive with the up/down and testing I'm
> > > doing.
> > >
> > > Regards,
> > > Joe AE6XE

-- 
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190227/01db949d/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel