Re: [LEDE-DEV] Makefile question

[Yousong Zhou]

On 14 February 2017 at 10:51, Philip Prindeville
 wrote:
>
>> On Feb 12, 2017, at 10:04 PM, Yousong Zhou  wrote:
>>
>> On 13 February 2017 at 11:23, Philip Prindeville
>>  wrote:
>>>
 On Feb 11, 2017, at 8:29 PM, David Lang  wrote:

 On Sat, 11 Feb 2017, Philip Prindeville wrote:

>> This can't eliminate the /etc/rc.d/S* files as it only adds files, and 
>> it's not as flexibile as adding a user or changing a password (as it 
>> would just let you replace the /etc/passwd, /etc/shadow files, not 
>> modify them).
>>
>> If you look for where the /files/* are copied into the filesystem, that 
>> is probably the place you would want to add your scripting hooks.
>
> Good idea.  I’ll look there.

 Once you find this, may I suggest that you create /scripts/* and 
 contribute the infrastructure to support it back upstream?

 I have seen a lot of people wanting to do similar things.
>>>
>>>
>>> Surprisingly, I’m still trying to find in the Makefiles where 
>>> $(topdir)/files/ gets copied over…
>>>
>>> -Philip
>>
>> It's prepare_rootfs doing this job at the moment.
>>
>>yousong
>
>
> Hi Yousong,
>
> I’ve been working on both OpenWRT and LEDE and needed to get some hooks 
> working in OpenWRT so I focused on that first.
>
> These are the changes I made, but I couldn’t get it to work.
>
> Was wondering if anyone can run with this.
>
> Part of the problem is making package/Makefile recurse with additional 
> arguments and a different working directory…  When I try to do this, the 
> submake of package/Makefile gets run without inherited variables like 
> $(INCLUDE_DIR), etc.

package/Makefile was included by $(TOPDIR)/Makefile which included
$(TOPDIR)/rules.mk first and that's where was INCLUDE_DIR defined but
not exported.

>
> Also odd is even though the top of package/Makefile says:
>
> curdir:=package
>
> when it recurses $(curdir) retains some other value like “target” or 
> “toolchain”.  Not sure why.
>

No idea how this happened as I do not yet have time to check the patch
in details.  Does it take these values in a random way?

The other thing is if it's just about pre/post hooks, then I guess the
Build/IncludeOverlay mechanism should already fulfil most (if not all)
of your needs.

yousong

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

[LEDE-DEV] 17.01-rc2 install on wrt1200ac

[John Ricardo]

I just updated from openwrt 15.05.01 to lede 17.01-rc2 on my WRT1200AC.  The 
update went well but you can't keep your settings.  Once I unchecked the keep 
settings option the update worked great.  In the few minutes I have been using 
it the wifi is much better than openwrt.  Before my android would take about 5 
seconds to connect and occasionally drop and reconnect to the router.  Now my 
phone connects in a second and it seems more reliable.  Please keep up the good 
work. 

Now if I can lede on my mikrotik and IPv6 working I would be a very a happy 
person.

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

[LEDE-DEV] [PATCH mdns] Set TTL to 255 for outgoing IPv4 unicast packets

[Rafał Miłecki]

From: Rafał Miłecki 

1) We SHOULD do this according to the RFC 6762 (Section 11, "Source
   Address Check").
2) We already do it for IPv6 unicast and both multicast interfaces
3) When receiving IPv4 packet we ignore it if TTL doesn't equal 255

In other words this fixes unicast communication between 2 umdns
instances.

Signed-off-by: Rafał Miłecki 
---
 interface.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/interface.c b/interface.c
index 587b188..76820c7 100644
--- a/interface.c
+++ b/interface.c
@@ -389,6 +389,7 @@ static void
 reconnect_socket4(struct uloop_timeout *timeout)
 {
struct interface *iface = container_of(timeout, struct interface, 
reconnect);
+   int ttl = 255;
int yes = 1;
 
iface->fd.fd = usock(USOCK_UDP | USOCK_SERVER | USOCK_NONBLOCK | 
USOCK_IPV4ONLY,
@@ -404,6 +405,9 @@ reconnect_socket4(struct uloop_timeout *timeout)
if (setsockopt(iface->fd.fd, SOL_SOCKET, SO_REUSEADDR, , 
sizeof(yes)) < 0)
fprintf(stderr, "ioctl failed: SO_REUSEADDR\n");
 
+   if (setsockopt(iface->fd.fd, IPPROTO_IP, IP_TTL, , sizeof(ttl)) < 0)
+   fprintf(stderr, "ioctl failed: IP_TTL\n");
+
if (setsockopt(iface->fd.fd, IPPROTO_IP, IP_RECVTTL, , sizeof(yes)) 
< 0)
fprintf(stderr, "ioctl failed: IP_RECVTTL\n");
 
-- 
2.11.0


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

Re: [LEDE-DEV] Lantiq XWAY Linux 4.9 Internal Switch Ports NO-CARRIER

[hamsi2k]

I think I found something interesting (and an workaround):
In 4.4 at the phy_device init there is only set the
http://lxr.free-electrons.com/source/drivers/net/phy/phy_device.c?v=4.4#L669
phydev->state = PHY_READY;

while in 4.9 there is a 
http://lxr.free-electrons.com/source/drivers/net/phy/phy_device.c#L911
/* Initial carrier state is off as the phy is about to be
* (re)initialized.
*/netif_carrier_off(phydev->attached_dev);call. This explains the behavior and 
after removing this line the network
is working.

