Re: [LEDE-DEV] Lack of DNS robustness for openwrt.org

2018-05-06 Thread John Crispin 



On 06/05/18 22:44, Joerg Jaspert wrote:

On 15029 March 1977, Bjørn Mork wrote:


1) update the .org delegation to include *all* NS records for the
openwrt.org zone

I added the soapstone one to the registrar for now, as thats an easy
step to do.


3) possibly consider adding/replacing DNS servers with more robust
   (anycasted?) solutions.  Adding or replacing secondaries should at
   least be a no-brainer

If *wanted*, SPI nameservers can be used as secondaries.



Hi Joerg,

I am liasion to the SPI if I am not mistaken so i can just ask you to do 
that right ? If so, please add spi as secondary.


We should also consider moving primary to the DO servers, but that would 
require a vote and a thread on the adm channels.


    John

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

Re: [LEDE-DEV] [PATCH 2/2] kernel: bump 4.14 to 4.14.38

2018-05-06 Thread Koen Vandeputte 



On 06-05-18 19:25, Tomasz Maciej Nowak wrote:

Hi Koen.

W dniu 03.05.2018 o 11:57, Koen Vandeputte pisze:

All,

Please skip these.
It does not apply anymore due to:   "kernel: add missing in6_dev_put_clear call to 
an ipv6 network patch"

Also .. yet another kernel bump was released yesterday ..

If You'll be doing kernel bump for 4.14.39 or later, You cane safely drop these 
patches:

target/linux/mvebu/patches-4.14/522-PCI-aardvark-fix-logic-in-PCI-configuration-read-write-functions.patch
target/linux/mvebu/patches-4.14/523-PCI-aardvark-set-PIO_ADDR_LS-correctly-in-advk_pcie_rd_conf.patch
target/linux/mvebu/patches-4.14/524-PCI-aardvark-set-host-and-device-to-the-same-MAX-payload-size.patch
target/linux/mvebu/patches-4.14/525-PCI-aardvark-use-isr1-instead-of-isr0-interrupt-in-legacy-irq-mode.patch
target/linux/mvebu/patches-4.14/526-PCI-aardvark-disable-LOS-state-by-default.patch
target/linux/mvebu/patches-4.14/527-PCI-aardvark-fix-PCIe-max-read-request-size-setting.patch

Thanks for all Your work.

Hi,
I started working on the V2 last week, and it seems not all of these 
were upstreamed.
If I have some time, I'll check it further in detail tomorrow how it 
should be handled.



V2 later on ..

Koen


Cheers, Tomasz.




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

Re: [LEDE-DEV] 18.06 Status?

2018-05-06 Thread Fernando Frediani 
Well, schedule means a bit of organization and commitment around 
something, I personally don't fear it.


I am only putting this point here because something happen the recent 
past (including during the merge agreements) that justifies. And again 
nothing happens if a feature is skipped.But the main point is the lack 
of someone to gather things together.


This isn't some exotic, works pretty well for several very well known 
community projects and don't seem to cause any harm.


Best regards,
Fernando

On 05/05/2018 17:33, Alberto Bursi wrote:
They already had jow or someone else sent messages to call for kernel 
updates and sending patches before the release, and got stuff done by 
now.


As per the last answer of John Crispin to this mail thread, they will 
release at the beginning of next week.


Developers choose freely what they prefer to work on, and when and 
everything, as it is not a job.


I really don't see how this could have been improved without forcing 
people to do things for the "best interests of the project", and if 
you can't force people then the only thing left for this Release 
Coordinator is declaring releases at fixed dates for the sake of 
schedule.


-Alberto

On 05/05/2018 21:12, Fernando Frediani wrote:
I didn't mention forcing people at any point. Just having someone to 
be in charge in order to organize certain things, get people's 
availability and make more thing happen.


With regards schedule the lack of one seems not doing much good, so 
having one has the potential to improve things. And again, having a 
schedule doesn't necessarily mean every single point will get done, 
but certainly will get more attention and commitment from most of 
people around something in common. It will not be a big thing if a 
feature was skipped.


As mentioned in the other reply perhaps Release Coordinator could do 
this job fine without changing much of the whole thing.


Regards
Fernando

On 05/05/2018 15:55, Alberto Bursi wrote:

This isn't a job where you can force people to do anything.

Also, I'm not a fan of half-assing or leaving out things for the 
sake of a schedule.



-Alberto

On 05/05/2018 20:41, Fernando Frediani wrote:
One characteristic from OpenWrt, different from other projects is 
the lack of a leader or a person who can gather others together, 
make some decisions or push for them to happen. If one doesn't like 
this title it can also be "Project Manager" or "Project 
Coordinator". This, in my view, makes a big difference for things 
to flow in time.


Has anyone heard that saying: "A dog with many owners starves"

