[LEDE-DEV] [PATCH] base-files: uppercase default hostname: LEDE

2017-01-10 Thread Yousong Zhou 
The name will appear in shell prompt and LuCI page title.  Uppercase
letters seem to be more vigorous

Signed-off-by: Yousong Zhou 
---
 package/base-files/files/bin/config_generate | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/base-files/files/bin/config_generate 
b/package/base-files/files/bin/config_generate
index f9b4e5c..6230b08 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -226,7 +226,7 @@ generate_static_system() {
uci -q batch <<-EOF
delete system.@system[0]
add system system
-   set system.@system[-1].hostname='lede'
+   set system.@system[-1].hostname='LEDE'
set system.@system[-1].timezone='UTC'
set system.@system[-1].ttylogin='0'
set system.@system[-1].log_size='64'
-- 
2.6.4


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

[LEDE-DEV] [PATCH v2] wpa_supplicant: Fix mesh encryption config

2017-01-10 Thread Sujith 
From: Sujith Manoharan 

wpa_supplicant allows only SAE as the key management
type for mesh mode. The recent key_mgmt rework unconditionally
added WPA-PSK - this breaks interface bringup and wpa_s
throws this error message:

Line 10: key_mgmt for mesh network should be open or SAE
Line 10: failed to parse network block.
Failed to read or parse configuration '/var/run/wpa_supplicant-wlan0.conf

Fix this by making sure that only SAE is used for mesh.

Signed-off-by: Sujith Manoharan 
---
 package/network/services/hostapd/files/netifd.sh | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/netifd.sh 
b/package/network/services/hostapd/files/netifd.sh
index a7a6a64e7a..fb23e52e67 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -617,7 +617,10 @@ wpa_supplicant_add_network() {
psk)
local passphrase
 
-   hostapd_append_wpa_key_mgmt
+   if [ "$_w_mode" != "mesh" ]; then
+   hostapd_append_wpa_key_mgmt
+   fi
+
key_mgmt="$wpa_key_mgmt"
 
if [ ${#key} -eq 64 ]; then
-- 
2.11.0


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

Re: [LEDE-DEV] externalizing package management?

2017-01-10 Thread i...@rauberhaus.de 
you guys know the meshkit ?

http://firmware.leipzig.freifunk.net:8086/meshkit/default/wizard

as it used in leipzig, or for freifunk in general for example.
There you can add packages in second step as you like ...

this is far mor advanced

jens
On 11.01.2017 00:22, Oswald Buddenhagen wrote:
> On Sun, Jan 08, 2017 at 08:42:25PM +0100, Jo-Philipp Wich wrote:
>> the imagebuilder should support all that already and it likely fills the
>> "powerful desktop tools" part your concept requires.
>>

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

[LEDE-DEV] per-cpu IRQ stack on MIPS

2017-01-10 Thread Jason A. Donenfeld 
Hey folks,

You might considering backporting this patchset to the LEDE/OpenWRT kernel:

http://www.spinics.net/lists/mips/msg65937.html

It prevents crashes when lots of different networking drivers are
stacked on top of eachother, like gre+l2tp+somethingelse.

Jason

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

Re: [LEDE-DEV] externalizing package management?

2017-01-10 Thread Oswald Buddenhagen 
On Sun, Jan 08, 2017 at 08:42:25PM +0100, Jo-Philipp Wich wrote:
> the imagebuilder should support all that already and it likely fills the
> "powerful desktop tools" part your concept requires.
> 
i answered that in my other mail already.

anyway, specifically regarding the existing imagebuilder, i'm not really
satisfied. it's a big download which is specific to each target, and
requires pretty much a complete build environment. of course, it's the
obvious choice to minimize development effort, but as a user i'd expect
something ... nicer.

in my understanding, sysupgrade images (and uimages) are a pretty
uniform archive format, just like the feed packages are. that means that
a single generic tool should be able to work with all targets, over
extended periods of time, and would need to support a rather limited
number of features to accomplish the goal of building images from the
"regular" image+package downloads that are already available.

> Given the recent advances with Linux support on Windows 10 plus Docker
> etc. it shouldn't be too hard to bundle an ImageBuilder with some
> Desktop ui and an RPC client to remote-control the router via SSH or
> HTTPS-UBUS-RPC.
> 
that's way too new-fangled for my taste. :D
a simple desktop application (built with the cross-platform toolkit of
the developer's choice) would do just fine. all the steps that deal with
the archives can be handled in-process by linked libraries (most of the
code is already librarized). offer three pre-built binaries for the
major desktops. "regular" linux distros would package it for you as well.

of course, over time the scope of that application could be extended
into a generic openwrt installer which can actually flash uboot and
everything on top. that would actually provide significant added value
over the purely on-device update mechanism proposed in the other thread,
and could potentially significantly increase the user base of openwrt.

a different aspect would be developing it into a complete desktop-based
"luci" (basically an extended version of the initial idea of this
thread), but that seems kinda unreasonable to me.

> Do you plan to work on something like that?
> 
given current realities of the size of my todo list and available spare
time, the best i can hope for is to inspire Someone Else (TM) to pick up
some of my ideas ...

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

Re: [LEDE-DEV] how to make sysupgrade not drop user-installed packages

2017-01-10 Thread Oswald Buddenhagen 
On Sun, Jan 08, 2017 at 08:38:04PM +0100, Jo-Philipp Wich wrote:
> Right now it cannot be provided unless we provide suitable meta data for
> that on the server side or - preferably - inside the image itself.
> 
i actually had that typed out already, but deleted it because it seems
like a complete no-brainer to me. there doesn't appear to be anything
hard about having the build bots include a file into /etc which contains
the _current_ repository url, subdirectory, and image name.

whenever the de-facto policy changes in an ordered way, there should be
a transition phase where the images are available at both locations, but
already point to the new one.

and when the download fails because the policy changes unexpectedly (or
the user neglected to trigger the process for too long), the interactive
variant of the tool can just ask for the information it found outdated.
even in this worst case, that system is still *a lot* more convenient
(and thus less likely to contribute to unpatched CPEs) than what exists
now.

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

Re: [LEDE-DEV] Branching LEDE 17.01

2017-01-10 Thread Ted Hess 
On Tue, 2017-01-10 at 16:19 +0100, Jo-Philipp Wich wrote:
> Hi guys,
> 
> I'd like to branch off lede-17.01 on Friday, the 13th and would
> appreciate if you could merge your outstanding, release critical work
> until then.
> 
> If you think we should delay branching, then raise your objections now.
> 
> If no objections are brought up within the next 24 hours, I'll go
> forward asking the feed maintainers to create "lede-17.01" branches.
> 
> 
> Regards,
> Jo
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Hi Jo -

Could you possibly hold off on this until after the weekend. I'm still working
on a few PolarSSL issues (and some other more minor) in the Packages repo. I
should have them done by then.

After that, I'll just cherry-pick other fixes until we freeze a release.

/ted


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

Re: [LEDE-DEV] procd question, something causing high cpu usage

2017-01-10 Thread Sebastian Kemper 
On Mon, Jan 09, 2017 at 04:33:02PM +0100, Baptiste Jonglez wrote:
> Hi Sebastian,
> 
> On Mon, Dec 19, 2016 at 11:58:26PM +0100, Sebastian Kemper wrote:
> > Hi all,
> > 
> > I'm running LEDE git from yesterday (but also observed this on an older
> > git revision from a few weeks back) on a small mips router. When I start
> > freeswitch compiled without libedit via procd, CPU usage goes up to a
> > 100% percent. When freeswitch is compiled with libedit on the other
> > hand, everything seems fine.
> > 
> > Also, when I start the libedit-less freeswitch from the command
> > line/shell, all is fine, too.
> > 
> > When I set the logging to syslog (procd_set_param stdout 1), then
> > logread shows this all the time:
> > 
> > Mon Dec 19 23:17:12 2016 daemon.info freeswitch[3495]: freeswitch@hank2> 
> > Mon Dec 19 23:17:12 2016 daemon.info freeswitch[3495]: freeswitch@hank2> 
> > Mon Dec 19 23:17:12 2016 daemon.info freeswitch[3495]: freeswitch@hank2> 
> > Mon Dec 19 23:17:12 2016 daemon.info freeswitch[3495]: freeswitch@hank2> 
> 
> What is the behaviour of freeswitch when you launch it directly from the
> command-line?  Does it give you a prompt, or does it just run in the
> foreground without printing anything?

Hi Baptiste,

It gives a prompt.

> 
> If freeswitch expects an interactive terminal to accept user commands,
> it's most likely the cause of the issue, because procd does not provide
> this.  If that is the case, maybe disabling the interactive prompt in
> freeswitch could help?

Yes, but as this only happens when FS is compiled without libedit, I
don't think it's the prompt per se.

And yes, when I disable the prompt by calling it with -nc (no console)
and -fg (no fork) then there's no issue with CPU consumption. It's just
that procd really wants the console output, which is nice because you
can put it into logd if you want.

But for now the workaround will do.

Thanks!
Sebastian


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

[LEDE-DEV] [PATCH v3] Curl: fix HTTPS network timeouts with OpenSSL

2017-01-10 Thread Stijn Segers 
Hi John,

I hope this works better then? Wasn't too sure about leaving in the e-mail etc.
from upstream.

This patch fixes HTTPS timeouts with OpenSSL. Upstream curl bug #1174.

Cheers!

Stijn

Signed-off-by: Stijn Segers 
---
 .../curl/patches/320-curl-https-openssl-fix.patch  | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 
package/network/utils/curl/patches/320-curl-https-openssl-fix.patch

diff --git 
a/package/network/utils/curl/patches/320-curl-https-openssl-fix.patch 
b/package/network/utils/curl/patches/320-curl-https-openssl-fix.patch
new file mode 100644
index 00..259f618d46
--- /dev/null
+++ b/package/network/utils/curl/patches/320-curl-https-openssl-fix.patch
@@ -0,0 +1,36 @@
+From a7b38c9dc98481e4a5fc37e51a8690337c674dfb Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Mon, 26 Dec 2016 00:06:33 +0100
+Subject: [PATCH] vtls: s/SSLEAY/OPENSSL
+
+Fixed an old leftover use of the USE_SSLEAY define which would make a
+socket get removed from the applications sockets to monitor when the
+multi_socket API was used, leading to timeouts.
+
+Bug: #1174
+---
+ lib/vtls/vtls.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/vtls/vtls.c b/lib/vtls/vtls.c
+index b808e1c..707f24b 100644
+--- a/lib/vtls/vtls.c
 b/lib/vtls/vtls.c
+@@ -484,7 +484,7 @@ void Curl_ssl_close_all(struct Curl_easy *data)
+   curlssl_close_all(data);
+ }
+ 
+-#if defined(USE_SSLEAY) || defined(USE_GNUTLS) || defined(USE_SCHANNEL) || \
++#if defined(USE_OPENSSL) || defined(USE_GNUTLS) || defined(USE_SCHANNEL) || \
+ defined(USE_DARWINSSL) || defined(USE_NSS)
+ /* This function is for OpenSSL, GnuTLS, darwinssl, and schannel only. */
+ int Curl_ssl_getsock(struct connectdata *conn, curl_socket_t *socks,
+@@ -518,7 +518,7 @@ int Curl_ssl_getsock(struct connectdata *conn,
+   (void)numsocks;
+   return GETSOCK_BLANK;
+ }
+-/* USE_SSLEAY || USE_GNUTLS || USE_SCHANNEL || USE_DARWINSSL || USE_NSS */
++/* USE_OPENSSL || USE_GNUTLS || USE_SCHANNEL || USE_DARWINSSL || USE_NSS */
+ #endif
+ 
+ void Curl_ssl_close(struct connectdata *conn, int sockindex)
-- 
2.11.0


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

Re: [LEDE-DEV] All0333CJ LEDE

2017-01-10 Thread Jo-Philipp Wich 
Hi Florian,

I suppose you've chosen the wrong recipient address here :)

~ Jo



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

[LEDE-DEV] All0333CJ LEDE

2017-01-10 Thread Florian Wobbe 
Hi Tino,

ich habe deinen thread auf LEDE-DEV gesehen. Ich habe einige Erfahrung
im Portieren von Freezt, LEDE ist mir jedoch neu. Deshalb ein paar Fragen bevor 
ich starte:

Ist das Modem mit deinem gepatchten LEDE-kernel bereits voll
einsatzfähig im Bridge-Modus? Auf deiner Seite steht etwas von 70% Fortschritt. 
Was meinst du genau damit?

Hat der Einsatz von neuem kernel bzw. DSL-Firmware Auswirkung auf die
Erwärmung des Geräts?

Die standard DSL Firmware scheint nur mit maximal 2 Mbps Upload zu 
synchronisieren. Konntest du das Problem mit einer aktuelleren Firmware beheben?

Dein Image konnte ich entpacken aber hast du eine Idee wie man das Filesystem 
von mtd1.bin entpackt?

$ binwalk mtd1.bin

DECIMAL   HEXADECIMAL DESCRIPTION
-
---
0 0x0 Squashfs filesystem, big endian, lzma
compression, version 2.1, size: 1856697 bytes, 790 inodes, blocksize:
65536 bytes, created: 2013-01-24 05:38:40
3556560   0x3644D0uImage header, header size: 64 bytes,
header CRC: 0xED79EBF9, created: 2013-01-24 05:38:19, image size:
552170 bytes, Data Address: 0x80002000, Entry Point: 0x8019A040, data
CRC: 0x38AAA3BA, OS: Linux, CPU: MIPS, image type: OS Kernel Image,
compression type: lzma, image name: "MIPS Linux-2.4.31-Amazon_SE-3.6.]"
3556624   0x364510LZMA compressed data, properties: 0x5D,
dictionary size: 8388608 bytes, uncompressed size: 1867776 bytes
4108808   0x3EB208gzip compressed data, maximum
compression, from Unix, last modified: 2013-01-24 13:29:07

Ich hab mit unsquashfs_all.sh von firmware-mod-kit keinen Erfolg.

Gruß
Florian


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Linksys WRT1900ACS wifi issues with recent LEDE build

2017-01-10 Thread Kevin Beranek 
I had an older build of LEDE from sometime in December that was quite
stable (I don't know the exact version any more), but I upgraded to
r2718-fd718c5 recently and I've been having issues with the wifi on an
approximately daily basis.  I finally captured logs from one of these
events.  I've included the logs below.  I removed a bunch of lines
that are obviously not relevant and redacted IPs and MAC addresses.
The first section of logs below is what I saw after running "logread"
immediately after I noticed issues.  I then ran "/etc/init.d/network
restart", hoping it would fix things, but I was still seeing errors
and wifi didn't work until after I rebooted the device.

I see a couple commits (94030e86d5ea357f6c541d534c0ee1c8ab714fa5 and
24e58c3f72a94ebf659586eb876b06b59adb2bb2) that look suspicious simply
because they touched mwlwifi during the time period between my working
and non-working builds.  I haven't had a chance yet to test rolling
back either of those commits.

I also noticed that there's a very recent upstream commit in mwlwifi
titled "Modification of the code to truely support ACS." (commit id
0d5b9c26adbd984dee814453ab49914cc78bce19), which seems like something
that might be worth trying.

Any ideas?  Any additional information I can provide that might be useful?


Tue Jan 10 02:51:07 2017 kern.err kernel: [84609.492605] ieee80211
phy0: cmd 0x9125=BAStream timed out
Tue Jan 10 02:51:07 2017 kern.err kernel: [84609.498050] ieee80211
phy0: return code: 0x1125
Tue Jan 10 02:51:07 2017 kern.err kernel: [84609.502618] ieee80211
phy0: timeout: 0x1125
Tue Jan 10 02:51:07 2017 kern.err kernel: [84609.506838] ieee80211
phy0: destroy ba failed execution
Tue Jan 10 02:51:12 2017 daemon.info hostapd: wlan1: STA XXX WPA:
group key handshake completed (RSN)
Tue Jan 10 02:51:44 2017 kern.err kernel: [84646.102006] ieee80211
phy0: cmd 0x9122=UpdateEncryption timed out
Tue Jan 10 02:51:44 2017 kern.err kernel: [84646.108136] ieee80211
phy0: return code: 0x1122
Tue Jan 10 02:51:44 2017 kern.err kernel: [84646.112692] ieee80211
phy0: timeout: 0x1122
Tue Jan 10 02:51:44 2017 kern.err kernel: [84646.116892] ieee80211
phy0: failed execution
Tue Jan 10 02:51:44 2017 kern.err kernel: [84646.121180] wlan0: failed
to remove key (0, XXX) from hardware (-5)
Tue Jan 10 02:51:48 2017 kern.err kernel: [84650.128059] ieee80211
phy0: cmd 0x9122=UpdateEncryption timed out
Tue Jan 10 02:51:48 2017 kern.err kernel: [84650.134193] ieee80211
phy0: return code: 0x1122
Tue Jan 10 02:51:48 2017 kern.err kernel: [84650.138744] ieee80211
phy0: timeout: 0x1122
Tue Jan 10 02:51:48 2017 kern.err kernel: [84650.142961] ieee80211
phy0: failed execution
Tue Jan 10 02:51:48 2017 kern.err kernel: [84650.147253] wlan0: failed
to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-4)
Tue Jan 10 02:51:52 2017 kern.err kernel: [84654.153997] ieee80211
phy0: cmd 0x9122=UpdateEncryption timed out
Tue Jan 10 02:51:52 2017 kern.err kernel: [84654.160120] ieee80211
phy0: return code: 0x1122
Tue Jan 10 02:51:52 2017 kern.err kernel: [84654.164684] ieee80211
phy0: timeout: 0x1122
Tue Jan 10 02:51:52 2017 kern.err kernel: [84654.168887] ieee80211
phy0: failed execution
Tue Jan 10 02:51:52 2017 kern.err kernel: [84654.173182] wlan0: failed
to set key (2, ff:ff:ff:ff:ff:ff) to hardware (-5)
Tue Jan 10 02:51:56 2017 kern.err kernel: [84658.179938] ieee80211
phy0: cmd 0x9122=UpdateEncryption timed out
Tue Jan 10 02:51:56 2017 kern.err kernel: [84658.186066] ieee80211
phy0: return code: 0x1122
Tue Jan 10 02:51:56 2017 kern.err kernel: [84658.190615] ieee80211
phy0: timeout: 0x1122
Tue Jan 10 02:51:56 2017 kern.err kernel: [84658.194822] ieee80211
phy0: failed execution
Tue Jan 10 02:51:56 2017 kern.err kernel: [84658.199110] wlan0: failed
to remove key (0, XXX) from hardware (-5)
Tue Jan 10 02:52:00 2017 kern.err kernel: [84662.211881] ieee80211
phy0: cmd 0x9122=UpdateEncryption timed out
Tue Jan 10 02:52:00 2017 kern.err kernel: [84662.218003] ieee80211
phy0: return code: 0x1122
Tue Jan 10 02:52:00 2017 kern.err kernel: [84662.222561] ieee80211
phy0: timeout: 0x1122
Tue Jan 10 02:52:00 2017 kern.err kernel: [84662.226760] ieee80211
phy0: failed execution
Tue Jan 10 02:52:00 2017 kern.err kernel: [84662.231046] wlan0-1:
failed to remove key (0, XXX) from hardware (-5)
Tue Jan 10 02:52:04 2017 kern.err kernel: [84666.239843] ieee80211
phy0: cmd 0x9122=UpdateEncryption timed out
Tue Jan 10 02:52:04 2017 kern.err kernel: [84666.245978] ieee80211
phy0: return code: 0x1122
Tue Jan 10 02:52:04 2017 kern.err kernel: [84666.250540] ieee80211
phy0: timeout: 0x1122
Tue Jan 10 02:52:04 2017 kern.err kernel: [84666.254753] ieee80211
phy0: failed execution
Tue Jan 10 02:52:04 2017 kern.err kernel: [84666.259045] wlan0-1:
failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-5)
Tue Jan 10 02:52:08 2017 kern.err kernel: [84670.267782] ieee80211
phy0: cmd 0x9122=UpdateEncryption timed out
Tue Jan 10 02:52:08 2017 kern.err kernel: [84670.273925] ieee80211
phy0: return

[LEDE-DEV] LEDE static routes not working when masquerade/firewall is on

2017-01-10 Thread Mauro Mozzarelli 

Hello,

When I switched from OpenWrt to LEDE static routes configured on my 
network stopped working.


My configuration is as follows:


  Internet ADSL
|
|
Internet ADSLRouter C
[Dynamic IP]  [Public Subnet P]
  | |
  | Address on Subnet P
  Router B   Router A -- VPN to 192.168.2.0
 192.168.1.5   192.168.1.1
  | |
  | |
  --- [Private LAN 192.168.1.0]
|
 Host X
Default Router 192.168.1.5


Router A is configured to Masquerade traffic from 192.168.1.0 through 
its port on Subnet P

Router C is the default router for Public Subnet P
Router B is configured with a static route to Public Subnet P through 
192.168.1.1
I want traffic from Hosts with 192.168.1.5 default route to Public 
Subnet P to go via 192.168.1.1 (instead of through the internet)
I want traffic from Hosts with 192.168.1.5 default route to VPN 
192.168.2.0 to go via 192.168.1.1
On Router B I configure a static route directing traffic for Public 
Subnet P through 192.168.1.1
On Router B I configure a static route directing traffic for VPN 
192.168.2.0 through 192.168.1.1


Behaviour from Host X:

- Using OpenWRT (any version including latest trunk):
  I can ping any host on Public Subnet P or VPN 192.168.2.0
  I can http/https, use any protocol to any host on Public Subnet P or 
VPN 192.168.2.0


- Using LEDE up to build r2713 (the latest i tried)
I can ping any host on Public Subnet or VPN 192.168.2.0
  Any attempt to connect using any other internet protocol to any host 
in Public Subnet P or VPN 192.168.2.0 fails.


However if I disable Masquerading or the firewall altogether in Router B 
my connections succeed.


It looks as if response packets are somehow blocked by the firewall 
before they reach Host X (I can see connections coming on the hosts in 
Public Subnet P, and responses returning, but not reaching Host X).


I tried to add s specific directive to the Router B firewall to let 
through packets from Public Subnet P, but it is not working.
The only workaround I found working is to create a SNAT rule on Router B 
to Rewrite the source IP to 192.168.1.5 with destination Public Subnet 
P. This however should be un-necessary if the routing worked properly.


When I use OperWRT and I ping hosts on Subnet P from Host X I get an 
initial notification that the router is 192.168.1.1.

With LEDE installed I do not get such notification.


Are you aware of what was changed in LEDE that makes static routes no 
longer work properly?


Thank you in advance.

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

Re: [LEDE-DEV] Branching LEDE 17.01

2017-01-10 Thread Daniel Golle 
Hi!

I'd really like to see a rather trivial issue addressed:
dnsmasq fails to get notifications on /tmp/resolv.conf.auto changes
when running inside ujail. This is because the bind mount obviously
won't survive this file being *replaced*, eg. if the DHCP client
supplies the DNS server to be used only after dnsmasq has already
been started.

The easiest solution would be to introduce a directory
/tmp/resolv.conf.d/, move all /tmp/resolv.conf* in there and bind mount
that into the jail instead. The current /tmp/resolv.conf.auto seems to
hardcoded in netifd and appears in dnsmasq's and mwan's default config.
Anywhere else? Given the overall code quality of dnsmasq, it would
really be nice to at least have it run in a jail by default for the
next release...

Mentioning the problem to John, he said that the current bind mounting
approach will be replaced by a future jailfs he is working on. However,
I'm afraid this won't be ready by Friday ;)

If there are no objections, I'll suggest a PR introducing
/tmp/resolv.conf.d/ and moving the location of /tmp/resolv.conf* into
that directory.

Cheers

Daniel


On Tue, Jan 10, 2017 at 04:19:05PM +0100, Jo-Philipp Wich wrote:
> Hi guys,
> 
> I'd like to branch off lede-17.01 on Friday, the 13th and would
> appreciate if you could merge your outstanding, release critical work
> until then.
> 
> If you think we should delay branching, then raise your objections now.
> 
> If no objections are brought up within the next 24 hours, I'll go
> forward asking the feed maintainers to create "lede-17.01" branches.
> 
> 
> Regards,
> Jo
> 
> ___
> 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

[LEDE-DEV] [PATCH] ramips: add support for RATOC REX-WIFISD2

2017-01-10 Thread FUKAUMI Naoki 
RATOC REX-WIFISD2 is a battery-powered wireless SD card reader with

 - MT7620A + MT7610E
 - 64MiB DDR2 SDRAM
 - 16MiB SPI flash
 - 2T2R 2.4GHz + 1T1R 5GHz Wi-Fi
 - 1x 10/100Mbps ethernet switch
 - 1x SD card
 - 1x USB 2.0
 - 2x programmable LED
 - 1x button

stock firmware is very similar to HooToo Tripmate travel routers. you
can do almost anything as a root user with telnet and/or shell script
(factory image or "EnterRouterMode.sh") on stock firmware.

"EnterRouterMode.sh" will be the easiest way to install. put the
following shell script into SD card (or USB storage) as
"EnterRouterMode.sh" with "kernel.bin" and "rootfs.bin" files.

 
 #!/bin/sh

 dir=`dirname $0`

 mtd_write write ${dir}/kernel.bin Kernel_RootFS
 mtd_write -r write ${dir}/rootfs.bin Rootfs
 

it will be run automatically when SD card is mounted on stock firmware.

TFTP can also be used to flash kernel and rootfs. it will be run by
press & hold RESET button while power on. (serverip=10.10.10.254)

you may use all partitions between "kernel" and "rootfs" as a single
"firmware" partition (please edit dts yourself), but "params" partition
should be kept if you want to restore stock firmware.

Signed-off-by: FUKAUMI Naoki 
---
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   3 +-
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/REX-WIFISD2.dts| 145 +
 target/linux/ramips/image/mt7620.mk|  10 ++
 6 files changed, 162 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/REX-WIFISD2.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index daf9b33..d59a450 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -189,6 +189,7 @@ ramips_setup_interfaces()
mzk-ex750np|\
na930|\
pbr-d1|\
+   rex-wifisd2|\
wli-tx4-ag300n|\
wmr-300|\
wrh-300cr)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index a22be5e..94be032 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -41,7 +41,8 @@ get_status_led() {
xdxrn502j)
status_led="$board:green:power"
;;
-   3g-6200nl)
+   3g-6200nl|\
+   rex-wifisd2)
status_led="$board:green:internet"
;;
a5-v11|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 9b82b2a..90f8370 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -400,6 +400,9 @@ ramips_board_detect() {
*"RE6500")
name="re6500"
;;
+   *"REX-WIFISD2")
+   name="rex-wifisd2"
+   ;;
*"RN502J")
name="xdxrn502j"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index c097cfa..87f4ecd 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -111,6 +111,7 @@ platform_check_image() {
px-4885|\
rb750gr3|\
re6500|\
+   rex-wifisd2|\
rp-n53|\
rt5350f-olinuxino|\
rt5350f-olinuxino-evb|\
diff --git a/target/linux/ramips/dts/REX-WIFISD2.dts 
b/target/linux/ramips/dts/REX-WIFISD2.dts
new file mode 100644
index 000..ddf7e01
--- /dev/null
+++ b/target/linux/ramips/dts/REX-WIFISD2.dts
@@ -0,0 +1,145 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "ratoc,rex-wifisd2", "ralink,mt7620a-soc";
+   model = "RATOC REX-WIFISD2";
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+
+   reset {
+   label = "reset";
+   gpios = < 1 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   internet {
+   label = "rex-wifisd2:green:internet";
+   gpios = < 2 GPIO_ACTIVE_HIGH>;
+   };
+
+   wifi {
+   label = "rex-wifisd2:blue:wifi";
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   mtd-mac-address = < 0x2e>;
+   mediatek,portmap = "w";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+

Re: [LEDE-DEV] [PATCH] ar71xx: prepare jffs2 partition properly in factory.bin for BHR-4GRV2

2017-01-10 Thread Naoki FUKAUMI 
hi,

could you handle this patch?

Regards,

On Fri, Dec 23, 2016 at 10:43 PM, Naoki FUKAUMI  wrote:
> hi
>
> what's the current status?
>
> On Fri, Dec 9, 2016 at 5:53 PM, FUKAUMI Naoki  wrote:
>> "pad-rootfs" is required just after "append-rootfs".
>>
>> Signed-off-by: FUKAUMI Naoki 
>> ---
>>  target/linux/ar71xx/image/generic.mk | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/target/linux/ar71xx/image/generic.mk 
>> b/target/linux/ar71xx/image/generic.mk
>> index 6ceabeb..b1d9af9 100644
>> --- a/target/linux/ar71xx/image/generic.mk
>> +++ b/target/linux/ar71xx/image/generic.mk
>> @@ -704,6 +704,6 @@ define Device/bhr-4grv2
>>MTDPARTS := 
>> spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14528k(rootfs),1472k(kernel),64k(art)ro,16000k@0x5(firmware)
>>IMAGES := sysupgrade.bin factory.bin
>>IMAGE/sysupgrade.bin = append-rootfs | pad-rootfs | pad-to 
>> (ROOTFS_SIZE) | append-kernel | check-size (IMAGE_SIZE)
>> -  IMAGE/factory.bin = append-kernel | pad-to (KERNEL_SIZE) | 
>> append-rootfs | mkbuffaloimg
>> +  IMAGE/factory.bin = append-kernel | pad-to (KERNEL_SIZE) | 
>> append-rootfs | pad-rootfs | mkbuffaloimg
>>  endef
>>  TARGET_DEVICES += bhr-4grv2
>> --
>> 2.7.4
>>

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

[LEDE-DEV] [PATCH v3 3/3] ramips: add support for Buffalo WCR-1166DS

2017-01-10 Thread FUKAUMI Naoki 
Buffalo WCR-1166DS is a small wireless router with

 - MT7628AN + MT7612E
 - 64MiB DDR2 SDRAM
 - 16MiB SPI flash
 - 2T2R 2.4/5GHz Wi-Fi
 - 2x 10/100M ethernet switch
 - 8x LED
 - 3x button
 - UART pad on PCB (J2: 3.3V, GND, TX, RX)

factory image can be installed via stock web UI.

due to the "dual image" function in the bootloader, the second half of
the SPI flash ("firmware2" partition) cannot be used as a part of the
file system.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v3:
- added

 .../linux/ramips/base-files/etc/board.d/02_network |  15 +-
 target/linux/ramips/base-files/etc/diag.sh |  11 +-
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   9 +-
 target/linux/ramips/dts/WCR-1166DS.dts | 172 +
 target/linux/ramips/image/Makefile |   3 +-
 target/linux/ramips/image/mt7628.mk|  16 ++
 target/linux/ramips/mt7628/config-4.4  |   1 +
 ...r-custom-trx-magic-for-Buffalo-WCR-1166DS.patch |  30 
 9 files changed, 245 insertions(+), 15 deletions(-)
 create mode 100644 target/linux/ramips/dts/WCR-1166DS.dts
 create mode 100644 
target/linux/ramips/patches-4.4/0400-mtd-mtdsplit-add-support-for-custom-trx-magic-for-Buffalo-WCR-1166DS.patch

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index daf9b33..0b7c5b4 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -256,6 +256,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
;;
+   wcr-1166ds)
+   ucidef_add_switch "switch0" \
+   "3:lan" "4:wan" "6@eth0"
+   ;;
wcr-150gn)
ucidef_add_switch "switch0" \
"0:lan" "6t@eth0"
@@ -392,6 +396,12 @@ ramips_setup_macs()
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 5)
;;
+   wcr-1166ds|\
+   wsr-1166)
+   local index="$(find_mtd_index "board_data")"
+   wan_mac="$(grep -m1 mac= "/dev/mtd${index}" | cut -d= -f2)"
+   lan_mac=$wan_mac
+   ;;
wcr-150gn)
wan_mac=$(mtd_get_mac_binary factory 40)
;;
@@ -409,11 +419,6 @@ ramips_setup_macs()
wlr-6000)
wan_mac=$(macaddr_add "$(mtd_get_mac_binary factory 32772)" 2)
;;
-   wsr-1166)
-   local index="$(find_mtd_index "board_data")"
-   wan_mac="$(grep -m1 mac= "/dev/mtd${index}" | cut -d= -f2)"
-   lan_mac=$wan_mac
-   ;;
*)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 1)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index a22be5e..c20e939 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -211,6 +211,12 @@ get_status_led() {
zbt-wr8305rt)
status_led="$board:green:sys"
;;
+   wcr-1166ds|\
+   whr-300hp2|\
+   wsr-1166|\
+   wsr-600)
+   status_led="$board:green:power"
+   ;;
wcr-150gn|\
wl-351)
status_led="$board:amber:power"
@@ -225,11 +231,6 @@ get_status_led() {
wizfi630a)
status_led="$board::run"
;;
-   whr-300hp2|\
-   wsr-1166|\
-   wsr-600)
-   status_led="$board:green:power"
-   ;;
wrtnode2r | \
wrtnode2p | \
wrtnode)
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 9b82b2a..766cc72 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -490,6 +490,9 @@ ramips_board_detect() {
*"W502U")
name="w502u"
;;
+   *"WCR-1166DS")
+   name="wcr-1166ds"
+   ;;
*"WCR-150GN")
name="wcr-150gn"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index c097cfa..4be59b8 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -222,6 +222,11 @@ platform_check_image() {
}
return 0
;;
+   ubnt-erx)
+   nand_do_platform_check "$board" "$1"
+   return $?;
+   ;;
+   wcr-1166ds|\
wsr-1166)
[ "$magic" != "48445230" ] && {

[LEDE-DEV] [PATCH v3 2/3] bcm53xx: build factory images for WZR-900DHP series

2017-01-10 Thread FUKAUMI Naoki 
only factory images for DHP-EU and DHP2-JP (fw ver. 2.x) are built.

this will not work for DHP-JP/AP/TW (fw ver. 1.x) because they use
different buffalo_csum() formula.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v3:
- renumbered, no change

Changes in v2:
- refresh everything to make rules simple

 target/linux/bcm53xx/image/Makefile | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index 853c9b2..d7478fe 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -38,6 +38,17 @@ define Build/bcm53xx-tplink-safeloader
rm $@.trx
 endef
 
+define Build/buffalo-wzr-header
+   $(eval product=$(word 1,$(1)))
+   $(eval region=$(word 2,$(1)))
+   ( \
+   echo 
$(product)_$(BUFFALO_TAG_VERSION)_$(BUFFALO_TAG_MINOR)_$(region)_$(BUFFALO_TAG_PLATFORM);
 \
+   echo filelen=$$(stat -c%s $@); \
+   cat $@ \
+   ) > $@.new
+   mv $@.new $@
+endef
+
 define Build/trx-serial
$(STAGING_DIR_HOST)/bin/trx \
-o $@.new \
@@ -85,6 +96,7 @@ define Build/seama-nand
 endef
 
 DEVICE_VARS += PRODUCTID SIGNATURE NETGEAR_BOARD_ID NETGEAR_REGION TPLINK_BOARD
+DEVICE_VARS += BUFFALO_TAG_PLATFORM BUFFALO_TAG_VERSION BUFFALO_TAG_MINOR
 
 BRCMFMAC_43602A1 := kmod-brcmfmac brcmfmac-firmware-43602a1-pcie
 BRCMFMAC_4366B1 := kmod-brcmfmac brcmfmac-firmware-4366b1-pcie
@@ -149,6 +161,20 @@ endef
 TARGET_DEVICES += buffalo-wzr-600dhp2
 
 define Device/buffalo-wzr-900dhp
+  BUFFALO_TAG_PLATFORM := bcm
+  BUFFALO_TAG_VERSION := 9.99
+  BUFFALO_TAG_MINOR := 9.99
+  IMAGES += factory-DHP-EU.bin factory-DHP2-JP.bin
+  IMAGE/factory-DHP-EU.bin := \
+   append-ubi | trx-nand | buffalo-wzr-header WZR-900DHP EU | \
+   buffalo-enc WZR-900DHP $$(BUFFALO_TAG_VERSION) | \
+   buffalo-tag-dhp WZR-900DHP EU mlang20 | buffalo-enc-tag | \
+   buffalo-dhp-image
+  IMAGE/factory-DHP2-JP.bin := \
+   append-ubi | trx-nand | buffalo-wzr-header WZR-900DHP2 JP | \
+   buffalo-enc WZR-900DHP2 $$(BUFFALO_TAG_VERSION) | \
+   buffalo-tag-dhp WZR-900DHP2 JP jp | buffalo-enc-tag | \
+   buffalo-dhp-image
   DEVICE_TITLE := Buffalo WZR-900DHP
   DEVICE_PACKAGES := kmod-b43 $(USB3_PACKAGES)
 endef
-- 
2.7.4


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

[LEDE-DEV] [PATCH v3 1/3] firmware-utils: improve tools for Buffalo DHP series

2017-01-10 Thread FUKAUMI Naoki 
some of Buffalo DHP series use slightly different trx magic, buffalo-enc,
buffalo-tag, and factory image begin with 'bgn'.

this patch adds support for building those images.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v3:
- no change

Changes in v2:
- refresh everything to make rules simple

 include/image-commands.mk  | 33 +
 tools/firmware-utils/Makefile  |  1 +
 tools/firmware-utils/src/buffalo-enc.c | 26 +--
 tools/firmware-utils/src/buffalo-lib.h | 20 
 tools/firmware-utils/src/buffalo-tag.c | 46 --
 tools/firmware-utils/src/mkdhpimg.c| 85 ++
 tools/firmware-utils/src/trx.c | 13 +-
 7 files changed, 215 insertions(+), 9 deletions(-)
 create mode 100644 tools/firmware-utils/src/mkdhpimg.c

diff --git a/include/image-commands.mk b/include/image-commands.mk
index a7acd0e..6dadb1f 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -11,6 +11,39 @@ define Build/uImage
@mv $@.new $@
 endef
 
+define Build/buffalo-enc
+   $(eval product=$(word 1,$(1)))
+   $(eval version=$(word 2,$(1)))
+   $(eval args=$(wordlist 3,$(words $(1)),$(1)))
+   $(STAGING_DIR_HOST)/bin/buffalo-enc \
+   -p $(product) -v $(version) $(args) \
+   -i $@ -o $@.new
+   mv $@.new $@
+endef
+
+define Build/buffalo-enc-tag
+   $(call Build/buffalo-enc,'' '' -S 152 $(1))
+endef
+
+define Build/buffalo-tag-dhp
+   $(eval product=$(word 1,$(1)))
+   $(eval region=$(word 2,$(1)))
+   $(eval language=$(word 3,$(1)))
+   $(STAGING_DIR_HOST)/bin/buffalo-tag \
+   -d 0x0100 -w 1 \
+   -a $(BUFFALO_TAG_PLATFORM) \
+   -v $(BUFFALO_TAG_VERSION) -m $(BUFFALO_TAG_MINOR) \
+   -b $(product) -p $(product) \
+   -r $(region) -r $(region) -l $(language) \
+   -I $@ -o $@.new
+   mv $@.new $@
+endef
+
+define Build/buffalo-dhp-image
+   $(STAGING_DIR_HOST)/bin/mkdhpimg $@ $@.new
+   mv $@.new $@
+endef
+
 define Build/netgear-chk
$(STAGING_DIR_HOST)/bin/mkchkimg \
-o $@.new \
diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index 69cba69..2504678 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -80,6 +80,7 @@ define Host/Compile
$(call cc,jcgimage, -lz -Wall)
$(call cc,mkbuffaloimg, -Wall)
$(call cc,zyimage, -Wall)
+   $(call cc,mkdhpimg buffalo-lib, -Wall)
 endef
 
 define Host/Install
diff --git a/tools/firmware-utils/src/buffalo-enc.c 
b/tools/firmware-utils/src/buffalo-enc.c
index 794659e..08fad4e 100644
--- a/tools/firmware-utils/src/buffalo-enc.c
+++ b/tools/firmware-utils/src/buffalo-enc.c
@@ -35,6 +35,7 @@ static char *product;
 static char *version;
 static int do_decrypt;
 static int offset;
+static int size;
 
 void usage(int status)
 {
@@ -54,6 +55,7 @@ void usage(int status)
 "  -v set version to \n"
 "  -h  show this screen\n"
 "  -O  Offset of encrypted data in file (decryption)\n"
+"  -S  Size of unencrypted data in file (encryption)\n"
);
 
exit(status);
@@ -118,7 +120,7 @@ out:
 static int encrypt_file(void)
 {
struct enc_param ep;
-   ssize_t src_len;
+   ssize_t src_len, tail_dst, tail_len, tail_src;
unsigned char *buf;
uint32_t hdrlen;
ssize_t totlen = 0;
@@ -131,8 +133,12 @@ static int encrypt_file(void)
goto out;
}
 
-   totlen = enc_compute_buf_len(product, version, src_len);
-   hdrlen = enc_compute_header_len(product, version);
+   if (size) {
+   tail_dst = enc_compute_buf_len(product, version, size);
+   tail_len = src_len - size;
+   totlen = tail_dst + tail_len;
+   } else
+   totlen = enc_compute_buf_len(product, version, src_len);
 
buf = malloc(totlen);
if (buf == NULL) {
@@ -140,12 +146,21 @@ static int encrypt_file(void)
goto out;
}
 
+   hdrlen = enc_compute_header_len(product, version);
+
err = read_file_to_buf(ifname, [hdrlen], src_len);
if (err) {
ERR("unable to read from file '%s'", ofname);
goto free_buf;
}
 
+   if (size) {
+   tail_src = hdrlen + size;
+   memmove([tail_dst], [tail_src], tail_len);
+   memset([tail_src], 0, tail_dst - tail_src);
+   src_len = size;
+   }
+
memset(, '\0', sizeof(ep));
ep.key = (unsigned char *) crypt_key;
ep.seed = seed;
@@ -241,7 +256,7 @@ int main(int argc, char *argv[])
while ( 1 ) {
int c;
 
-   c = getopt(argc, argv, "adi:m:o:hlp:v:k:O:r:s:");
+   c = getopt(argc, argv, "adi:m:o:hlp:v:k:O:r:s:S:");
if (c == -1)

[LEDE-DEV] Branching LEDE 17.01

2017-01-10 Thread Jo-Philipp Wich 
Hi guys,

I'd like to branch off lede-17.01 on Friday, the 13th and would
appreciate if you could merge your outstanding, release critical work
until then.

If you think we should delay branching, then raise your objections now.

If no objections are brought up within the next 24 hours, I'll go
forward asking the feed maintainers to create "lede-17.01" branches.


Regards,
Jo

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

[LEDE-DEV] [PATCH] cns3xxx: restore mpcore watchdog

2017-01-10 Thread Koen Vandeputte 
Adds the mpcore watchdog driver for kernel 4.4 as it was originally
present up to kernel 3.12

- Disabled by default for now, but can be simply enabled in kernelconfig
- Currently does not contain the latest patches as mentioned here:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-
next.git/commit/?id=6e63a3a294fdf91eaaac1061a9c7a5f53d16ac25

Tested on cns3xxx (GW2388)

[0.70] mpcore_wdt: MPcore Watchdog Timer: 0.1. mpcore_noboot=0
mpcore_margin=60 sec (nowayout= 1)
[3.49] mpcore_wdt mpcore_wdt: enabling watchdog
[3.49] init: - watchdog -
[8.75] procd: - watchdog -

Signed-off-by: Koen Vandeputte 
---
 target/linux/cns3xxx/config-4.4|   1 +
 .../patches-4.4/300-restore-mpcore-watchdog.patch  | 502 +
 2 files changed, 503 insertions(+)
 create mode 100644 
target/linux/cns3xxx/patches-4.4/300-restore-mpcore-watchdog.patch

diff --git a/target/linux/cns3xxx/config-4.4 b/target/linux/cns3xxx/config-4.4
index 4745f4e..ffc1f02 100644
--- a/target/linux/cns3xxx/config-4.4
+++ b/target/linux/cns3xxx/config-4.4
@@ -182,6 +182,7 @@ CONFIG_MMC_SDHCI_CNS3XXX=y
 CONFIG_MMC_SDHCI_PLTFM=y
 # CONFIG_MMC_TIFM_SD is not set
 CONFIG_MODULES_USE_ELF_REL=y
+# CONFIG_MPCORE_WATCHDOG is not set
 CONFIG_MTD_M25P80=y
 # CONFIG_MTD_OF_PARTS is not set
 CONFIG_MTD_PHYSMAP=y
diff --git a/target/linux/cns3xxx/patches-4.4/300-restore-mpcore-watchdog.patch 
b/target/linux/cns3xxx/patches-4.4/300-restore-mpcore-watchdog.patch
new file mode 100644
index 000..156dcaa
--- /dev/null
+++ b/target/linux/cns3xxx/patches-4.4/300-restore-mpcore-watchdog.patch
@@ -0,0 +1,502 @@
+--- a/Documentation/watchdog/watchdog-parameters.txt
 b/Documentation/watchdog/watchdog-parameters.txt
+@@ -196,6 +196,14 @@ reset: Watchdog Interrupt/Reset Mode. 0
+ nowayout: Watchdog cannot be stopped once started
+   (default=kernel config parameter)
+ -
++mpcore_wdt:
++mpcore_margin: MPcore timer margin in seconds.
++  (0 < mpcore_margin < 65536, default=60)
++nowayout: Watchdog cannot be stopped once started
++  (default=kernel config parameter)
++mpcore_noboot: MPcore watchdog action, set to 1 to ignore reboots,
++  0 to reboot (default=0
++--
+ mv64x60_wdt:
+ nowayout: Watchdog cannot be stopped once started
+   (default=kernel config parameter)
+--- a/drivers/watchdog/Kconfig
 b/drivers/watchdog/Kconfig
+@@ -297,6 +297,15 @@ config DW_WATCHDOG
+ To compile this driver as a module, choose M here: the
+ module will be called dw_wdt.
+ 
++config MPCORE_WATCHDOG
++  tristate "MPcore watchdog"
++  depends on HAVE_ARM_TWD
++  help
++Watchdog timer embedded into the MPcore system.
++
++To compile this driver as a module, choose M here: the
++module will be called mpcore_wdt.
++
+ config EP93XX_WATCHDOG
+   tristate "EP93xx Watchdog"
+   depends on ARCH_EP93XX
+--- a/drivers/watchdog/Makefile
 b/drivers/watchdog/Makefile
+@@ -43,6 +43,7 @@ obj-$(CONFIG_S3C2410_WATCHDOG) += s3c241
+ obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o
+ obj-$(CONFIG_SAMA5D4_WATCHDOG) += sama5d4_wdt.o
+ obj-$(CONFIG_DW_WATCHDOG) += dw_wdt.o
++obj-$(CONFIG_MPCORE_WATCHDOG) += mpcore_wdt.o
+ obj-$(CONFIG_EP93XX_WATCHDOG) += ep93xx_wdt.o
+ obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
+ obj-$(CONFIG_IOP_WATCHDOG) += iop_wdt.o
+--- /dev/null
 b/drivers/watchdog/mpcore_wdt.c
+@@ -0,0 +1,454 @@
++/*
++ *Watchdog driver for the mpcore watchdog timer
++ *
++ *(c) Copyright 2004 ARM Limited
++ *
++ *Based on the SoftDog driver:
++ *(c) Copyright 1996 Alan Cox ,
++ *All Rights Reserved.
++ *
++ *This program is free software; you can redistribute it and/or
++ *modify it under the terms of the GNU General Public License
++ *as published by the Free Software Foundation; either version
++ *2 of the License, or (at your option) any later version.
++ *
++ *Neither Alan Cox nor CymruNet Ltd. admit liability nor provide
++ *warranty for any of this software. This material is provided
++ *"AS-IS" and at no charge.
++ *
++ *(c) Copyright 1995Alan Cox 
++ *
++ */
++
++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
++
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++
++#include 
++
++struct mpcore_wdt {
++  unsigned long   timer_alive;
++  struct device   *dev;
++  void __iomem*base;
++  int irq;
++  unsigned intperturb;
++  charexpect_close;
++};
++
++static struct platform_device *mpcore_wdt_pdev;
++static DEFINE_SPINLOCK(wdt_lock);
++
++#define TIMER_MARGIN  60
++static int mpcore_margin = TIMER_MARGIN;

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

2017-01-10 Thread Yousong Zhou 
On 10 January 2017 at 20:20, John Crispin  wrote:
>
>
> On 10/01/2017 12:11, Yousong Zhou wrote:
>> On 10 January 2017 at 18:27, John Crispin  wrote:
>>> correct, which is why we tend to add subsystem and lib stuff using
>>> AutoLoad and the rest using AutoProbe
>>
>> I think the problem with wireguard in github issue 3790 [1] is that
>> wireguard requires NFPROTO_{IPV4,IPV6} "hashlimit" module and
>> netfilter subsystem will try to load ipt_hashlimit and ip6t_hashlimit
>> which are aliases of xt_hashlimit, but we have aliases along with
>> other modinfoinfo stripped from kernel modules with patch
>> 204-module_strip.patch.
>>
>> It looks to me mod aliases are essential part of the module info in
>> this case . What do you think about restoring them by patching the
>> 204.xxx.patch?
>>
>> [1] https://github.com/openwrt/packages/issues/3790
>>
>> yousong
>>
>
> why not simply set the hashlimit to autoload and make wireguard depend
> on it ? that should resolve the loading issue.
>
> John

Yes, but the point is that missing aliases is a generic issue and
autoloading hashlimit only fixes a single case.

yousong

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

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

2017-01-10 Thread John Crispin 


On 10/01/2017 12:11, Yousong Zhou wrote:
> On 10 January 2017 at 18:27, John Crispin  wrote:
>> correct, which is why we tend to add subsystem and lib stuff using
>> AutoLoad and the rest using AutoProbe
> 
> I think the problem with wireguard in github issue 3790 [1] is that
> wireguard requires NFPROTO_{IPV4,IPV6} "hashlimit" module and
> netfilter subsystem will try to load ipt_hashlimit and ip6t_hashlimit
> which are aliases of xt_hashlimit, but we have aliases along with
> other modinfoinfo stripped from kernel modules with patch
> 204-module_strip.patch.
> 
> It looks to me mod aliases are essential part of the module info in
> this case . What do you think about restoring them by patching the
> 204.xxx.patch?
> 
> [1] https://github.com/openwrt/packages/issues/3790
> 
> yousong
> 

why not simply set the hashlimit to autoload and make wireguard depend
on it ? that should resolve the loading issue.

John

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

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

2017-01-10 Thread Yousong Zhou 
On 10 January 2017 at 18:27, John Crispin  wrote:
> correct, which is why we tend to add subsystem and lib stuff using
> AutoLoad and the rest using AutoProbe

I think the problem with wireguard in github issue 3790 [1] is that
wireguard requires NFPROTO_{IPV4,IPV6} "hashlimit" module and
netfilter subsystem will try to load ipt_hashlimit and ip6t_hashlimit
which are aliases of xt_hashlimit, but we have aliases along with
other modinfoinfo stripped from kernel modules with patch
204-module_strip.patch.

It looks to me mod aliases are essential part of the module info in
this case . What do you think about restoring them by patching the
204.xxx.patch?

[1] https://github.com/openwrt/packages/issues/3790

yousong

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

Re: [LEDE-DEV] [PATCH] wpa_supplicant: Fix mesh encryption config

2017-01-10 Thread Stijn Tintel 
On 10-01-17 11:22, Sujith wrote:
> wpa_supplicant allows only SAE as the key management
> type for mesh mode. The recent key_mgmt rework unconditionally
> added WPA-PSK - this breaks interface bringup and wpa_s
> throws this error message:
>
> Line 10: key_mgmt for mesh network should be open or SAE
> Line 10: failed to parse network block.
> Failed to read or parse configuration '/var/run/wpa_supplicant-wlan0.conf
Sorry about that.
>
> Fix this by making sure that only SAE is used for mesh.
>
> Signed-off-by: Sujith 
Please use your full name in SoB.

Thanks,
Stijn

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

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

2017-01-10 Thread John Crispin 


On 10/01/2017 10:53, Zefir Kurtisi wrote:
> On 01/10/2017 09:20 AM, John Crispin wrote:
>>
>>
>> On 10/01/2017 09:17, Baptiste Jonglez wrote:
>>> On Tue, Jan 10, 2017 at 07:56:36AM +0100, John Crispin wrote:
>> While investigating an issue with module loading order¹, I discovered
>> that
>> some kernel packages use AutoProbe, like this:
>>
>>  AUTOLOAD:=$(call AutoProbe,xt_hashlimit)
>>
>> while some kernel packages use the AutoLoad helper I was used to, with a
>> priority:
>>
>>  AUTOLOAD:=$(call AutoLoad,28,raid0)
>>
>> Judging from this commit² and `include/kernel.mk`, it seems the only
>> difference is that AutoProbe does not include a priority.
>>
>> Is the loading order determined automatically for AutoProbe?  If so,
>> where
>> is the magic, and why is AutoLoad still needed in some cases?
>
> I opened the issue, so using autoload the modules will get a priority
> specified by the number, for wireguard above 90 would issue only one
> warning and using autoprobe the module would be loaded by the order of
> the name ? so setting the xt_hashlimit with a lower number (autoload)
> will start wireguard without complaining
>

 autoload is like insmod while autoproe is more liek modprobe. kmodloader
 will first load all numbered modules in the given order and then probe
 the remaining ones.
>>>
>>> So, with AutoProbe, there is dependency resolution, similarly to modprobe?
>>> But without using depmod?
>>>
>>
>> correct. kmodloader will scan the ELF header and work out which other
>> modules are required to be loaded. depmod caches this dependency info
>> while kmodloader generates it when needed.
>>
>>  John
>>
> Worth to note that only explicit dependencies are resolved, i.e. if one ko 
> uses
> another ko (like ath9k -> ath9k_common). It obviously does not (and can't) 
> work if
> one subsystem makes use of a component in another subsystem.
> 
> Let me share a recent experience for illustration and amusement. I had to 
> debug a
> system where a gianfar ETH driver connects to an at803x PHY driver. 
> Approaching
> the problem the usual printk based technique, I ended up in a situation where
> printing a string of size n in gianfar made the system work, while reducing 
> the
> length of the printed string to (n-1) did not. Realizing that prink-ing random
> chars might not be the correct fix for the issue, I was wondering wtf!?
> 
> Turned out problem was caused by the kernel module autoloader. While the PHY 
> and
> ETH driver were loaded and initialized in the background, the additional 
> printk
> caused enough delay to allow the PHY to finish registration before the ETH
> attaches to it. If otherwise the ETH attaches to an enumerated PHY on the bus
> whose driver did not yet finalize its registration, it gets attach to genphy.
> Since everything works more or less, you won't notice unless you look for 
> printk
> output - which itself changes measures :\
> 
> 
> Lesson learned: autoprobe is convenient, but if you need to ensure lower layer
> drivers are loaded before upper layer ones, use autoload.

correct, which is why we tend to add subsystem and lib stuff using
AutoLoad and the rest using AutoProbe

John

> 
> NOTE: Since module initialization / registration still happens in the 
> background,
> this might not prevent from the effect described above from happening (e.g. in
> case you delay PHY registration long enough with printk), but at least it 
> gives
> you some control for spreading the loading of dependent modules.
> 
> 
> Cheers,
> Zefir
> 

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

[LEDE-DEV] [PATCH] wpa_supplicant: Fix mesh encryption config

2017-01-10 Thread Sujith 
wpa_supplicant allows only SAE as the key management
type for mesh mode. The recent key_mgmt rework unconditionally
added WPA-PSK - this breaks interface bringup and wpa_s
throws this error message:

Line 10: key_mgmt for mesh network should be open or SAE
Line 10: failed to parse network block.
Failed to read or parse configuration '/var/run/wpa_supplicant-wlan0.conf

Fix this by making sure that only SAE is used for mesh.

Signed-off-by: Sujith 
---
 package/network/services/hostapd/files/netifd.sh | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/netifd.sh 
b/package/network/services/hostapd/files/netifd.sh
index a7a6a64e7a..fb23e52e67 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -617,7 +617,10 @@ wpa_supplicant_add_network() {
psk)
local passphrase
 
-   hostapd_append_wpa_key_mgmt
+   if [ "$_w_mode" != "mesh" ]; then
+   hostapd_append_wpa_key_mgmt
+   fi
+
key_mgmt="$wpa_key_mgmt"
 
if [ ${#key} -eq 64 ]; then
-- 
2.11.0


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

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

2017-01-10 Thread Zefir Kurtisi 
On 01/10/2017 09:20 AM, John Crispin wrote:
> 
>
> On 10/01/2017 09:17, Baptiste Jonglez wrote:
>> On Tue, Jan 10, 2017 at 07:56:36AM +0100, John Crispin wrote:
> While investigating an issue with module loading order¹, I discovered
> that
> some kernel packages use AutoProbe, like this:
>
>  AUTOLOAD:=$(call AutoProbe,xt_hashlimit)
>
> while some kernel packages use the AutoLoad helper I was used to, with a
> priority:
>
>  AUTOLOAD:=$(call AutoLoad,28,raid0)
>
> Judging from this commit² and `include/kernel.mk`, it seems the only
> difference is that AutoProbe does not include a priority.
>
> Is the loading order determined automatically for AutoProbe?  If so,
> where
> is the magic, and why is AutoLoad still needed in some cases?

 I opened the issue, so using autoload the modules will get a priority
 specified by the number, for wireguard above 90 would issue only one
 warning and using autoprobe the module would be loaded by the order of
 the name ? so setting the xt_hashlimit with a lower number (autoload)
 will start wireguard without complaining

>>>
>>> autoload is like insmod while autoproe is more liek modprobe. kmodloader
>>> will first load all numbered modules in the given order and then probe
>>> the remaining ones.
>>
>> So, with AutoProbe, there is dependency resolution, similarly to modprobe?
>> But without using depmod?
>>
> 
> correct. kmodloader will scan the ELF header and work out which other
> modules are required to be loaded. depmod caches this dependency info
> while kmodloader generates it when needed.
> 
>   John
> 
Worth to note that only explicit dependencies are resolved, i.e. if one ko uses
another ko (like ath9k -> ath9k_common). It obviously does not (and can't) work 
if
one subsystem makes use of a component in another subsystem.

Let me share a recent experience for illustration and amusement. I had to debug 
a
system where a gianfar ETH driver connects to an at803x PHY driver. Approaching
the problem the usual printk based technique, I ended up in a situation where
printing a string of size n in gianfar made the system work, while reducing the
length of the printed string to (n-1) did not. Realizing that prink-ing random
chars might not be the correct fix for the issue, I was wondering wtf!?

Turned out problem was caused by the kernel module autoloader. While the PHY and
ETH driver were loaded and initialized in the background, the additional printk
caused enough delay to allow the PHY to finish registration before the ETH
attaches to it. If otherwise the ETH attaches to an enumerated PHY on the bus
whose driver did not yet finalize its registration, it gets attach to genphy.
Since everything works more or less, you won't notice unless you look for printk
output - which itself changes measures :\


Lesson learned: autoprobe is convenient, but if you need to ensure lower layer
drivers are loaded before upper layer ones, use autoload.

NOTE: Since module initialization / registration still happens in the 
background,
this might not prevent from the effect described above from happening (e.g. in
case you delay PHY registration long enough with printk), but at least it gives
you some control for spreading the loading of dependent modules.


Cheers,
Zefir

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

[LEDE-DEV] [PATCHv2] ar71xx: add support for PQI Air Pen

2017-01-10 Thread YuheiOKAWA 
SoC: AR9331
Ethernet x1, Wireless 2.4G, uSD card slot x1.
USB Power, include Li-Po Battery.

Signed-off-by: YuheiOKAWA 

Changes in v2:
alphabetical ordering, tabs fron spaces.
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds |  4 +
 .../linux/ar71xx/base-files/etc/board.d/02_network |  1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |  3 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |  1 +
 target/linux/ar71xx/config-4.4 |  1 +
 .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   | 10 +++
 target/linux/ar71xx/files/arch/mips/ath79/Makefile |  1 +
 .../files/arch/mips/ath79/mach-pqi-air-pen.c   | 99 ++
 .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |  1 +
 target/linux/ar71xx/image/generic.mk   | 11 +++
 10 files changed, 132 insertions(+)
 create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-pqi-air-pen.c

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 5a2bf0c..14d9b3c 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -427,6 +427,10 @@ omy-x1)
ucidef_set_led_default "power" "POWER" "omy:green:power" "1"
ucidef_set_led_default "wan" "WAN" "omy:green:wan" "eth0"
;;
+pqi-air-pen)
+   ucidef_set_led_wlan "wlan" "WLAN" "pqi-air-pen:blue:wlan" "phy0tpt"
+   ucidef_set_led_default "wps" "WPS" "pqi-air-pen:blue:wps" "0"
+   ;;
 qihoo-c301)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "qihoo:red:status" "phy1tpt"
;;
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 66274db..89ab6f5 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -83,6 +83,7 @@ ar71xx_setup_interfaces()
mr900|\
mr900v2|\
mynet-rext|\
+   pqi-air-pen|\
rb-411|\
rb-911g-2hpnd|\
rb-911g-5hpacd|\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 1b30f4d..33925eb 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -775,6 +775,9 @@ ar71xx_board_detect() {
*"PB44 reference board")
name="pb44"
;;
+   *"PQI Air Pen")
+   name="pqi-air-pen"
+   ;;
*"Qihoo 360 C301")
name="qihoo-c301"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 6341a31..c232ea9 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -222,6 +222,7 @@ platform_check_image() {
nanostation-m-xw|\
nanostation-m|\
nbg460n_550n_550nh|\
+   pqi-air-pen|\
rocket-m-ti|\
rocket-m-xw|\
rocket-m|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 4b2f736..129af79 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -136,6 +136,7 @@ CONFIG_ATH79_MACH_OMY_X1=y
 CONFIG_ATH79_MACH_ONION_OMEGA=y
 CONFIG_ATH79_MACH_PB42=y
 CONFIG_ATH79_MACH_PB44=y
+CONFIG_ATH79_MACH_PQI_AIR_PEN=y
 CONFIG_ATH79_MACH_QIHOO_C301=y
 CONFIG_ATH79_MACH_R6100=y
 # CONFIG_ATH79_MACH_RB2011 is not set
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt 
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 21d6b51..34042d0 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -243,6 +243,16 @@ config ATH79_MACH_ESR1750
select ATH79_DEV_USB
select ATH79_DEV_WMAC
 
+config ATH79_MACH_PQI_AIR_PEN
+   bool "PQI Air Pen"
+   select SOC_AR933X
+   select ATH79_DEV_ETH
+   select ATH79_DEV_GPIO_BUTTONS
+   select ATH79_DEV_LEDS_GPIO
+   select ATH79_DEV_M25P80
+   select ATH79_DEV_USB
+   select ATH79_DEV_WMAC
+
 config ATH79_MACH_SOM9331
bool "SOM9331 support"
select SOC_AR933X
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile 
b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
index 6384c06..e0bac16 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
@@ -140,6 +140,7 @@ obj-$(CONFIG_ATH79_MACH_OMY_X1) += 
mach-omy-x1.o
 obj-$(CONFIG_ATH79_MACH_ONION_OMEGA)   += mach-onion-omega.o
 obj-$(CONFIG_ATH79_MACH_PB42)  += mach-pb42.o
 obj-$(CONFIG_ATH79_MACH_PB44)  += mach-pb44.o
+obj-$(CONFIG_ATH79_MACH_PQI_AIR_PEN)   += mach-pqi-air-pen.o
 obj-$(CONFIG_ATH79_MACH_QIHOO_C301)+=

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

2017-01-10 Thread John Crispin 


On 10/01/2017 09:17, Baptiste Jonglez wrote:
> On Tue, Jan 10, 2017 at 07:56:36AM +0100, John Crispin wrote:
 While investigating an issue with module loading order¹, I discovered
 that
 some kernel packages use AutoProbe, like this:

  AUTOLOAD:=$(call AutoProbe,xt_hashlimit)

 while some kernel packages use the AutoLoad helper I was used to, with a
 priority:

  AUTOLOAD:=$(call AutoLoad,28,raid0)

 Judging from this commit² and `include/kernel.mk`, it seems the only
 difference is that AutoProbe does not include a priority.

 Is the loading order determined automatically for AutoProbe?  If so,
 where
 is the magic, and why is AutoLoad still needed in some cases?
>>>
>>> I opened the issue, so using autoload the modules will get a priority
>>> specified by the number, for wireguard above 90 would issue only one
>>> warning and using autoprobe the module would be loaded by the order of
>>> the name ? so setting the xt_hashlimit with a lower number (autoload)
>>> will start wireguard without complaining
>>>
>>
>> autoload is like insmod while autoproe is more liek modprobe. kmodloader
>> will first load all numbered modules in the given order and then probe
>> the remaining ones.
> 
> So, with AutoProbe, there is dependency resolution, similarly to modprobe?
> But without using depmod?
> 

correct. kmodloader will scan the ELF header and work out which other
modules are required to be loaded. depmod caches this dependency info
while kmodloader generates it when needed.

John

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

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

2017-01-10 Thread Jo-Philipp Wich 
Hi Baptiste,

> So, with AutoProbe, there is dependency resolution, similarly to modprobe?
> But without using depmod?

Exactly.

~ Jo



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

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

2017-01-10 Thread Baptiste Jonglez 
On Tue, Jan 10, 2017 at 07:56:36AM +0100, John Crispin wrote:
> >> While investigating an issue with module loading order¹, I discovered
> >> that
> >> some kernel packages use AutoProbe, like this:
> >>
> >>  AUTOLOAD:=$(call AutoProbe,xt_hashlimit)
> >>
> >> while some kernel packages use the AutoLoad helper I was used to, with a
> >> priority:
> >>
> >>  AUTOLOAD:=$(call AutoLoad,28,raid0)
> >>
> >> Judging from this commit² and `include/kernel.mk`, it seems the only
> >> difference is that AutoProbe does not include a priority.
> >>
> >> Is the loading order determined automatically for AutoProbe?  If so,
> >> where
> >> is the magic, and why is AutoLoad still needed in some cases?
> > 
> > I opened the issue, so using autoload the modules will get a priority
> > specified by the number, for wireguard above 90 would issue only one
> > warning and using autoprobe the module would be loaded by the order of
> > the name ? so setting the xt_hashlimit with a lower number (autoload)
> > will start wireguard without complaining
> > 
> 
> autoload is like insmod while autoproe is more liek modprobe. kmodloader
> will first load all numbered modules in the given order and then probe
> the remaining ones.

So, with AutoProbe, there is dependency resolution, similarly to modprobe?
But without using depmod?


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] [PATCH v2] Curl: fix HTTPS network timeouts with OpenSSL

2017-01-10 Thread John Crispin 
Hi,

On 08/01/2017 15:29, Stijn Segers wrote:
> Fixes HTTPS timeouts with OpenSSL. Upstream curl bug #1174.
> 
> Upstream commit message:
> 
> Fixed an old leftover use of the USE_SSLEAY define which would make a
> socket get removed from the applications sockets to monitor when the
> multi_socket API was used, leading to timeouts.
> 
> Signed-off-by: Stijn Segers 
> ---
>  .../curl/patches/320-curl-https-openssl-fix.patch  | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 
> package/network/utils/curl/patches/320-curl-https-openssl-fix.patch
> 


it looks like you only added the patch body. if this is an upstream
comit, then please add the fully annotated upstream patch.

John

> diff --git 
> a/package/network/utils/curl/patches/320-curl-https-openssl-fix.patch 
> b/package/network/utils/curl/patches/320-curl-https-openssl-fix.patch
> new file mode 100644
> index 00..9ecb2a95f8
> --- /dev/null
> +++ b/package/network/utils/curl/patches/320-curl-https-openssl-fix.patch
> @@ -0,0 +1,22 @@
> +diff --git a/lib/vtls/vtls.c b/lib/vtls/vtls.c
> +index b808e1c..707f24b 100644
> +--- a/lib/vtls/vtls.c
>  b/lib/vtls/vtls.c
> +@@ -484,7 +484,7 @@ void Curl_ssl_close_all(struct Curl_easy *data)
> +   curlssl_close_all(data);
> + }
> + 
> +-#if defined(USE_SSLEAY) || defined(USE_GNUTLS) || defined(USE_SCHANNEL) || \
> ++#if defined(USE_OPENSSL) || defined(USE_GNUTLS) || defined(USE_SCHANNEL) || 
> \
> + defined(USE_DARWINSSL) || defined(USE_NSS)
> + /* This function is for OpenSSL, GnuTLS, darwinssl, and schannel only. */
> + int Curl_ssl_getsock(struct connectdata *conn, curl_socket_t *socks,
> +@@ -518,7 +518,7 @@ int Curl_ssl_getsock(struct connectdata *conn,
> +   (void)numsocks;
> +   return GETSOCK_BLANK;
> + }
> +-/* USE_SSLEAY || USE_GNUTLS || USE_SCHANNEL || USE_DARWINSSL || USE_NSS */
> ++/* USE_OPENSSL || USE_GNUTLS || USE_SCHANNEL || USE_DARWINSSL || USE_NSS */
> + #endif
> + 
> + void Curl_ssl_close(struct connectdata *conn, int sockindex)
> 

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

Re: [LEDE-DEV] [PATCH] ar71xx: add support for PQI Air Pen

2017-01-10 Thread John Crispin 
Hi,

comments inline

On 09/01/2017 02:41, YuheiOKAWA wrote:
> SoC: AR9331
> Ethernet x1, Wireless 2.4G, uSD card slot x1.
> USB Power, include Li-Po Battery.
> 

could be a bit more verbose here

> Signed-off-by: YuheiOKAWA 
> ---
>  target/linux/ar71xx/base-files/etc/board.d/01_leds |  4 +
>  .../linux/ar71xx/base-files/etc/board.d/02_network |  1 +
>  target/linux/ar71xx/base-files/lib/ar71xx.sh   |  3 +
>  .../ar71xx/base-files/lib/upgrade/platform.sh  |  1 +
>  target/linux/ar71xx/config-4.4 |  1 +
>  .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   | 10 +++
>  target/linux/ar71xx/files/arch/mips/ath79/Makefile |  1 +
>  .../files/arch/mips/ath79/mach-pqi-air-pen.c   | 99 
> ++
>  .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |  1 +
>  target/linux/ar71xx/image/generic.mk   | 10 +++
>  10 files changed, 131 insertions(+)
>  create mode 100644 
> target/linux/ar71xx/files/arch/mips/ath79/mach-pqi-air-pen.c
> 
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
> b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> index 5a2bf0c..14d9b3c 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> @@ -427,6 +427,10 @@ omy-x1)
>   ucidef_set_led_default "power" "POWER" "omy:green:power" "1"
>   ucidef_set_led_default "wan" "WAN" "omy:green:wan" "eth0"
>   ;;
> +pqi-air-pen)
> + ucidef_set_led_wlan "wlan" "WLAN" "pqi-air-pen:blue:wlan" "phy0tpt"
> + ucidef_set_led_default "wps" "WPS" "pqi-air-pen:blue:wps" "0"
> + ;;
>  qihoo-c301)
>   ucidef_set_led_wlan "wlan2g" "WLAN2G" "qihoo:red:status" "phy1tpt"
>   ;;
[...]

> diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
> index 4b2f736..129af79 100644
> --- a/target/linux/ar71xx/config-4.4
> +++ b/target/linux/ar71xx/config-4.4
> @@ -136,6 +136,7 @@ CONFIG_ATH79_MACH_OMY_X1=y
>  CONFIG_ATH79_MACH_ONION_OMEGA=y
>  CONFIG_ATH79_MACH_PB42=y
>  CONFIG_ATH79_MACH_PB44=y
> +CONFIG_ATH79_MACH_PQI_AIR_PEN=y
>  CONFIG_ATH79_MACH_QIHOO_C301=y
>  CONFIG_ATH79_MACH_R6100=y
>  # CONFIG_ATH79_MACH_RB2011 is not set
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt 
> b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> index 21d6b51..902a7e9 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> @@ -1734,6 +1734,16 @@ config ATH79_MACH_CARAMBOLA2
>   select ATH79_DEV_USB
>   select ATH79_DEV_WMAC
>  
> +config ATH79_MACH_PQI_AIR_PEN

alphabetical ordering is wrong

> + bool "PQI Air Pen"
> + select SOC_AR933X
> + select ATH79_DEV_ETH
> + select ATH79_DEV_GPIO_BUTTONS
> + select ATH79_DEV_LEDS_GPIO
> + select ATH79_DEV_M25P80
> + select ATH79_DEV_USB
> + select ATH79_DEV_WMAC
> +
>  config ATH79_MACH_CF_E316N_V2
>   bool "COMFAST CF-E316N v2 support"
>   select SOC_AR934X
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile 
> b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
> index 6384c06..2280483 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
> @@ -65,6 +65,7 @@ obj-$(CONFIG_ATH79_MACH_C60)+= 
> mach-c60.o
>  obj-$(CONFIG_ATH79_MACH_CAP324)  += mach-cap324.o
>  obj-$(CONFIG_ATH79_MACH_CAP4200AG)   += mach-cap4200ag.o
>  obj-$(CONFIG_ATH79_MACH_CARAMBOLA2)  += mach-carambola2.o
> +obj-$(CONFIG_ATH79_MACH_PQI_AIR_PEN) += mach-pqi-air-pen.o


