date:20171122

[LEDE-DEV] LEDE/OpenWrt firmware wizard

2017-11-22 Thread Moritz Warning

Hi,

I've put online a firmware wizard for LEDE:

http://mwarning.de/firmware-wizard/
(Sources: https://github.com/freifunk-bielefeld/firmware-wizard)

Build with rather plain HTML5/CSS/JS. Merge requests are welcome.
Everything is still rough around the edges.

It would be nice if downloads.lede-project.org would set 
"Access-Control-Allow-Origin: *",
since the code tries to scrape the download site. So far I use a pre-scraped 
file index as a workaround.
But that causes the file links to not work..

Have fun,
mwarning

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

[LEDE-DEV] odhcpd: possible regression in make DHCPv4 support compiletime configurable

2017-11-22 Thread Eric Luehrsen

FS#1188 has been raised due to problems for optional build recipes in 
"dhcpv4: make DHCPv4 support compiletime configurable" 
(d80621fea5cafcdca3f7fe762fede374a66e4b2) because no odhcpd-full package 
is build bot available. However, it also appears that conditionally 
compiling DHCPv4 back in does not work. This may be a rather significant 
regression.


- Eric

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

[LEDE-DEV] LEDE/OpenWrt firmware wizard

2017-11-22 Thread Moritz Warning

Hi,

I've put online a firmware wizard for LEDE:

http://mwarning.de/firmware-wizard/
(Sources: https://github.com/freifunk-bielefeld/firmware-wizard)

Build with rather plain HTML5/CSS/ES6. Merge requests are welcome.
Everything is still rough around the edges.

It would be nice if downloads.lede-project.org would set 
"Access-Control-Allow-Origin: *",
since the code tries to scrape the download site. So far I use a pre-scraped 
file index as a workaround.
That causes the file links to not work..

Have fun,
mwarning

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

[LEDE-DEV] WRT3200ACM crashes after mac80211 wireless-testing 2017-11-01

2017-11-22 Thread Syrone Wong

Hi,

1. minor warning

.config:5:warning: symbol value 'm' invalid for ATH_REG_DYNAMIC_USER_REG_HINTS

The config entry is of type bool.

config ATH_REG_DYNAMIC_USER_REG_HINTS
bool "Atheros dynamic user regulatory hints"
depends on CFG80211_CERTIFICATION_ONUS
default n
---help---
Say N. This should only be enabled in countries where
this feature is explicitly allowed and only on cards that
specifically have been tested for this.

2. wireless-regdb

python $(PKG_BUILD_DIR)/db2fw.py $(PKG_BUILD_DIR)/regulatory.db
$(PKG_BUILD_DIR)/db.txt in Build/Compile assumes python is linked to
python2 by default. But it's not the truth for bleeding edge distros,
for example, Archlinux.

It will fail on the system that links python to python 3.

File
"/home/wong/github/lede-1/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/wireless-regdb-2017-10-20-4343d359/db2fw.py",
line 13

print 'Usage: %s output-file input-file' % sys.argv[0]
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean
print(int 'Usage: %s output-file input-file' % sys.argv[0])?

The error got ignored silently.

I propose following `tools/scons/files/pywrap.sh` way, find python2
ourselves and call python2 explicitly.

3. About the crash

It crashes in ~5mins after clients connected to the router. No warning
or kernel panic messages at all, just rebooting.

I tried to build new backports based on wt-2017-11-14, drop some
patches already upstream, and still the same issue.

After reverting
6a6dc94e0c9a0533eaa9819bf3c22128b009af56,
9247864b6ed933841ee3068dbd4add06babe7fbd,
2dc485250d516f1535eeaf53f0f2f5742e5f9e0c and
f9fa266faf9a2fdea48cc2fb72fa5a7e52a527c0, the crash disappears.

4. My thoughts

The big change has been made is switching from internal regdb to a
self-built one.

>From net/wireless/Kconfig, there are several config entries are
enabled by default.

config CFG80211_REQUIRE_SIGNED_REGDB
bool "require regdb signature" if CFG80211_CERTIFICATION_ONUS
default y
select SYSTEM_DATA_VERIFICATION
help
Require that in addition to the "regulatory.db" file a
"regulatory.db.p7s" can be loaded with a valid PKCS#7
signature for the regulatory.db file made by one of the
keys in the certs/ directory.

config CFG80211_USE_KERNEL_REGDB_KEYS
bool "allow regdb keys shipped with the kernel" if CFG80211_CERTIFICATION_ONUS
default y
depends on CFG80211_REQUIRE_SIGNED_REGDB
help
Allow the regulatory database to be signed by one of the keys for
which certificates are part of the kernel sources
(in net/wireless/certs/).

This is currently only Seth Forshee's key, who is the regulatory
database maintainer.

config CFG80211_CRDA_SUPPORT
bool "support CRDA" if EXPERT
default y
depends on CFG80211
help
You should enable this option unless you know for sure you have no
need for it, for example when using internal regdb (above) or the
database loaded as a firmware file.

If unsure, say Y.

We don't have CRDA installed and there is no signing key being
installed. This might be the root cause. While I'm not familiar with
this series of changes. I wonder if someone can dig into it.

Best Regards,
Syrone Wong

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

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

2017-11-22 Thread Christian Lamparter

On Wednesday, November 22, 2017 9:55:39 AM CET Koen Vandeputte wrote:
> >> Yes,
> >>
> >> Main reason in that specific case was mainly for these 2 fixes:
> >>
> >> /9e01be6 fix signal masking race in pthread_create with priority (I use
> >> lots of threading & thread priority in my app) //51bdcdc fix OOB reads in 
> >> Xbyte_memmem (used by memmem() ) /
> >>
> > Hm? Are you now talking about something else? I remember seeing these
> > commits listed in your musl update to 1.1.16+.
> > 
> >
> > But Felix did the update musl to 1.1.18 on the 5th (I noticed that he had
> > a patch queued). This update included the changes you listed, right?
> >
> I was indeed referring to that one, as a mere example where I proposed 
> to bump to head, just like you propose now. (got superseded)
> http://patchwork.ozlabs.org/patch/823135/
Ah ok, I misread this at first and got confused. Thank you for taking the
time to explain what was going on here.

In any case it seems like the commits entered Felix's staging tree.


> > Maybe a balanced solution would be to wait for 1 .. 2  tested-by's
> > before pushing these to master?
> > Great that you bring this up. So, did you test >this patch< already too?
> > And if so, what's your verdict? Does it perform as expected on your cns3xxx?
> > Can you please post a "tested-by" tag then?
> I've added it to my daily build yesterday, and it's running on my stress 
> setup currently. (9 boards: 6x cns3xxx & 3x imx6, all meshed up)
> If all goes well, I'm more that happy to drop a tested-by within the 
> next few hours (like I sometimes do for other people's patches too)
Yes, I saw Kevin and your mail too. Thank you both! :)

> Feel free to do the same for mine ;)
Yes, of course. Please do include me in the "CC:", this way it will
hit my inbox, instead of being delivered to just the Mailinglist folder.

The linux kernel ships with a rather useful perl script called:
get_maintainer.pl. (Yes, it can be a blessing but it can also be a curse)

Long ago, this script required a project maintain a special MAINTAINERS file.
However nowadays, the tool has the ability to extract this information from 
git by looking at the previous commits (Emails from Signed-off-by: Reviewed-by:
and Acked-by: tags). And for the most part, this is compatible with LEDE's 
patch guidelines. 

For example, for this patch it will generate the following output:

$ get_maintainer.pl 0004-toolchain-musl-update-to-current-HEAD.patch 
Felix Fietkau  
(authored:3/7=43%,added_lines:5/17=29%,removed_lines:5/14=36%,authored:1/2=50%,added_lines:3/54=6%,removed_lines:3/22=14%)
Christian Lamparter  
(authored:2/7=29%,added_lines:8/17=47%,removed_lines:5/14=36%,authored:1/2=50%,added_lines:51/54=94%,removed_lines:19/22=86%)
Koen Vandeputte  
(authored:2/7=29%,added_lines:4/17=24%,removed_lines:4/14=29%)

So, this tool has picked you as a reviewer! ;)