But the question is, why the internal phy comes sends no link up event while 
the external port
does this?




---
Die Bundesliga hat begonnen! Alle Tore, alle Ergebnisse, alle News: Pocket Liga 
jetzt im https://app.adjust.com/dpynzd oder https://app.adjust.com/dpynzd 
herunterladen - kostenlos!


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

[LEDE-DEV] [PATCH mdns] Fix sending replies to PTR questions

[Rafał Miłecki]

From: Rafał Miłecki 

When we receive PTR question it includes hostname (instance), e.g.:
mdnsd: parse_question (391): Q -> PTR lede._http._tcp.local

First of all we should check if it matches hostname we use before trying
to reply. Secondly service_reply expects service with domain appended
(without hostname/instance) so we need to strip received string out of
hostname before passing it.

Signed-off-by: Rafał Miłecki 
---
 dns.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/dns.c b/dns.c
index 91434f2..dac6f2c 100644
--- a/dns.c
+++ b/dns.c
@@ -367,9 +367,19 @@ parse_question(struct interface *iface, char *name, struct 
dns_question *q)
break;
 
case TYPE_PTR:
-   if (!strcmp(name, sdudp))
+   if (!strcmp(name, sdudp)) {
service_announce_services(iface, announce_ttl);
-   service_reply(iface, name, announce_ttl);
+   } else {
+   /* First dot separates instance name from the rest */
+   char *dot = strchr(name, '.');
+   /* Length of queried instance */
+   size_t len = dot ? dot - name : 0;
+
+   /* Make sure it's query for the instance name we use */
+   if (len && len == strlen(mdns_hostname) &&
+   !strncmp(name, mdns_hostname, len))
+   service_reply(iface, dot + 1, announce_ttl);
+   }
break;
 
case TYPE_:
-- 
2.11.0


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

Re: [LEDE-DEV] Working with network namespaces?

[Jeff Ahrenholz]

yanosz,

> Getting back to this:
> IMHO I'd be cool, to set option namespace 'ns4711' for interfaces and
> routes in /etc/config/network.

> Is there anything happening related to network namespaces in lede?

Not sure what else is happening with netns, but I use the following to turn on 
namespace support:

