Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Dave Täht]

On 2/3/17 3:42 AM, Baptiste Jonglez wrote:
> On Tue, Jan 31, 2017 at 10:14:04AM +, David Woodhouse wrote:
>> On Tue, 2017-01-31 at 10:54 +0100, Baptiste Jonglez wrote:
>>>
>>> - IPv6 support: since that was the focus of CC, at least mention that
>>>   nothing was intentionally broken (and maybe there were some
>>>   improvement?)]
>>
>> What was the IPv6 problem?
> 
> Nothing, hopefully :) What I meant is that LEDE should work as well as
> OpenWRT CC with respect to IPv6 support.  This is currently implicit,
> because the release notes do not mention IPv6 at all.  I was wondering if
> it would make sense to mention that IPv6 support remains very good.

If it were only true. Earlier this month I experienced a raft of ipv6
inter-related bugs in an odhcp6c+dhcpv6-pd or 6rd environment, mostly
around timers - both in expiry of and refresh of routes of addresses.

Various bits of improved code has been landing since, and I have not got
back on it (busy on wifi and atf). I think much of the evidence points
at a bug in netifd in pushing out or refeshing routes that expire,
compounded by noprefixroute being added to the kernel in the last 2
years, compounded by a bit of bit-rot on some of the scripting interfaces...

It would be good to have more people get on this, but I would, given the
release schedule, deprioritize mention of ipv6 support, and try to
aggressively attack all the issues in a subsequent round.





___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Baptiste Jonglez]

On Tue, Jan 31, 2017 at 10:14:04AM +, David Woodhouse wrote:
> On Tue, 2017-01-31 at 10:54 +0100, Baptiste Jonglez wrote:
> > 
> > - IPv6 support: since that was the focus of CC, at least mention that
> >   nothing was intentionally broken (and maybe there were some
> >   improvement?)]
> 
> What was the IPv6 problem?

Nothing, hopefully :) What I meant is that LEDE should work as well as
OpenWRT CC with respect to IPv6 support.  This is currently implicit,
because the release notes do not mention IPv6 at all.  I was wondering if
it would make sense to mention that IPv6 support remains very good.

Baptiste


signature.asc
Description: PGP signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Leonidas Spyropoulos]

On 01/02/17, Rich Brown wrote:
> Update on the release documentation. There's a new top-level page to describe 
> Release Builds at: https://lede-project.org/releases/start
> 
> jow has updated and coalesced the release documentation into a single 
> directory at /releases/17.01 You can read the improved documents at:
> 
> Overview: https://lede-project.org/releases/17.01/start
> 
> Download link: 
> https://downloads.lede-project.org/releases/17.01.0-rc1/targets/
> 
> Browse Source: 
> https://git.lede-project.org/?p=source.git;a=commit;h=68a04dbb4271e98c4622e6471c0d600cb57fe75f
> 
> Release Notes: https://lede-project.org/releases/17.01/notes-17.01.0-rc1
> 
> Detailed Changelog: 
> https://lede-project.org/releases/17.01/changelog-17.01.0-rc1
> 
> There's still plenty of time to make corrections and additions!
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Hello

I'm not sure if this is the place to report issues but the package
indexes in http://downloads.lede-project.org/releases/17.01.0-rc1 seems
wrong. An example is:
http://downloads.lede-project.org/releases/17.01.0-rc1/packages/mips_24kc/luci/luci-app-samba_git-17.033.24085-e306ee6-1_all.ipk
amd the version mentioned in index is:
git-17.030.65694-46fd88e-1

Are these expected to be stable for RC1 ?

Thanks

-- 
Leonidas Spyropoulos

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Rich Brown]

Update on the release documentation. There's a new top-level page to describe 
Release Builds at: https://lede-project.org/releases/start

jow has updated and coalesced the release documentation into a single directory 
at /releases/17.01 You can read the improved documents at:

Overview: https://lede-project.org/releases/17.01/start

Download link: https://downloads.lede-project.org/releases/17.01.0-rc1/targets/

Browse Source: 
https://git.lede-project.org/?p=source.git;a=commit;h=68a04dbb4271e98c4622e6471c0d600cb57fe75f

Release Notes: https://lede-project.org/releases/17.01/notes-17.01.0-rc1

Detailed Changelog: 
https://lede-project.org/releases/17.01/changelog-17.01.0-rc1

There's still plenty of time to make corrections and additions!
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[David Woodhouse]

On Tue, 2017-01-31 at 10:54 +0100, Baptiste Jonglez wrote:
> 
> - IPv6 support: since that was the focus of CC, at least mention that
>   nothing was intentionally broken (and maybe there were some
>   improvement?)]