If you (or anyone else) want to check it out, I've uploaded this slightly
modified version github gist [removed "linux kernel" references in help texts
and changed top_of_kernel_tree() func to work for the LEDE's root directory.]

(To download, press "Raw" button)

Is there any interest for this?

Regards,
Christian

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

[LEDE-DEV] Trouble with dnsmasq

2017-11-22 Thread e9hack

Hi,

I've some trouble with dnsmasq since the last kernel update but it isn't an 
issue of the kernel. After reboot (or
sysupgrade), dnsmasq isn't able to do a name resolution of hosts provided by 
the host file:

Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: read 
/tmp/hosts/dhcp.cfg02411c - 0 addresses

The file contains 5 entries. I did add some logger calls and check the syslog:

Tue Nov 21 22:18:16 2017 user.notice [DNSMASQ:790]: start boot()
Tue Nov 21 22:18:16 2017 user.notice [DNSMASQ:790]: start start_service()
Tue Nov 21 22:18:16 2017 user.notice [DNSMASQ:790]: end start_service()
Tue Nov 21 22:18:17 2017 user.notice [DNSMASQ:790]: end boot()
Tue Nov 21 22:18:37 2017 user.notice [DNSMASQ:1061]: start reload_service()
Tue Nov 21 22:18:37 2017 user.notice [DNSMASQ:1061]: start start_service()
Tue Nov 21 22:18:39 2017 user.notice [DNSMASQ:1061]: echo "# auto-generated 
config file from /etc/config/dhcp" >
/tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:18:44 2017 user.notice [DNSMASQ:1061]: echo "192.168.a.b HOST1" 
>> /tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:18:44 2017 user.notice [DNSMASQ:1061]: echo "192.168.a.b HOST2" 
>> /tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:18:44 2017 user.notice [DNSMASQ:1061]: echo "192.168.a.b HOST3" 
>> /tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:18:44 2017 user.notice [DNSMASQ:1061]: echo "192.168.a.b HOST4" 
>> /tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:21:32 2017 user.notice [DNSMASQ:1061]: echo "192.168.a.b HOST5" 
>> /tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:21:38 2017 user.notice [DNSMASQ:1061]: end start_service()
Tue Nov 21 22:21:40 2017 user.notice [DNSMASQ:1061]: end reload_service()
Tue Nov 21 22:21:41 2017 user.notice [DNSMASQ:1430]: start reload_service()
Tue Nov 21 22:21:41 2017 user.notice [DNSMASQ:1430]: start start_service()
Tue Nov 21 22:21:41 2017 user.notice [DNSMASQ:1430]: echo "# auto-generated 
config file from /etc/config/dhcp" >
/tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: started, version 
2.79test1-2-g6fd5d79 cachesize 150
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: compile time options: IPv6 
GNU-getopt no-DBus no-i18n no-IDN DHCP
DHCPv6 no-Lua TFTP no-conntrack no-ipset auth DNSSEC no-ID loop-detect inotify
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq-dhcp[1410]: DHCP, IP range 
192.168.a.b -- 192.168.a.b, lease time 2d
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain test
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain onion
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain localhost
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain local
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain invalid
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain example.net
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain example.org
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain example.com
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using 3 more local addresses
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: reading 
/tmp/resolv.conf.auto
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain test
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain onion
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain localhost
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain local
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain invalid
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain example.net
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain example.org
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using local addresses only 
for domain example.com
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using nameserver 
192.168.a.b#53
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using nameserver 
fec0:a:b:c:d:e#53
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using nameserver 
fec0:a:b:c:d:f#53
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: using 3 more local addresses
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: read /etc/hosts - 1 
addresses
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq[1410]: read 
/tmp/hosts/dhcp.cfg02411c - 0 addresses
Tue Nov 21 22:21:42 2017 daemon.info dnsmasq-dhcp[1410]: read /etc/ethers - 0 
addresses
Tue Nov 21 22:21:42 2017 user.notice [DNSMASQ:1430]: echo "192.168.a.b HOST1" 
>> /tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:21:42 2017 user.notice [DNSMASQ:1430]: echo "192.168.a.b HOST2" 
>> /tmp/hosts/dhcp.cfg02411c
Tue Nov 21 22:21:42 2017 user.notice [DNSMASQ:1430]:

Re: [LEDE-DEV] [PATCH] samba36: Disable by default

2017-11-22 Thread Val Kulkov

No problem with "use sendfile = yes" on bcm53xx platform,
arm_cortex-a9, LEDE SNAPSHOT r5297-bddffc5 (and preceding development
releases), running for a long time (weeks or months), used daily by
several users.

On 21 November 2017 at 04:34, Karl Palsson  wrote:
>
> Rosen Penev  wrote:
>> sendfile has been tested to have stability issues with at least
>> mt7621 and mvebu. With both, I've had the system reboot(no logs
>> unfortunately). It usually happens when seeking multiple times
>> with a single video file. A different user said disabling
>> sendfile improved her uptime from a few hours to around 10
>> days.
>
> Do you have a ticket for this? this would seem to be a bigger
> problem than just samba, and should get solved via something more
> than just disabling one part of samba. Also, I find it hard to
> believe that sendfile would be broken on al platforms.
>
> Sincerely,
> Karl Palsson
> ___
> 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] [PATCH] samba36: Disable by default