config CORE_KERNEL_OPTIONS
bool "Enable kernel support for containers"
default y
select PACKAGE_lxc
select LXC_KERNEL_OPTIONS
select PACKAGE_veth
select PACKAGE_kmod-veth
help
  Select the LXC_KERNEL_OPTIONS config to enable namespaces support in
  the Linux kernel.

This goes into a custom feed config, turns on LXC options including network 
namespaces. 
I’m using this in conjunction with CORE [1] utilities.

cheers,
-Jeff

1. https://www.nrl.navy.mil/itd/ncs/products/core



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

Re: [LEDE-DEV] [PATCH 2/2] x86: Add board configs for the PC Engines APU2

[David Woodhouse]

On Mon, 2017-02-13 at 12:50 +0100, Felix Fietkau wrote:
> 
> Please leave out the /lib/.sh anti-pattern. Just use
> /tmp/sysinfo/board_name directly or (even better) introduce a generic
> function for getting the board name.

Once I stop /etc/diag.sh from having hard-coded board name stuff, we go
back to only one instance of reading /tmp/sysinfo/board_name — so I
dropped that part from https://github.com/lede-project/source/pull/824

Testing seems to show that the diag LED only really works from the
second boot though, since it isn't *configured* during the first boot.


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

Re: [LEDE-DEV] [PATCH 2/2] x86: Add board configs for the PC Engines APU2

[Felix Fietkau]

On 2017-02-13 09:01, Chris Blake wrote:
> This adds the default LED and network settings for the PC Engines APU2
> when running under the x86 target.
> 
> Signed-off-by: Chris Blake 
> ---
>  target/linux/x86/base-files/etc/board.d/01_leds|  7 +++-
>  target/linux/x86/base-files/etc/board.d/02_network |  7 +++-
>  target/linux/x86/base-files/etc/diag.sh| 37 
> ++
>  target/linux/x86/base-files/lib/x86.sh | 13 
>  4 files changed, 62 insertions(+), 2 deletions(-)
>  create mode 100755 target/linux/x86/base-files/etc/diag.sh
>  create mode 100755 target/linux/x86/base-files/lib/x86.sh
> 
> diff --git a/target/linux/x86/base-files/lib/x86.sh 
> b/target/linux/x86/base-files/lib/x86.sh
> new file mode 100755
> index 000..40e4d1f
> --- /dev/null
> +++ b/target/linux/x86/base-files/lib/x86.sh
Please leave out the /lib/.sh anti-pattern. Just use
/tmp/sysinfo/board_name directly or (even better) introduce a generic
function for getting the board name.

- Felix

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

Re: [LEDE-DEV] [PATCH 2/2] x86: Add board configs for the PC Engines APU2

[David Woodhouse]

On Mon, 2017-02-13 at 02:01 -0600, Chris Blake wrote:
> 
> +get_status_led() {
> +    case $(x86_board_name) in
> +    pc-engines-apu2)
> +    status_led="apu2:green:power"
> +    ;;
> +    esac
> +}

Ick. Why hard-code that and have board-specific stuff in more than one
place, instead of just configuring it with everything else, then
deferring to the configuration? Can't we do something like this
instead?

diff --git a/target/linux/x86/base-files/etc/diag.sh 
b/target/linux/x86/base-files/etc/diag.sh
index 2426161..c51d080 100755
--- a/target/linux/x86/base-files/etc/diag.sh
+++ b/target/linux/x86/base-files/etc/diag.sh
@@ -3,15 +3,26 @@
 # Copyright © 2017 OpenWrt.org
 #
 
+. /lib/functions.sh
 . /lib/functions/leds.sh
 . /lib/x86.sh
 