What was the IPv6 problem? I updated my VDSL router and separate AP to
17.01 over the weekend, and haven't seen any problems. My ISP does do
prefix delegation and I suppose I *ought* to check that works out of
the box, but haven't looked hard at it yet.

I did have missing *Legacy* IP routing for a while until I finally
noticed, but that was just a configuration issue :)

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Dave Täht]

On 1/29/17 7:36 AM, Jaap Buurman wrote:
> One more question if you don't mind :) With the "mac80211 debloated
> intermediate queues" do you also mean fq_codel (phase 2), or just
> phase 1?
> Also, has cake ever been tried instead of fq_codel to try and debloat wifi?

We used various simluations of wifi in cake, as one way to verify the
performance of the codel algorithm. Simple example would be, firing up a
test, and have a script...

sleep 10;
tc qdisc change dev whatever cake bandwidth 10mbit
sleep 1;
tc qdisc change dev whatever cake bandwidth 20mbit
sleep 1;
tc qdisc change dev whatever cake bandwidth 40mbit
sleep 1;
tc qdisc change dev whatever cake bandwidth 6mbit

I fear, after getting some major testing done in the past week now that
things are stabler, that this sort of emulation was insufficient to
emulate the real behaviors of wifi in a noisy environment. (yes, we did
do tons of live testing, too)

I am, admittedly, now testing with 51 APs within listening distance, at
the moment, which is far, far, far worse than the lab ever was. Some of
the things we deferred for further research were ratcheting down on
retries, and rate limiting multicast. It still seems, overall, better,
(I haven't had a single crash or error in the log in 3 days of testing a
build done friday on the archer)

It's my hope we can get more people pounding things with flent's
rtt_fair* tests to see how "right" the ATF is, and taking packet
captures (aircaps) so we can see what else can be improved. I'm about to
go try upping the multicast rate and/or re-enabling the igmp and
multicast-unicast code



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Jaap Buurman]

One more question if you don't mind :) With the "mac80211 debloated
intermediate queues" do you also mean fq_codel (phase 2), or just
phase 1?
Also, has cake ever been tried instead of fq_codel to try and debloat wifi?

On Sun, Jan 29, 2017 at 2:46 PM, Toke Høiland-Jørgensen  wrote:
> Jaap Buurman  writes:
>
>> Thank you very much for the clarification. That makes a lot of sense.
>> Do you happen to know where the mt76 driver stands with respect to
>> these different phases? I am in the market for a new router, and due
>> to the openness of the driver I'm currently looking at a mediatek
>> based platform, namely the dir-860l rev b1.
>
> The mt76 driver also uses the mac80211 debloated intermediate queues. So
> yeah, maybe that should be mentioned in the announcement as well.
>
> As far as ath10k is concerned, the driver will use the intermediate
> queues, but only if the hardware has certain capabilities. Hence the
> wording in that bullet.
>
> The only thing that is ath9k-only is the airtime fairness patches. Which
> are not in 17.01 anyway...
>
> -Toke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Toke Høiland-Jørgensen]

Rich Brown  writes:

> Hi Jaap,
>
>> On Jan 28, 2017, at 6:36 AM, Jaap Buurman  wrote:
>> 
>> Great job on the release notes! One minor thing that I think looks
>> nicer would be the removal of "nothing specific" after "improved
>> performance", since it adds no additional information. But that's just
>> me.
>
> Thanks for the kind words. I left "nothing specific" there as an attempt to 
> lure
> people into writing something. :-) I would expect to remove that text for the
> final version.

Arguably, the heading "improved networking support" should really be
"improved (networking) performance". So maybe collapsing those two
bullets into one (with the subpoints from the networking part)?

-Toke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Toke Høiland-Jørgensen]

Jaap Buurman  writes:

> Thank you very much for the information! Actually, airtime fairness
> was added 3 days ago, both to the master branch and to the 17.01
> branch as can be seen in this commit:
> https://git.lede-project.org/?p=source.git;a=commit;h=a6f3ea5e848fd6c23cf0af9fe7b6c9753a1bf2fe

Ah, awesome! I'll go update the changelog accordingly :)

-Toke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Jaap Buurman]

Thank you very much for the information! Actually, airtime fairness
was added 3 days ago, both to the master branch and to the 17.01
branch as can be seen in this commit:
https://git.lede-project.org/?p=source.git;a=commit;h=a6f3ea5e848fd6c23cf0af9fe7b6c9753a1bf2fe

:)