Perhaps it is the time to adjust the Rules 
(https://openwrt.org/rules) and add something to make it exist in 
benefit of the project.


Fernando

On 05/05/2018 07:27, Jaap Buurman wrote:

Hi all,

I feel like everybody is just waiting for everybody to agree what
features we want in before coming up with the next step of picking a
date. Obviously this isn't working out very well. Why not turn things
around? Pick a date in a few weeks time on which the Master branch
will be split to a 18.0X branch. If nobody complains before that date
the branch goes on as planned. People can obviously get in the
features they want before said date. If somebody deems a particular
feature very important to be included in this branch, but feels like
it will not be finished before said date, he/she can request a delay
stating:

-What he/she would like to include
-Why this is so important to be included before the branch.
-How much extra time this will need by proposing a new date
-Perhaps a request for help implementing said change

Should this proposal be accepted, we will reschedule the date from
there. If the other people don't think it is important enough to
postpone the release, the old date will stand. This way, we can 
simply

move forward if nobody complains about a particular date instead of
the waiting around for others that is going on right now. What does
everybody else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?

Yours sincerely,

Jaap Buurman

On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen 
 wrote:

On 05/01/2018 10:47 AM, Hannu Nyman wrote:
I think that the main source tree is in pretty good shape, so 
branching

off the 18.0X rather soon might make sense


I would also think its time to branch 18.[something-soon], and 
rather than
focus on work that needs yet to be completed, look to cut 
hardware and
packages that are not ready for a release. There is always some 
heart ache
when such decisions are made, but at a point those decisions do 
need to be
made. Without an official release to punctuate both the core team 
and other

packagers hard work, OpenWrt/LEDE could risk losing support from the
community and its limited sponsorship. I imagine this project means

Re: [LEDE-DEV] Lack of DNS robustness for openwrt.org

2018-05-06 Thread Joerg Jaspert 
On 15029 March 1977, Bjørn Mork wrote:

> 1) update the .org delegation to include *all* NS records for the
>openwrt.org zone

I added the soapstone one to the registrar for now, as thats an easy
step to do.

> 3) possibly consider adding/replacing DNS servers with more robust
>   (anycasted?) solutions.  Adding or replacing secondaries should at
>   least be a no-brainer

If *wanted*, SPI nameservers can be used as secondaries.

-- 
bye, Joerg

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

[LEDE-DEV] [PATCH 2/2] cake: bump to 20180504 bake

2018-05-06 Thread Kevin Darbyshire-Bryant via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Cake is bearing fruits of kernel upstreaming efforts.

diffserv-llt dropped. DSCP mapping paper died and no one using it.

ack-filter re-written & simplified

tc userspace & cake kmod netlink interface usage changed in non
backwards compatible way, thus this once requires tc & cake to be
in-step.  Change due to upstream requirements.

Signed-off-by: Kevin Darbyshire-Bryant 
---
 package/kernel/kmod-sched-cake/Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/package/kernel/kmod-sched-cake/Makefile 
b/package/kernel/kmod-sched-cake/Makefile
index 2156eee0e4..fe5e2acd50 100644
--- a/package/kernel/kmod-sched-cake/Makefile
+++ b/package/kernel/kmod-sched-cake/Makefile
@@ -13,9 +13,10 @@ PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL:=https://github.com/dtaht/sch_cake.git
-PKG_SOURCE_DATE:=2018-03-19
-PKG_SOURCE_VERSION:=0afc1bee4e9fc5d75668cb10254ab5d2d02f0098
-PKG_MIRROR_HASH:=b8ac95753d05ff602282ed5a799f9c953f60decebc5720ee8f0101344a5acfc4
+PKG_SOURCE_DATE:=2018-05-04
+PKG_SOURCE_VERSION:=e848241cda393fe1fa643156bcdbe81764bfe060
+PKG_MIRROR_HASH:=70fd1f79dcdf39e47957fa6684a1a41c1b50f51896781bea0d27bc9e8ff057ab
+PKG_MAINTAINER:=Kevin Darbyshire-Bryant 
 
 include $(INCLUDE_DIR)/package.mk
 
-- 
2.15.1 (Apple Git-101)


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

[LEDE-DEV] [PATCH 1/2] iproute2: import latest cake

2018-05-06 Thread Kevin Darbyshire-Bryant via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Bearing fruits of the latest upstreaming efforts on cake.

Changes: diffserv-llt dropped.  The paper describing this DSCP
allocation has gone stale and doesn't appear used.

The userspace to kernel netlink messages for cake have been reworked in
a backwards incompatible way, so tc & cake must be bumped together this
once.

Signed-off-by: Kevin Darbyshire-Bryant 
---
 package/network/utils/iproute2/Makefile|   2 +-
 .../iproute2/patches/950-add-cake-to-tc.patch  | 869 ++---
 2 files changed, 425 insertions(+), 446 deletions(-)