+match_diag_led() {
+   local name
+   local default
+   local sysfs
+   config_get name "$1" name
+   config_get default "$1" default
+   config_get sysfs "$1" sysfs
+
+   if [ "$name" = "DIAG" -a "$default" = "1" ]; then
+   status_led="$sysfs"
+   fi
+}
+
 get_status_led() {
-case $(x86_board_name) in
-pc-engines-apu2)
-status_led="apu2:green:power"
-;;
-esac
+   config_load system
+   config_foreach match_diag_led led
 }
 
 set_state() {
diff --git a/target/linux/x86/base-files/etc/board.d/01_leds 
b/target/linux/x86/base-files/etc/board.d/01_leds
index 05ddc71..50eac33 100755
--- a/target/linux/x86/base-files/etc/board.d/01_leds
+++ b/target/linux/x86/base-files/etc/board.d/01_leds
@@ -14,11 +14,12 @@ case "$board" in
 pc-engines-apu2)
    ucidef_set_led_netdev "wan" "WAN" "apu2:green:led3" "eth0"
    ucidef_set_led_netdev "lan" "LAN" "apu2:green:led2" "eth1"
+   ucidef_set_led_default "diag" "DIAG" "apu2:green:power" "1"
    ;;
 traverse-technologies-geos)
    ucidef_set_led_netdev "lan" "LAN" "geos:1" "br-lan" "tx rx"
    ucidef_set_led_netdev "wlan" "WiFi" "geos:2" "phy0tpt"
-   ucidef_set_led_default "diag" "DIAG" "geos:3" "0"
+   ucidef_set_led_default "diag" "DIAG" "geos:3" "1"
    ;;
 esac
 board_config_flush


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

Re: [LEDE-DEV] [PATCH] sdk: Fix src-git URL for the base feed when on a detached commit (FS#501)

[Karl Palsson]

Baptiste Jonglez  wrote:
> From: Baptiste Jonglez 
> 
> When the source repository is on a detached commit (such as
> when building a release tag), the git URL for the "base" feed
> is incorrect in the SDK.
> 
> Before this commit:
> 
>   On branch "master":  src-git base git://git.lede-project.org/source
>   On branch "lede-17.01":  src-git base 
> git://git.lede-project.org/source;lede-17.01
>   On tag "v17.01.0-rc2":   src-git base 
> git://git.lede-project.org/source;HEAD  <-- incorrect
> 
> After this commit:
> 
>   On branch "master":  src-git base 
> git://git.lede-project.org/source;master
>   On branch "lede-17.01":  src-git base 
> git://git.lede-project.org/source;lede-17.01
>   On tag "v17.01.0-rc2":   src-git base 
> git://git.lede-project.org/source^28b7d7f1dac725157c19236b8899e1c97f19cee9

I'd prefer if you could make it...

On tag "v17.01.0-rc2": src-git base
git://git.lede-project.org/source;v17.01.0-rc2

rather than the hash. Tags work just fine there, I've been using
that locally for my own tags, and it's much "nicer" than just the
hash.

Cheers,
Karl P


> 
> Notice that the "master" branch is now explicitly expanded:
> this is just to simplify the new code.
> 
> Signed-off-by: Baptiste Jonglez 
> ---
>  target/sdk/Makefile | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/target/sdk/Makefile b/target/sdk/Makefile index
> 719b659d25..34755b2096 100644
> --- a/target/sdk/Makefile
> +++ b/target/sdk/Makefile
> @@ -38,9 +38,10 @@ SDK_DIRS = \
>   $(STAGING_SUBDIR_TOOLCHAIN)
>  
>  GIT_URL:=$(filter git://% http://% https://%,$(shell git config --get 
> remote.origin.url 2>/dev/null))
> -GIT_BRANCH:=$(filter-out master,$(shell git rev-parse
> --abbrev-ref HEAD 2>/dev/null)) +GIT_BRANCH:=$(filter-out
> HEAD,$(shell git rev-parse --abbrev-ref HEAD 2>/dev/null))
> +GIT_DETACHED_COMMIT:=$(shell git rev-parse HEAD 2>/dev/null)
>  
> -BASE_FEED:=$(if $(GIT_URL),src-git base $(GIT_URL)$(if
> $(GIT_BRANCH),;$(GIT_BRANCH))) +BASE_FEED:=$(if
> $(GIT_URL),src-git base $(GIT_URL)$(if
> $(GIT_BRANCH),;$(GIT_BRANCH),^$(GIT_DETACHED_COMMIT)))
>  BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),$(shell cd $(TOPDIR); LC_ALL=C git 
> svn info 2>/dev/null | sed -ne 's/^URL: /src-gitsvn base /p'))
>  BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),$(shell cd $(TOPDIR); LC_ALL=C svn 
> info 2>/dev/null | sed -ne 's/^URL: /src-svn base /p'))
>  BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),src-git base 
> https://git.lede-project.org/source.git$(if $(GIT_BRANCH),;$(GIT_BRANCH)))
> -- 
> 2.11.1
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