alphabetical ordering is wrong

>  obj-$(CONFIG_ATH79_MACH_CF_E316N_V2) += mach-cf-e316n-v2.o
>  obj-$(CONFIG_ATH79_MACH_CF_E320N_V2) += mach-cf-e316n-v2.o
>  obj-$(CONFIG_ATH79_MACH_CF_E380AC_V1)+= mach-cf-e316n-v2.o
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-pqi-air-pen.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-pqi-air-pen.c
> new file mode 100644
> index 000..f8803c4
> --- /dev/null
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-pqi-air-pen.c
> @@ -0,0 +1,99 @@
> +/*
> + *  PQI Air Pen stick support
> + *
> + *  Copyright (C) 2016 YuheiOKAWA 
> + *
> + *  This program is free software; you can redistribute it and/or modify it
> + *  under the terms of the GNU General Public License version 2 as published
> + *  by the Free Software Foundation.
> +*/
> +
> +#include 
> +
> +#include 
> +
> +#include "common.h"
> +#include "dev-eth.h"
> +#include "dev-gpio-buttons.h"
> +#include "dev-leds-gpio.h"
> +#include "dev-m25p80.h"
> +#include "dev-usb.h"
> +#include "dev-wmac.h"
> +#include "machtypes.h"
> +
> +#define PQI_AIR_PEN_GPIO_LED_WLAN0
> +#define PQI_AIR_PEN_GPIO_LED_WPS 23
> +
> +#define PQI_AIR_PEN_GPIO_BTN_WPS 22
> +#define