diff --git a/package/network/utils/iproute2/Makefile 
b/package/network/utils/iproute2/Makefile
index f5a9db321d..88a4851748 100644
--- a/package/network/utils/iproute2/Makefile
+++ b/package/network/utils/iproute2/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=iproute2
 PKG_VERSION:=4.16.0
-PKG_RELEASE:=2
+PKG_RELEASE:=3
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@KERNEL/linux/utils/net/iproute2
diff --git a/package/network/utils/iproute2/patches/950-add-cake-to-tc.patch 
b/package/network/utils/iproute2/patches/950-add-cake-to-tc.patch
index c8f70da132..3c2cdaaac3 100644
--- a/package/network/utils/iproute2/patches/950-add-cake-to-tc.patch
+++ b/package/network/utils/iproute2/patches/950-add-cake-to-tc.patch
@@ -1,6 +1,6 @@
 --- a/include/uapi/linux/pkt_sched.h
 +++ b/include/uapi/linux/pkt_sched.h
-@@ -934,4 +934,75 @@ enum {
+@@ -934,4 +934,110 @@ enum {
  
  #define TCA_CBS_MAX (__TCA_CBS_MAX - 1)
  
@@ -22,66 +22,101 @@
 +  TCA_CAKE_MPU,
 +  TCA_CAKE_INGRESS,
 +  TCA_CAKE_ACK_FILTER,
++  TCA_CAKE_SPLIT_GSO,
 +  __TCA_CAKE_MAX
 +};
 +#define TCA_CAKE_MAX  (__TCA_CAKE_MAX - 1)
 +
-+struct tc_cake_traffic_stats {
-+  __u32 packets;
-+  __u32 link_ms;
-+  __u64 bytes;
++enum {
++  __TCA_CAKE_STATS_INVALID,
++  TCA_CAKE_STATS_CAPACITY_ESTIMATE,
++  TCA_CAKE_STATS_MEMORY_LIMIT,
++  TCA_CAKE_STATS_MEMORY_USED,
++  TCA_CAKE_STATS_AVG_NETOFF,
++  TCA_CAKE_STATS_MIN_NETLEN,
++  TCA_CAKE_STATS_MAX_NETLEN,
++  TCA_CAKE_STATS_MIN_ADJLEN,
++  TCA_CAKE_STATS_MAX_ADJLEN,
++  TCA_CAKE_STATS_TIN_STATS,
++  __TCA_CAKE_STATS_MAX
 +};
++#define TCA_CAKE_STATS_MAX (__TCA_CAKE_STATS_MAX - 1)
 +
++enum {
++  __TCA_CAKE_TIN_STATS_INVALID,
++  TCA_CAKE_TIN_STATS_PAD,
++  TCA_CAKE_TIN_STATS_SENT_PACKETS,
++  TCA_CAKE_TIN_STATS_SENT_BYTES64,
++  TCA_CAKE_TIN_STATS_DROPPED_PACKETS,
++  TCA_CAKE_TIN_STATS_DROPPED_BYTES64,
++  TCA_CAKE_TIN_STATS_ACKS_DROPPED_PACKETS,
++  TCA_CAKE_TIN_STATS_ACKS_DROPPED_BYTES64,
++  TCA_CAKE_TIN_STATS_ECN_MARKED_PACKETS,
++  TCA_CAKE_TIN_STATS_ECN_MARKED_BYTES64,
++  TCA_CAKE_TIN_STATS_BACKLOG_PACKETS,
++  TCA_CAKE_TIN_STATS_BACKLOG_BYTES64,
++  TCA_CAKE_TIN_STATS_THRESHOLD_RATE,
++  TCA_CAKE_TIN_STATS_TARGET_US,
++  TCA_CAKE_TIN_STATS_INTERVAL_US,
++  TCA_CAKE_TIN_STATS_WAY_INDIRECT_HITS,
++  TCA_CAKE_TIN_STATS_WAY_MISSES,
++  TCA_CAKE_TIN_STATS_WAY_COLLISIONS,
++  TCA_CAKE_TIN_STATS_PEAK_DELAY_US,
++  TCA_CAKE_TIN_STATS_AVG_DELAY_US,
++  TCA_CAKE_TIN_STATS_BASE_DELAY_US,
++  TCA_CAKE_TIN_STATS_SPARSE_FLOWS,
++  TCA_CAKE_TIN_STATS_BULK_FLOWS,
++  TCA_CAKE_TIN_STATS_UNRESPONSIVE_FLOWS,
++  TCA_CAKE_TIN_STATS_MAX_SKBLEN,
++  TCA_CAKE_TIN_STATS_FLOW_QUANTUM,
++  __TCA_CAKE_TIN_STATS_MAX
++};
++#define TCA_CAKE_TIN_STATS_MAX (__TCA_CAKE_TIN_STATS_MAX - 1)
 +#define TC_CAKE_MAX_TINS (8)
-+struct tc_cake_tin_stats {
-+
-+  __u32 threshold_rate;
-+  __u32 target_us;
-+  struct tc_cake_traffic_stats sent;
-+  struct tc_cake_traffic_stats dropped;
-+  struct tc_cake_traffic_stats ecn_marked;
-+  struct tc_cake_traffic_stats backlog;
-+  __u32 interval_us;
-+  __u32 way_indirect_hits;
-+  __u32 way_misses;
-+  __u32 way_collisions;
-+  __u32 peak_delay_us; /* ~= bulk flow delay */
-+  __u32 avge_delay_us;
-+  __u32 base_delay_us; /* ~= sparse flows delay */
-+  __u16 sparse_flows;
-+  __u16 bulk_flows;
-+  __u16 unresponse_flows;
-+  __u16 spare;
-+  __u32 max_skblen;
-+  struct tc_cake_traffic_stats ack_drops;
++
++enum {
++  CAKE_FLOW_NONE = 0,
++  CAKE_FLOW_SRC_IP,
++  CAKE_FLOW_DST_IP,
++  CAKE_FLOW_HOSTS,/* = CAKE_FLOW_SRC_IP | CAKE_FLOW_DST_IP */
++  CAKE_FLOW_FLOWS,
++  CAKE_FLOW_DUAL_SRC, /* = CAKE_FLOW_SRC_IP | CAKE_FLOW_FLOWS */
++  CAKE_FLOW_DUAL_DST, /* = CAKE_FLOW_DST_IP | CAKE_FLOW_FLOWS */
++  CAKE_FLOW_TRIPLE,   /* = CAKE_FLOW_HOSTS  | CAKE_FLOW_FLOWS */
++  CAKE_FLOW_MAX,
 +};
 +
-+struct tc_cake_xstats {
-+

[LEDE-DEV] [PATCH 0/2] bump cake support in iproute2 & kmod

2018-05-06 Thread Kevin Darbyshire-Bryant via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Bearing fruits of attempting to get cake upstream, a few changes most
importantly to the netlink messaging for cake such that it's no longer
backwards compatible, hence bumping iproute2's tc cake support and the
cake module itself at the same time.

Kevin Darbyshire-Bryant (2):
  iproute2: import latest cake
  cake: bump to 20180504 bake

 package/kernel/kmod-sched-cake/Makefile|   7 +-
 package/network/utils/iproute2/Makefile|   2 +-
 .../iproute2/patches/950-add-cake-to-tc.patch  | 869 ++---
 3 files changed, 429 insertions(+), 449 deletions(-)

-- 
2.15.1 (Apple Git-101)


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

Re: [LEDE-DEV] [PATCH 2/2] kernel: bump 4.14 to 4.14.38

2018-05-06 Thread Tomasz Maciej Nowak 
Hi Koen.

W dniu 03.05.2018 o 11:57, Koen Vandeputte pisze:
> All,
> 
> Please skip these.
> It does not apply anymore due to:   "kernel: add missing in6_dev_put_clear 
> call to an ipv6 network patch"
> 
> Also .. yet another kernel bump was released yesterday ..

If You'll be doing kernel bump for 4.14.39 or later, You cane safely drop these 
patches:

target/linux/mvebu/patches-4.14/522-PCI-aardvark-fix-logic-in-PCI-configuration-read-write-functions.patch
target/linux/mvebu/patches-4.14/523-PCI-aardvark-set-PIO_ADDR_LS-correctly-in-advk_pcie_rd_conf.patch
target/linux/mvebu/patches-4.14/524-PCI-aardvark-set-host-and-device-to-the-same-MAX-payload-size.patch
target/linux/mvebu/patches-4.14/525-PCI-aardvark-use-isr1-instead-of-isr0-interrupt-in-legacy-irq-mode.patch
target/linux/mvebu/patches-4.14/526-PCI-aardvark-disable-LOS-state-by-default.patch
target/linux/mvebu/patches-4.14/527-PCI-aardvark-fix-PCIe-max-read-request-size-setting.patch

Thanks for all Your work.

> V2 later on ..
> 
> Koen
> 

Cheers, Tomasz.

-- 
TMN

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

Re: [LEDE-DEV] Lack of DNS robustness for openwrt.org

2018-05-06 Thread John Crispin 



On 06/05/18 17:44, David Woodhouse wrote:

Hello,

I apologize for bringing up this long-standing issue at a time where you
all have need to other issues to take care of.  But it's again become a
real pressing issue, at least seen from the networks I have a presence in.

We can host it (primary or just secondary) on ns[123].infradead.org if it
helps...


why not move primary to digital ocean ?
    John

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

Re: [LEDE-DEV] [PATCH] download: skip hash check without a download hash

2018-05-06 Thread Paul Oranje 


> Op 30 apr. 2018, om 08:39 heeft John Crispin  het volgende 
> geschreven:
> 
> On 30/03/18 17:34, Hauke Mehrtens wrote:
>> If the package doe not contain a PKG_HASH just skip the check instead of
>> making the download fail. The scripts/download.pl script will
>> automatically skip the hash check in case the hash value equals skip,
>> otherwise it fails.
>> 
>> Signed-off-by: Hauke Mehrtens 
>> ---
>>  include/download.mk | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/include/download.mk b/include/download.mk
>> index 2ba8a7bdf4..b14ce2a39a 100644
>> --- a/include/download.mk
>> +++ b/include/download.mk
>> @@ -239,11 +239,11 @@ define Download/Defaults
>>URL_FILE:=
>>PROTO:=
>>HASH=$$(MD5SUM)
>> -  MD5SUM:=x
>> +  MD5SUM:=skip
>>SUBDIR:=
>>MIRROR:=1
>>MIRROR_HASH=$$(MIRROR_MD5SUM)
>> -  MIRROR_MD5SUM:=x
>> +  MIRROR_MD5SUM:=skip
>>VERSION:=
>>OPTS:=
>>  endef
> 
> Hi,
> I am against merging this patch. b30ba14e2a858cfebcfdbc38348ab96a6d179556 
> fixed an error where we had a copy/paste mess up of a hash causing a none 
> valid length. we would think that there is hash that gets checked but it 
> would never be validated. Adding your patch would introduce a similar case 
> where a typo in the variable name would make us believe that a hash is 
> present but in reality there it none. I'd prefer that the Makefile would have 
> the skip inside it and that the buildsystem would then skip the validation.
> 
> John
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Sometime last year there has been some discussion about skipping hash 
validations in development workflows and IIRC that it could (likewise) be 
controlled with setting a HASH to skip and that once a change would be ready 
for submission a true hash value would be set.

In the context of a development workflow the effect of a hash validation being 
skipped is limited to the environment of the developer, but after submission 
that would be different (and dangerous; I presume that a merge of a patch 
without a proper hash value should never occur).

Please correct me if I'am wrong, regards,
Paul


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

Re: [LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan (8devices) board.

2018-05-06 Thread Rosen Penev 
On Sun, May 6, 2018 at 3:52 AM, Daniel Danzberger  wrote:
> MMAP'ed memory that has been allocated via 'get_zeroed_page(GFP_KERNEL)' or
> 'vmalloc()' doesn't always contain the same data when accessed from userspace.
>
> This means all userspace programs using mmap to access kernel memory aren't
> always working properly on the Rambutan board. I am currently testing if other
> ar71xx devices are affected as well.
>
> I first noticed this when using ALSA's mmap api to capture audio.
>
> Here is the feed for a kmod + userpace util to reproduce the issue:
> g...@github.com:dddaniel/mmaptest.git
>
> The kernel module simply allocates a page and initializes it with 0xff.
> The userspace application then mmap's and reads this page 10 times with a 
> 500ms
> delay an checks if all data is 0xff.
>
> ---
> root@OpenWrt:/# mmaptest-user
> mmap addr: 0x77a04000
> [  760.464968] mmap page 7573000 at va 87573000
> check memory ...FAIL (at byte 0)
> check memory ...FAIL (at byte 96)
> check memory ...FAIL (at byte 96)
> check memory ...FAIL (at byte 96)
> check memory ...FAIL (at byte 128)
> ---
>
> I have no idea whats causing it. Does anybody have a hint on how to fix this ?
>
Try reverting 
https://github.com/torvalds/linux/commit/c00ab4896ed5f7d89af6f90b809e2c0197c6d170
> --
> Regards
>
> Daniel Danzberger
> embeDD GmbH, Alter Postplatz 2, CH-6370 Stans
>
> ___
> 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] Lack of DNS robustness for openwrt.org

2018-05-06 Thread David Woodhouse 

> Hello,
>
> I apologize for bringing up this long-standing issue at a time where you
> all have need to other issues to take care of.  But it's again become a
> real pressing issue, at least seen from the networks I have a presence in.

We can host it (primary or just secondary) on ns[123].infradead.org if it
helps...

-- 
dwmw2


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

[LEDE-DEV] [PATCH] iproute2: backport json_print-fix-hidden-64-bit-type-promotion

2018-05-06 Thread Kevin Darbyshire-Bryant via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
print_uint() will silently promote its variable type to uint64_t, but there
is nothing that ensures that the format string specifier passed along with
it fits (and the function name suggest to pass "%u").

Fix this by changing print_uint() to use a native 'unsigned int' type, and
introduce a separate print_u64() function for printing 64-bit values. All
call sites that were actually printing 64-bit values using print_uint() are
converted to use print_u64() instead.

Since print_int() was already using native int types, just add a
print_s64() to match, but don't convert any call sites.

Fixes wonkyness in some stats from some qdiscs under tc

Signed-off-by: Kevin Darbyshire-Bryant 
---
 package/network/utils/iproute2/Makefile|   2 +-
 ...on_print-fix-hidden-64-bit-type-promotion.patch | 288 +
 2 files changed, 289 insertions(+), 1 deletion(-)
 create mode 100644 
package/network/utils/iproute2/patches/002-json_print-fix-hidden-64-bit-type-promotion.patch

diff --git a/package/network/utils/iproute2/Makefile 
b/package/network/utils/iproute2/Makefile
index 8c5e22f289..f5a9db321d 100644
--- a/package/network/utils/iproute2/Makefile
+++ b/package/network/utils/iproute2/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=iproute2
 PKG_VERSION:=4.16.0
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@KERNEL/linux/utils/net/iproute2
diff --git 
a/package/network/utils/iproute2/patches/002-json_print-fix-hidden-64-bit-type-promotion.patch
 
b/package/network/utils/iproute2/patches/002-json_print-fix-hidden-64-bit-type-promotion.patch
new file mode 100644
index 00..ad93973215
--- /dev/null
+++ 
b/package/network/utils/iproute2/patches/002-json_print-fix-hidden-64-bit-type-promotion.patch
@@ -0,0 +1,288 @@
+From 8de9593bb9dc05cb1be593a237682e8707e41aa9 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= 
+Date: Wed, 25 Apr 2018 16:19:35 +0200
+Subject: [PATCH] json_print: Fix hidden 64-bit type promotion
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+print_uint() will silently promote its variable type to uint64_t, but there
+is nothing that ensures that the format string specifier passed along with
+it fits (and the function name suggest to pass "%u").
+
+Fix this by changing print_uint() to use a native 'unsigned int' type, and
+introduce a separate print_u64() function for printing 64-bit values. All
+call sites that were actually printing 64-bit values using print_uint() are
+converted to use print_u64() instead.
+
+Since print_int() was already using native int types, just add a
+print_s64() to match, but don't convert any call sites.
+
+Signed-off-by: Toke Høiland-Jørgensen 
+Signed-off-by: Kevin Darbyshire-Bryant 
+---
+ include/json_print.h  |  4 +++-
+ include/json_writer.h | 12 ++
+ ip/ipaddress.c| 62 +--
+ ip/ipmacsec.c |  8 +++
+ ip/ipmroute.c |  6 ++---
+ lib/json_print.c  |  4 +++-
+ lib/json_writer.c | 30 +
+ 7 files changed, 78 insertions(+), 48 deletions(-)
+
+--- a/include/json_print.h
 b/include/json_print.h
+@@ -56,10 +56,12 @@ void close_json_array(enum output_type t
+   print_color_##type_name(t, COLOR_NONE, key, fmt, value);
\
+   }
+ _PRINT_FUNC(int, int);
++_PRINT_FUNC(s64, int64_t);
+ _PRINT_FUNC(bool, bool);
+ _PRINT_FUNC(null, const char*);
+ _PRINT_FUNC(string, const char*);
+-_PRINT_FUNC(uint, uint64_t);
++_PRINT_FUNC(uint, unsigned int);
++_PRINT_FUNC(u64, uint64_t);
+ _PRINT_FUNC(hu, unsigned short);
+ _PRINT_FUNC(hex, unsigned int);
+ _PRINT_FUNC(0xhex, unsigned int);
+--- a/include/json_writer.h
 b/include/json_writer.h
+@@ -34,9 +34,11 @@ void jsonw_string(json_writer_t *self, c
+ void jsonw_bool(json_writer_t *self, bool value);
+ void jsonw_float(json_writer_t *self, double number);
+ void jsonw_float_fmt(json_writer_t *self, const char *fmt, double num);
+-void jsonw_uint(json_writer_t *self, uint64_t number);
++void jsonw_uint(json_writer_t *self, unsigned int number);
++void jsonw_u64(json_writer_t *self, uint64_t number);
+ void jsonw_hu(json_writer_t *self, unsigned short number);
+-void jsonw_int(json_writer_t *self, int64_t number);
++void jsonw_int(json_writer_t *self, int number);
++void jsonw_s64(json_writer_t *self, int64_t number);
+ void jsonw_null(json_writer_t *self);
+ void jsonw_lluint(json_writer_t *self, unsigned long long int num);
+ 
+@@ -44,9 +46,11 @@ void jsonw_lluint(json_writer_t *self, u

Re: [LEDE-DEV] Firewall restart crashes routers with kernel 4.14

2018-05-06 Thread Kristian Evensen 
Hi,

Thanks for your reply, good to know that I am not alone :)

On Sat, May 5, 2018 at 9:45 PM, Lucian Cristian  wrote:
> do you have hardware offloading enabled and multiwan ?
>
> I have the same problem when I enable them

The routers do support hardware offloading (ZBT WG3526 so mt7621), but
it is not enabled. At least I can't see a FLOWOFFLOAD-rule. The
routers do, however, have multiple active interfaces (WAN port +
modem). I have now compiled an image with rtcache again and tested the
following combinations:

- WAN port + modem active: Crash.
- Only WAN port active (disconnected modem from router): Crash.
- Removed xt_FLOWOFFLOAD module: Crash.

On an image with rtcache disabled, I don't see the crash. I don't know
it matters or not, but the router always crashes after "Zone 'wan'"
has been written to screen (in the "Populating IPv4 filter table"
step).

BR,
Kristian

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

[LEDE-DEV] Lack of DNS robustness for openwrt.org

2018-05-06 Thread Bjørn Mork 
Hello,

I apologize for bringing up this long-standing issue at a time where you
all have need to other issues to take care of.  But it's again become a
real pressing issue, at least seen from the networks I have a presence in.

The main problem is that there still hasn't been any update to the
*technical* part of the .org delegation:

 bjorn@miraculix:~$ whois openwrt.org|grep Name
 Domain Name: OPENWRT.ORG
 Registrant Name: SPI Hostmaster
 Admin Name: SPI Hostmaster
 Tech Name: SPI Hostmaster
 Name Server: ARRAKIS.DUNE.HU
 Name Server: BELATEGEUSE.DUNE.HU

So those two listed name servers are still the *only* two servers making
a difference when following the tree from root:

bjorn@miraculix:~$ dig ns openwrt.org @a0.org.afilias-nst.info

; <<>> DiG 9.10.3-P4-Debian <<>> ns openwrt.org @a0.org.afilias-nst.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39054
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;openwrt.org.   IN  NS

;; AUTHORITY SECTION:
openwrt.org.86400   IN  NS  arrakis.dune.hu.
openwrt.org.86400   IN  NS  belategeuse.dune.hu.

;; Query time: 159 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Sun May 06 12:56:35 CEST 2018
;; MSG SIZE  rcvd: 95




That would not be an issue if those two servers were inependent and
stable.  But they are not. First of all, both depend on being able to
resolve dune.hu.  So we ask one of the hu servers:

bjorn@miraculix:~$ dig ns dune.hu @a.hu

; <<>> DiG 9.10.3-P4-Debian <<>> ns dune.hu @a.hu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53327
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dune.hu.   IN  NS

;; AUTHORITY SECTION:
dune.hu.86400   IN  NS  dns4.vietnamfree.com.
dune.hu.86400   IN  NS  arrakis.dune.hu.
dune.hu.86400   IN  NS  belategeuse.dune.hu.

;; ADDITIONAL SECTION:
arrakis.dune.hu.86400   IN  A   78.24.191.176
belategeuse.dune.hu.86400   IN  A   217.20.135.200

;; Query time: 51 msec
;; SERVER: 2001:738:4:8000::48#53(2001:738:4:8000::48)
;; WHEN: Sun May 06 12:58:10 CEST 2018
;; MSG SIZE  rcvd: 150




And naturally get glue for the two servers which are in that same zone.
But none of them are answering DNS requests at the moment, from none of
the networks I have access to (which each have millions of users AFAIK).


bjorn@miraculix:~$ dig ns dune.hu @78.24.191.176

; <<>> DiG 9.10.3-P4-Debian <<>> ns dune.hu @78.24.191.176
;; global options: +cmd
;; connection timed out; no servers could be reached
bjorn@miraculix:~$ dig ns dune.hu @217.20.135.200

; <<>> DiG 9.10.3-P4-Debian <<>> ns dune.hu @217.20.135.200
;; global options: +cmd
;; connection timed out; no servers could be reached


But there is also a third server for dune.hu, so let's try that one:


bjorn@miraculix:~$ dig ns vietnamfree.com @a.gtld-servers.net

; <<>> DiG 9.10.3-P4-Debian <<>> ns vietnamfree.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1957
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;vietnamfree.com.   IN  NS

;; AUTHORITY SECTION:
vietnamfree.com.172800  IN  NS  irc.vietnamfree.com.
vietnamfree.com.172800  IN  NS  dns4.vietnamfree.com.
vietnamfree.com.172800  IN  NS  ns.vietnamfree.com.
vietnamfree.com.172800  IN  NS  ns3.vietnamfree.com.
vietnamfree.com.172800  IN  NS  dns5.vietnamfree.com.

;; ADDITIONAL SECTION:
irc.vietnamfree.com.172800  IN  A   195.56.146.224
dns4.vietnamfree.com.   172800  IN  A   195.56.77.197
ns.vietnamfree.com. 172800  IN  A   195.56.146.224
ns3.vietnamfree.com.172800  IN  A   202.157.185.115
dns5.vietnamfree.com.   172800  IN  A   62.165.228.216

;; Query time: 147 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Sun May 06 13:02:43 CEST 2018
;; MSG SIZE  rcvd: 215

bjorn@miraculix:~$ dig a dns4.vietnamfree.com @195.56.77.197

; <<>> DiG 9.10.3-P4-Debian <<>> a dns4.vietnamfree.com @195.56.77.197
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42806
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:

[LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan (8devices) board.

2018-05-06 Thread Daniel Danzberger 
MMAP'ed memory that has been allocated via 'get_zeroed_page(GFP_KERNEL)' or
'vmalloc()' doesn't always contain the same data when accessed from userspace.

This means all userspace programs using mmap to access kernel memory aren't
always working properly on the Rambutan board. I am currently testing if other
ar71xx devices are affected as well.

I first noticed this when using ALSA's mmap api to capture audio.

Here is the feed for a kmod + userpace util to reproduce the issue:
g...@github.com:dddaniel/mmaptest.git

The kernel module simply allocates a page and initializes it with 0xff.
The userspace application then mmap's and reads this page 10 times with a 500ms
delay an checks if all data is 0xff.

---
root@OpenWrt:/# mmaptest-user
mmap addr: 0x77a04000
[  760.464968] mmap page 7573000 at va 87573000
check memory ...FAIL (at byte 0)
check memory ...FAIL (at byte 96)
check memory ...FAIL (at byte 96)
check memory ...FAIL (at byte 96)
check memory ...FAIL (at byte 128)
---

I have no idea whats causing it. Does anybody have a hint on how to fix this ?

-- 
Regards

Daniel Danzberger
embeDD GmbH, Alter Postplatz 2, CH-6370 Stans

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

Re: [LEDE-DEV] 18.06 Status?

2018-05-06 Thread John Crispin 


On 06/05/18 09:43, Jaap Buurman wrote:

Dear John,

That is most excellent to hear :) Please disregard my previous 
comment. Where did this decision take place by the way? I tried 
searching the mailing list but couldn't find anything. My apologies 
for bothering the mailing list with this porposal while it was already 
taken care of.


Yours sincerely,

Jaap Buurman

On Sat, May 5, 2018, 19:57 John Crispin > wrote:




On 05/05/18 12:27, Jaap Buurman wrote:
> Hi all,
>
> I feel like everybody is just waiting for everybody to agree what
> features we want in before coming up with the next step of picking a
> date. Obviously this isn't working out very well. Why not turn
things
> around? Pick a date in a few weeks time on which the Master branch
> will be split to a 18.0X branch. If nobody complains before that
date
> the branch goes on as planned. People can obviously get in the
> features they want before said date. If somebody deems a particular
> feature very important to be included in this branch, but feels like
> it will not be finished before said date, he/she can request a delay
> stating:
>
> -What he/she would like to include
> -Why this is so important to be included before the branch.
> -How much extra time this will need by proposing a new date
> -Perhaps a request for help implementing said change
>
> Should this proposal be accepted, we will reschedule the date from
> there. If the other people don't think it is important enough to
> postpone the release, the old date will stand. This way, we can
simply
> move forward if nobody complains about a particular date instead of
> the waiting around for others that is going on right now. What does
> everybody else think of this idea? What seems like a reasonable
date?
> And who would be willing to take on the task of splitting the branch
> at said date to make sure we'll be actually moving forward with the
> plan at said date?
>
> Yours sincerely,
>
> Jaap Buurman
>
> On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen
> wrote:
>> On 05/01/2018 10:47 AM, Hannu Nyman wrote:
>>> I think that the main source tree is in pretty good shape, so
branching
>>> off the 18.0X rather soon might make sense
>>
>> I would also think its time to branch 18.[something-soon], and
rather than
>> focus on work that needs yet to be completed, look to cut
hardware and
>> packages that are not ready for a release. There is always some
heart ache
>> when such decisions are made, but at a point those decisions do
need to be
>> made. Without an official release to punctuate both the core
team and other
>> packagers hard work, OpenWrt/LEDE could risk losing support
from the
>> community and its limited sponsorship. I imagine this project means
>> something personally to the core team, so those risks should be
considered.
>>
>> - Eric
>>
>>
>> ___
>> lede-adm mailing list
>> lede-...@lists.infradead.org 
>> http://lists.infradead.org/mailman/listinfo/lede-adm
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org 
> http://lists.infradead.org/mailman/listinfo/lede-dev

we agreed already to branch on friday but delayed it till start of
the
week as we ran out of time before calling it a day.
 John



Hi,

please dont top post. The discussion happened here on the ML. we 
exchanged mails that we will do a 18.06 and now with june coming up we 
exchanged 5 lines on IRC trying to figure out when we have time to do 
the branching. this whole discussion is just creating FUD. we announced 
18.06 almost 2 months ago and now with june coming up we are executing 
the plan. no more no less. i really dont understand the commotion. 
thanks to alberto for providing some useful comments to the discussion.


    John


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