Re: [LEDE-DEV] [PATCH mdns] Set TTL to the new value when updating cached service entry

[John Crispin]

On 13/02/2017 08:43, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> In the simplest case host may change TTL to some different value. It's
> the most important for the goodbye packets though.
> 
> Consider situation when host (for which we have no no cached entries)
> restarts. First it sends goodbye with TTL 0 (we cache it), then seconds
> later it announces with standard TTL values (but we keep TTL 0).
> It results in wrong cache state and could cause dropping valid entries.
> 
> Signed-off-by: Rafał Miłecki 

Hi Rafał

its getting cumbersome so here is a wildcard ...

Acked-by: John Crispin 

feel free to automatically add this to your mdns patches after a grace
period of 24 hours. i will continue to review the patches and if i see
anything will opt-out.

John



> ---
>  cache.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/cache.c b/cache.c
> index fa32465..6bf0d26 100644
> --- a/cache.c
> +++ b/cache.c
> @@ -143,6 +143,7 @@ cache_service(struct interface *iface, char *entry, int 
> hlen, int ttl)
>   if (!strcmp(s->entry, entry)) {
>   s->refresh = 50;
>   s->time = monotonic_time();
> + s->ttl = ttl;
>   return s;
>   }
>  
> 

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

[LEDE-DEV] Please test on your lantiq-Device: chan_lantiq | Patch from Stefan Koch is working

[Dennis Schneck]

 
Hello,
many thanks to Stefan Koch, i made a Patch for lantiq ( chan_lantiq ) for 
Asterisk.
https://forum.openwrt.org/viewtopic.php?id=62696

o26431-vmmc_v3.tar.gz
 
I got build a Image for a VGV7510KW22 / o2 6431 with Astersik 13.x with LEDE 
v17.01 rc2
can do a dial out with mein Provider: sipgate.
 
Can somebody do tests with this Patch too on lantiq-Device(s), and inform 
Stefan.
 
Thanks
Dennis
 

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

[LEDE-DEV] [PATCH 1/2] x86: Move Traverse Geos configs into x86 base-files

[Chris Blake]

This change moves the files in 657418d to the root of the x86 target.
This is done in preperation for adding more devices under other
subtargets.

CC: David Woodhouse 

Signed-off-by: Chris Blake 
---
 target/linux/x86/{geode => }/base-files/etc/board.d/01_leds| 0
 target/linux/x86/{geode => }/base-files/etc/board.d/02_network | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename target/linux/x86/{geode => }/base-files/etc/board.d/01_leds (100%)
 rename target/linux/x86/{geode => }/base-files/etc/board.d/02_network (100%)

diff --git a/target/linux/x86/geode/base-files/etc/board.d/01_leds 
b/target/linux/x86/base-files/etc/board.d/01_leds
similarity index 100%
rename from target/linux/x86/geode/base-files/etc/board.d/01_leds
rename to target/linux/x86/base-files/etc/board.d/01_leds
diff --git a/target/linux/x86/geode/base-files/etc/board.d/02_network 
b/target/linux/x86/base-files/etc/board.d/02_network
similarity index 100%
rename from target/linux/x86/geode/base-files/etc/board.d/02_network
rename to target/linux/x86/base-files/etc/board.d/02_network
-- 
2.7.4


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