2017-11-22 Thread Lucian Cristian


On 22.11.2017 16:20, Paul Oranje wrote:

On an archer-c7-v2 running 17.01.2 and samba with "use sendfile" enabled, no 
problems have been noticed (long up-time).
S.y. Paul


Op 21 nov. 2017, om 10:34 heeft Karl Palsson  het volgende 
geschreven:


Rosen Penev  wrote:

sendfile has been tested to have stability issues with at least
mt7621 and mvebu. With both, I've had the system reboot(no logs
unfortunately). It usually happens when seeking multiple times
with a single video file. A different user said disabling
sendfile improved her uptime from a few hours to around 10
days.

Do you have a ticket for this? this would seem to be a bigger
problem than just samba, and should get solved via something more
than just disabling one part of samba. Also, I find it hard to
believe that sendfile would be broken on al platforms.

Sincerely,
Karl Palsson___
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


never had problems with samba and sendfile was always yes, even with 
hundred of days of uptime but very few users  (x86 & mvebu, win 
7,10,2016,xp)


Regards


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

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

2017-11-22 Thread Kevin Darbyshire-Bryant



> On 22 Nov 2017, at 11:07, Koen Vandeputte  
> wrote:
> 
> Tested-by: Koen Vandeputte 
> 
> Targets: cns3xxx, imx6
> 
> Also
> 
> Tested-by: Kevin Darbyshire-Bryant 
> 
> ar71xx