On Sun, Jan 29, 2017 at 2:46 PM, Toke Høiland-Jørgensen  wrote:
> Jaap Buurman  writes:
>
>> Thank you very much for the clarification. That makes a lot of sense.
>> Do you happen to know where the mt76 driver stands with respect to
>> these different phases? I am in the market for a new router, and due
>> to the openness of the driver I'm currently looking at a mediatek
>> based platform, namely the dir-860l rev b1.
>
> The mt76 driver also uses the mac80211 debloated intermediate queues. So
> yeah, maybe that should be mentioned in the announcement as well.
>
> As far as ath10k is concerned, the driver will use the intermediate
> queues, but only if the hardware has certain capabilities. Hence the
> wording in that bullet.
>
> The only thing that is ath9k-only is the airtime fairness patches. Which
> are not in 17.01 anyway...
>
> -Toke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Toke Høiland-Jørgensen]

Jaap Buurman  writes:

> Thank you very much for the clarification. That makes a lot of sense.
> Do you happen to know where the mt76 driver stands with respect to
> these different phases? I am in the market for a new router, and due
> to the openness of the driver I'm currently looking at a mediatek
> based platform, namely the dir-860l rev b1.

The mt76 driver also uses the mac80211 debloated intermediate queues. So
yeah, maybe that should be mentioned in the announcement as well.

As far as ath10k is concerned, the driver will use the intermediate
queues, but only if the hardware has certain capabilities. Hence the
wording in that bullet.

The only thing that is ath9k-only is the airtime fairness patches. Which
are not in 17.01 anyway...

-Toke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Jaap Buurman]

Thank you very much for the clarification. That makes a lot of sense.
Do you happen to know where the mt76 driver stands with respect to
these different phases? I am in the market for a new router, and due
to the openness of the driver I'm currently looking at a mediatek
based platform, namely the dir-860l rev b1.

On Sun, Jan 29, 2017 at 6:33 AM, Weedy  wrote:
> On 28 January 2017 at 15:56, Rich Brown  wrote:
>> Hi Jaap,
>>
>>> On Jan 28, 2017, at 6:36 AM, Jaap Buurman  wrote:
>>> Also about the following: "Improvements to the WiFi stack eliminating
>>> bufferbloat on ath9k (and some ath10k) chipsets"
>>>
>>> Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k
>>> and not for ath10k? Or am I mixing things up here?
>>
>> I am not sure. I was hoping someone who has been following this more closely 
>> would weigh in.
>
> As far as I know the make-wifi-fast work was done in stages. Something like:
> Phase 1: Reducing buffering all over the stack/drivers. Pretty sure
> atk10k got some of this
> Phase 2: Replace most/all txqueue stuff with fq_codel inside the
> driver. I know Toke made patches for ath10k, I don't know if upstream
> accepted them
> Phase 3: Air time fairness stuff. Only for ath9k, and I don't know if
> ath10k can ever get this since the chip firmware is basically a full
> operating system and it does whatever it wants too.
>
> NB: I'm just a user, not a dev. But I like WiFi things and try to keep 
> informed.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Weedy]

On 28 January 2017 at 15:56, Rich Brown  wrote:
> Hi Jaap,
>
>> On Jan 28, 2017, at 6:36 AM, Jaap Buurman  wrote:
>> Also about the following: "Improvements to the WiFi stack eliminating
>> bufferbloat on ath9k (and some ath10k) chipsets"
>>
>> Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k
>> and not for ath10k? Or am I mixing things up here?
>
> I am not sure. I was hoping someone who has been following this more closely 
> would weigh in.

As far as I know the make-wifi-fast work was done in stages. Something like:
Phase 1: Reducing buffering all over the stack/drivers. Pretty sure
atk10k got some of this
Phase 2: Replace most/all txqueue stuff with fq_codel inside the
driver. I know Toke made patches for ath10k, I don't know if upstream
accepted them
Phase 3: Air time fairness stuff. Only for ath9k, and I don't know if
ath10k can ever get this since the chip firmware is basically a full
operating system and it does whatever it wants too.

NB: I'm just a user, not a dev. But I like WiFi things and try to keep informed.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Rich Brown]

Hi Jaap,

> On Jan 28, 2017, at 6:36 AM, Jaap Buurman  wrote:
> 
> Great job on the release notes! One minor thing that I think looks
> nicer would be the removal of "nothing specific" after "improved
> performance", since it adds no additional information. But that's just
> me.

Thanks for the kind words. I left "nothing specific" there as an attempt to 
lure people into writing something. :-) I would expect to remove that text for 
the final version.