> ___
> 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] [PATCH 4/4] toolchain: musl: update to current HEAD

2017-11-22 Thread Koen Vandeputte


Tested-by: Koen Vandeputte 

Targets: cns3xxx, imx6


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

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

2017-11-22 Thread Koen Vandeputte




Yes,

Main reason in that specific case was mainly for these 2 fixes:

/9e01be6 fix signal masking race in pthread_create with priority (I use
lots of threading & thread priority in my app) //51bdcdc fix OOB reads in 
Xbyte_memmem (used by memmem() ) /


Hm? Are you now talking about something else? I remember seeing these
commits listed in your musl update to 1.1.16+.


But Felix did the update musl to 1.1.18 on the 5th (I noticed that he had
a patch queued). This update included the changes you listed, right?

I was indeed referring to that one, as a mere example where I proposed 
to bump to head, just like you propose now. (got superseded)

http://patchwork.ozlabs.org/patch/823135/


fwiw, my 2 cents:

I try to carefully judge whether there's a good reason to bump head or
not, and I mostly wait for min 48 hrs to let the latest commits soak a bit.

"waiting" around doesn't help in regression cases. I think this
glob-regression is another case in point. The issue was discovered
more than a week before 1.1.17 was released:

and when I posted the request to move to 1.1.17 (again).
But it only received the attention, once people started testing the new
1.1.17 and did bisections.
After Syrone's reply concerning the regression, we've immediately 
contacted the committer in a separate mail-thread to get in-depth asap :)

keep in mind the reply mentioned:

"when I update to c10bc61 powerpc{64}: fix MAP_NORESERVE and MAP_LOCKED in 
mman.h"

Which indicates it was not clear at that time which commit exactly 
caused it.


Maybe a balanced solution would be to wait for 1 .. 2  tested-by's
before pushing these to master?
Great that you bring this up. So, did you test >this patch< already too?
And if so, what's your verdict? Does it perform as expected on your cns3xxx?
Can you please post a "tested-by" tag then?
I've added it to my daily build yesterday, and it's running on my stress 
setup currently. (9 boards: 6x cns3xxx & 3x imx6, all meshed up)
If all goes well, I'm more that happy to drop a tested-by within the 
next few hours (like I sometimes do for other people's patches too)


Feel free to do the same for mine ;)


As for pushing to master: From most past experience, a patch usually sits
in the patchwork queue for some time (a few days to months). Then one of
the commiter adds it to his/her public staging tree and if all went well,
the patch moves to master eventually.
  
Regards,

Christian


Keep in mind that I'm defending your approach completely, as long as the 
reason to bump is valid (in general) :)


Koen

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

[LEDE-DEV] LEDE/OpenWrt firmware wizard

[LEDE-DEV] odhcpd: possible regression in make DHCPv4 support compiletime configurable

[LEDE-DEV] LEDE/OpenWrt firmware wizard

[LEDE-DEV] WRT3200ACM crashes after mac80211 wireless-testing 2017-11-01

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[LEDE-DEV] Trouble with dnsmasq

Re: [LEDE-DEV] [PATCH] samba36: Disable by default

Re: [LEDE-DEV] [PATCH] samba36: Disable by default

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

11 matches

Site Navigation

Mail list logo

Footer information