Note to other readers: I have not been following all the LEDE enhancements 
carefully. Please do check the Release Notes to make sure that your hard work 
has been represented fairly. Check out: 
https://lede-project.org/playground/draft-release-notes

> Also about the following: "Improvements to the WiFi stack eliminating
> bufferbloat on ath9k (and some ath10k) chipsets"
> 
> Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k
> and not for ath10k? Or am I mixing things up here?

I am not sure. I was hoping someone who has been following this more closely 
would weigh in.

> While're talking about 17.01 anyway when are the first RCs coming out btw? :)

jow just clarified the situation for the naming of directories and image files. 
In that note, he also said that just switched the buildbot to produce tagged 
rc1 builds, so I imagine they will come out soon.

> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Jaap Buurman]

Great job on the release notes! One minor thing that I think looks
nicer would be the removal of "nothing specific" after "improved
performance", since it adds no additional information. But that's just
me.

Also about the following: "Improvements to the WiFi stack eliminating
bufferbloat on ath9k (and some ath10k) chipsets"

Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k
and not for ath10k? Or am I mixing things up here?

While're talking about 17.01 anyway when are the first RCs coming out btw? :)

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] LEDE-17.01 Final Release Notes available

[Rich Brown]

Since no changes have occurred to the release notes in the last 5 days, I 
assume they are complete and final. 

If you wish to prove me wrong, please send me a note, or update them directly 
at: https://lede-project.org/playground/draft-release-notes

I have pasted the current text below for your reading pleasure. Thanks, and 
congratulations on the great work!

Rich

---

LEDE 17.xx First Stable Release - MMM 2017

 _
//\  ____ ___  ___
   /  LE/  \| |  | __|   \| __|
  /DE  /\   | |__| _|| |) | _|
 //  LE  \  ||___|___/|___|  lede-project.org
 \\   DE /
  \LE  \/  ---
   \  DE\  /Reboot (17.01-SNAPSHOT, r-1234567)
\\/---

THIS IS THE FINAL DRAFT. LAST CHANCE TO MAKE IT BETTER.
[Final changes include updating “17.xx” everywhere, “MMM 2017” everywhere, 
final “Reboot” name/version/commit, actual URL for downloads.]

The LEDE Project (“Linux Embedded Development Environment”) is a Linux 
operating system based on OpenWrt. It is a complete replacement for the 
vendor-supplied firmware of a wide range of wireless routers and non-network 
devices. See the Table of Hardware for supported devices. For more information 
about LEDE Project organization, see the About LEDE pages.

Get LEDE Firmware at: http://downloads.lede-project.org/releases/

Highlights In LEDE 17.xx

The LEDE Community is proud to announce the first stable release of LEDE 17.xx. 
It incorporates thousands of commits over the last nine months of effort. With 
this release, the LEDE development team closes out an intense effort to 
modernize many parts of OpenWrt and incorporate many new modules, packages, and 
technologies. These are some of the highlights compared to OpenWrt Chaos Calmer:

• Linux kernel updated to version 4.4.42
• Improved Security Features
• Memory Corruption Mitigation Methods
• gcc -Wformat -Wformat-security
• User space Stack-Smashing Protection (Regular)
• Kernel space Stack-Smashing Protection (Regular)
• buffer-overflows detection (FORTIFY_SOURCE) 
(Conservative)
• RELRO protection (Full)
• Improved Networking Support
• Smart Queue Management (SQM) minimizes bufferbloat by using 
the cake and fq_codel qdisc's. More...
• Improvements to the WiFi stack eliminating bufferbloat on 
ath9k (and some ath10k) chipsets
• Improved Performance
• Nothing specific.
• Updated toolchain
• musl 1.1.15
• gcc 5.4.0
• binutils 2.25.1
• Platform and Driver Support
• Lantiq
• Added redistributable DSL firmware
• Updated DSL phy drivers
• Added new targets:
• apm821xx (AppliedMicro APM821xx)
• arc770 (Synopsys DesignWare ARC 770D)
• archs38 (Synopsys DesignWare ARC HS38)
• armvirt (QEMU ARM Virtual Machine)
• ipq806x (Qualcomm Atheros IPQ806X)
• layerscape (NXP Layerscape)
• zynq (Xilinx Zynq 7000 SoCs)
• New build system supports easier branching
• Building different root file systems for different devices at 
once
• Added support for a many new routers and boards
• And lots and lots of other advancements…
As always, a big thank you goes to all our active package maintainers, testers, 
documenters, and supporters.

Have fun!

The LEDE Community
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev