[LEDE-DEV] [PATCH] mac80211: Fix race condition leading to wifi interfaces not coming up at boot sometimes.

[Vittorio Gambaletta (VittGam)]

In the drv_mac80211_setup function, mac80211_interface_cleanup
is called to ask the kernel to delete all existing interfaces
for the phy that is being configured via netlink.

Later in the first function, mac80211_prepare_vif is called to
set up the new interfaces as required.

But sometimes, when mac80211_prepare_vif (and so the relevant
`iw phy x interface add y` command) runs, the kernel might still
be cleaning up the old interface with the same ifname. It usually
takes very few time to do that; possibly a few milliseconds of
sleep in the script after detecting this error condition could be
enough, but the busybox sh does not support sub-second sleep
intervals.

When this happens, iw obviously fails to create the new interface;
and the following message is printed in the system log, followed by
subsequent failure messages from hostapd in case this would have been
an AP interface.

Tue Mar 14 04:21:57 2017 daemon.notice netifd: radio1 (2767): command failed: 
Too many open files in system (-23)

This was a long-standing issue existing since at least OpenWrt Backfire,
and today I finally managed to debug and (hopefully) solve it.
It was happening very few times on most devices; but it was happening
a lot more frequently on fast platforms with multiple radios, such as
the powerpc-based dual-ath9k-radio tl-wdr4900-v1.

Signed-off-by: Vittorio Gambaletta 

---
 .../mac80211/files/lib/netifd/wireless/mac80211.sh |   35 +---
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index baa023e..5058b01 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -411,6 +411,31 @@ mac80211_check_ap() {
has_ap=1
 }
 
+mac80211_iw_interface_add() {
+   local phy="$1"
+   local ifname="$2"
+   local type="$3"
+   local wdsflag="$4"
+
+   iw phy "$phy" interface add "$ifname" type "$type" $wdsflag
+   ret="$?"
+
+   [ "$ret" = 233 ] && {
+   # Device might have just been deleted, give the kernel some 
time to finish cleaning it up
+   sleep 1
+
+   iw phy "$phy" interface add "$ifname" type "$type" $wdsflag
+   ret="$?"
+   }
+
+   [ "$ret" != 0 ] && {
+   wireless_setup_failed INTERFACE_CREATION_FAILED
+   return 1
+   }
+
+   return 0
+}
+
 mac80211_prepare_vif() {
json_select config
 
@@ -437,7 +462,7 @@ mac80211_prepare_vif() {
# It is far easier to delete and create the desired interface
case "$mode" in
adhoc)
-   iw phy "$phy" interface add "$ifname" type adhoc
+   mac80211_iw_interface_add "$phy" "$ifname" adhoc || 
return
;;
ap)
# Hostapd will handle recreating the interface and
@@ -451,21 +476,21 @@ mac80211_prepare_vif() {
mac80211_hostapd_setup_bss "$phy" "$ifname" "$macaddr" 
"$type" || return
 
[ -n "$hostapd_ctrl" ] || {
-   iw phy "$phy" interface add "$ifname" type __ap
+   mac80211_iw_interface_add "$phy" "$ifname" __ap 
|| return

hostapd_ctrl="${hostapd_ctrl:-/var/run/hostapd/$ifname}"
}
;;
mesh)
-   iw phy "$phy" interface add "$ifname" type mp
+   mac80211_iw_interface_add "$phy" "$ifname" mp || return
;;
monitor)
-   iw phy "$phy" interface add "$ifname" type monitor
+   mac80211_iw_interface_add "$phy" "$ifname" monitor || 
return
;;
sta)
local wdsflag=
staidx="$(($staidx + 1))"
[ "$wds" -gt 0 ] && wdsflag="4addr on"
-   iw phy "$phy" interface add "$ifname" type managed 
$wdsflag
+   mac80211_iw_interface_add "$phy" "$ifname" managed 
"$wdsflag" || return
[ "$powersave" -gt 0 ] && powersave="on" || 
powersave="off"
iw "$ifname" set power_save "$powersave"
;;


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

Re: [LEDE-DEV] Wrong feeds.conf.default on lede-sdk-17.01.0-rc2

[Pau]

Fine.

Thank you.

On 13/03/17 20:09, Jo-Philipp Wich wrote:
> Hi Pau,
> 
> the issue is known and has been fixed with 17.01.0 final, see
> https://lede-project.org/releases/17.01/changelog-17.01.0-final#section501
> 
> Kind regards,
> Jo
> 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

-- 
./p4u



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] Wrong feeds.conf.default on lede-sdk-17.01.0-rc2

[Jo-Philipp Wich]

Hi Pau,

the issue is known and has been fixed with 17.01.0 final, see
https://lede-project.org/releases/17.01/changelog-17.01.0-final#section501

Kind regards,
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] Wrong feeds.conf.default on lede-sdk-17.01.0-rc2

[Pau]

I downloaded the SDK [1] for 17.01.0-rc2 (ar71xx). The
feeds.conf.default file does not seem to be correct, this is the content:

src-git base https://git.lede-project.org/source.git;HEAD
src-git packages
https://git.lede-project.org/feed/packages.git^06198d9c8c1ba061a0a5d566545a5c0bbce2b0a4
src-git luci
https://git.lede-project.org/project/luci.git^e306ee6c93c1ef600012f47e40dd75020d4ab555
src-git routing
https://git.lede-project.org/feed/routing.git^dd36dd47bbd75defcb3c517cafe7a19ee425f0af
src-git telephony
https://git.lede-project.org/feed/telephony.git^1f0fb2538ba6fc306198fe2a9a4b976d63adb304


As far as I understand instead of ;HEAD it should be ;lede-17.01

Sorry for not providing a patch right now, hope someone can fix it.

[1] lede-sdk-17.01.0-rc2-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64
-- 
./p4u



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] using 464XLAT in LEDE (or OpenWRT)

[Hans Dedecker]

On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ
 wrote:
> Hi Hans,
>
> Thanks for your response.
>
> I’m now a bit more confused with your comment that it doesn’t work in LEDE, 
> because this afternoon, finally I got it working.
>
> Let me explain all the history.
>
> About a year ago, using OpenWRT 15.05, I tested 464XLAT and it worked fine.
>
> Last weekend, I was trying to replicate it again directly with LEDE … no 
> success.
>
> Then I tried again with OpenWRT 15.05.1 and didn’t worked, but this may be 
> related to the platform I was using.
>
> I reverted back to 15.05 and it worked.
>
> This has been a very slow process because I expected that simply adding at 
> network:
> config interface 'clat'
> option proto '464xlat'
> will make it, but, I didn’t realize that it requires a reboot, for some 
> reason, just ifdown/ifup, is not enough.
>
> I could ping/traceroute to both IPv4/IPv6, browse, use skype, etc., and only 
> having in the WAN IPv6, which is for what is meant 464XLAT of course.
>
> Once I got it stable, tried again with LEDE (17.01.0 stable), and even having 
> the same configuration didn't worked, or at least I was assuming that …
>
> In the packages info, it shows a dependency with libssp, so that confused me 
> … I also saw that the out rule was removed from 15.05, so I even edited the 
> 464xlat.sh to include that rule again, but no difference.
>
> Now … by chance instead of trying ping, which is the FIRST thing that you do 
> (specially because it worked in 15.05) … my previous browsing window was 
> still open and tried to reload it … and it worked!
>
> I tried it also with the trunk version from today, and also works.
>
> I tried with both a hardware router and also a VM under VirtualBox.
>
> So, I’m not sure to understand in which LEDE release is broken …
>
> What definitively is broken is the capability to issue a ping (IPv4).
464xlat is definitely broken on LEDE as you need an ip rule which
checks the prelocal table before the local table is checked

ip rule list
0:  from all lookup prelocal
1:  from all lookup local

The rule to the prelocal table is required in order to route the
464xlat traffic to the nat46 module via the xlat interface
>
> Also, there are other, probably simple to sort out (I’m not a programmer so 
> I’m not able to contribute myself on this), issues that may be enhanced to 
> have a good 464XLAT support:
> 1) option ipv4addr '192.168.0.1' seems to not work, I see in the 464xlat.sh 
> is fixed to 192.0.0.1, but according to my reading of RFC6877/7915 (and all 
> the related ones), it should be possible to select what address and not just 
> one address but a prefix for the translation. I believe that using just one 
> address, if there is a lot of flows, you can run out of “ports” for that 
> number of ports. This may not happen in a small residential network but if 
> you have a LEDE router in an enterprise is a different history.
You cannot specify an IPv4 address in the 464xlat config; all IPv4
traffic is indeed source nated to 192.0.0.1. Large scale deployment of
464xlat in an enterprise was not considered by Steven Barth as an
initial development target

> 2) Same with option ip6addr '2001:470:68ee:30::1', it should be possible to 
> use instead of just one address, a pool of them (a prefix).
> 3) Last, I believe the default route is not being installed. In fact, in my 
> case, I’ve a default route for in the WAN interphase to my primary router. 
> This default route is still there after installing 464XLAT. My default route 
> is: default via fe80::1 dev eth0.6. So I’ve added ip -6 route add 
> 64:ff9b::/96 via 2001:470:68ee:20::20 dev eth0.6 (later I’ve made a static 
> route with this at network, so it is keep across reboots). I think we need to 
> have two choices here. If there is already a default route, keep it and add a 
> route for the NAT64 prefix, otherwise have a default route to the NAT64 
> prefix.
>
> Let me explain 3). If you’re an ISP, you don’t want to have all the IPv6 
> traffic to go via the NAT64, as this means extra overload in that box. So you 
> will prefer to have ONLY the IPv4/IPv6 translated traffic going there (the 
> specific route for 64:ff9b::/96 in my case) and keep the rest going thru the 
> upstream infrastructure.
I did not hit this issue in my setups before but again this could be
related to 464xlat being broken on LEDE; the fact you have to
configure manually routes is not normal as routing rules are put into
place by the 464xlat script
(https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat.sh#L47
and 
https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat.sh#L48)
>
> Of course this can be done in the BRAS devices, or the access infrastructure, 
> but I think is also possible that this part of the network is layer 2, so 
> you’ve no way to do it there and the CPE should support it.
>
> This is my config at network:
> 

Re: [LEDE-DEV] [RFC] Disable 802.11b rates by default and set supported/basic rates appropriately for 2.4 GHz BSSes based on require_mode

[Nick Lowe]

I have sent separately via GitHub.

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

Re: [LEDE-DEV] [PATCH] imx6: add support for GW5904

[Rafał Miłecki]

On 10 March 2017 at 16:01, Tim Harvey  wrote:
> diff --git 
> a/target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6qdl-gw5904.dtsi 
> b/target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
> new file mode 100644
> index 000..4503f2c
> --- /dev/null
> +++ b/target/linux/imx6/files-4.9/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
> @@ -0,0 +1,629 @@
> +/*
> + * Copyright 2017 Gateworks Corporation
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include 

Hi Tim,

Is Gateworks very strict to the GPL licensing DTS files? Would that be
OK to release this under some BSD-compatible license? Please take a
look at my previous short e-mail:
http://lists.infradead.org/pipermail/lede-dev/2017-February/005842.html

-- 
Rafał

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

[LEDE-DEV] [RFC] Disable 802.11b rates by default and set supported/basic rates appropriately for 2.4 GHz BSSes based on require_mode

[Nick Lowe]

Disable 802.11b rates by default and set supported/basic rates
appropriately for 2.4 GHz BSSes based on require_mode.

The require_mode option can currently be configured to a value of g or
n for 2.4 GHz BSSes or n or ac for 5 GHz BSSes to set the minimum mode
that connecting clients need to support to be able to connect.

This patch introduces a new require_mode of b and defaults to a
require_mode of g where this is unspecified.

The rationale for this, which is stronger now than in 2014, can be found in:

https://mentor.ieee.org/802.11/dcn/14/11-14-0099-00-000m-renewing-2-4ghz-band.pptx

The balance of equities between compatibility with b clients and the
detriment to the 2.4 GHz ecosystem as a whole in 2017 strongly favors
disabling b support by default.

Issues previously in the hostapd.sh shell script for 2.4 GHz BSSes for
the require_mode were:

1) Where a require_mode of g was configured, the supported rates still
included b rates yet the basic rates would not include b rates.

2) Where a require_mode of g was configured, the basic rates would be
set to 60 120 240 that would override the configuration of the
basic_rate option rather than filtering to exclude b rates.

3) Where a require_mode of n was configured, the b rates were still
used as basic rates which is not airtime efficient. The g require_mode
achieved better airtime efficiency for broadcast/multicast traffic.
Only where the require_mode was set to g would the basic rates be set
to not include b rates.

Now:

1) Where a require_mode is not configured to b and the supported_rates
option has not been configured, this will be changed to OFDM rates
only:

60 90 120 180 240 360 480 540

2) Where a require_mode is not configured to b and the supported_rates
option has been configured, this will be filtered to include OFDM
rates only.

3) Where a require_mode is not configured to b and the basic_rate
option has not been configured, this will be changed to OFDM rates
only:

60 120 240

4) Where a require_mode is not configured to b and the basic_rate
option has been configured, this will now be filtered to include OFDM
rates only.

Signed-off-by: Nick Lowe 
---
 package/network/services/hostapd/files/hostapd.sh | 79 +++
 1 file changed, 68 insertions(+), 11 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 988ebc7..654d64e 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -90,23 +90,80 @@ hostapd_prepare_device_config() {
}
[ -n "$hwmode" ] && append base_cfg "hw_mode=$hwmode" "$N"

-   local brlist= br
-   json_get_values basic_rate_list basic_rate
-   for br in $basic_rate_list; do
-   hostapd_add_rate brlist "$br"
-   done
-   case "$require_mode" in
-   g) brlist="60 120 240" ;;
-   n) append base_cfg "require_ht=1" "$N";;
-   ac) append base_cfg "require_vht=1" "$N";;
-   esac
-
local rlist= r
json_get_values rate_list supported_rates
for r in $rate_list; do
+   if [ "$require_mode" != "b" ]; then
+   case "$r" in
+   1000)
+   continue
+   ;;
+   2000)
+   continue
+   ;;
+   5500)
+   continue
+   ;;
+   11000)
+   continue
+   ;;
+   esac
+   fi
+
hostapd_add_rate rlist "$r"
done

+   local brlist= br
+   json_get_values basic_rate_list basic_rate
+   for br in $basic_rate_list; do
+   if [ "$require_mode" != "b" ]; then
+   case "$br" in
+   1000)
+   continue
+   ;;
+   2000)
+   continue
+   ;;
+   5500)
+   continue
+   ;;
+   11000)
+   continue
+   ;;
+   esac
+   fi
+
+   if [ -z $rate_list ]; then
+   hostapd_add_rate brlist "$br"
+   else
+   for r in $rate_list; do
+   if [ "$br" = "$r" ]; then
+   hostapd_add_rate brlist "$br"
+   break
+   fi
+   done
+   fi
+   done
+
+   if [ "$require_mode" != "b" ]; then
+   if [ -z "$rlist" ]; then
+   rlist="60 90 120 180 240 360 480 540"
+   fi
+
+   if [ -z "$brlist" ]; then
+   brlist="60 120 240"
+   fi
+
+   case "$require_mode" in
+   n)
+   append base_cfg "require_ht=1" "$N"
+   ;;
+   ac)
+   append base_cfg "require_vht=1" "$N"
+   ;;
+   esac
+   fi
+
[ -n "$rlist" ] && append base_cfg "supported_rates=$rlist" "$N"
[ -n "$brlist" ] && append base_cfg "basic_rates=$brlist" "$N"
[ -n "$beacon_int" ] && append base_cfg "beacon_int=$beacon_int" "$N"
--
2.10.2

Re: [LEDE-DEV] [PATCH] imx6: add support for GW5904

[Tim Harvey]

On Fri, Mar 10, 2017 at 10:37 AM, Thomas Endt  wrote:
> Just curious: Why is the GW5904 not listed on http://www.gateworks.com/?
> I'm searching for technical data to include in the Table of Hardware
> (https://lede-project.org/toh/views/toh_minimal_all?dataflt%5BBrand*%7E%5D=g
> ateworks%5BModel*%7E%5D=ventana)
>
> Regards,
>
> Thomas
>

Thomas,

It's a special-order and/or hasn't been added there yet.

Tim

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

Re: [LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address

[Paul Oranje]

> Op 12 mrt. 2017, om 18:31 heeft Eric Luehrsen  het 
> volgende geschreven:
> 
> This discussion has really put some requirements and restrictions on 
> what I am trying to implement. I like that. Excuse my stream of 
> consciousness writing style, if you question "what? .. crazy?" then its 
> likely my fault for not editing well.
> 
> On 03/11/2017 11:39 AM, Paul Oranje wrote:
>>> RFC 3315 section 22.5:
>>> 
>>>   An IA_TA option does not include values for T1 and T2.
>> The use-case that Eric gave as an example - as I understood it - concerns 
>> policies that are enforced at the server side; at the client site 
>> “management" cannot enforce anything.
>> 
> Simply, a rational management desire would be to have similar or 
> "transparent" system of policies between IP4 and IP6. They have decades 
> of "Oh! !" lessons learned including tools built around DHCPv4. They 
> want evolution not revolution in the change over.
> 
> During an hypothetical IP6 roll out plan meeting ... The potential for 
> IP6 to profile a network externally is considered and the emotional 
> response is "unsettling" at best. The potential for loss of control with 
> SLAAC is equally emotional. Hopefully someone well spoken and well 
> respected explains NAT is not security, or storm clouds form.
> 
> Desire: one global IP6 per (virtual) machine just like was had with IP4.
> Desire: external network obscurity just like was had with IP4.
> Desire: full traceability and accountability for all intranet and 
> internet connections.
> Desire: time and point of first connection logs as mobile devices attach.
> Desire: not require extra steps or tools for general employees to "work 
> around" issues.
> Desire: IT policy/training/manuals don't need to change in grand 
> structure  (only change specifics in implementation)
> Desire: DUID or Client-ID or MAC is an "asset tag" and not modified 
> session to session.
> 
> DHCPv6 IA_NA which is NOT simply a fixed hash of DUID but also a random 
> function over moderate periods of time would be within standard and meet 
> these desires. Within "accountability and traceability" a limit to 
> address roll over frequency creates another rational definition of 
> "non-temporary."
> 
>>> In any case, there are existing client implementations of IA_TA (for
>>> example ISC dhclient and dibbler) and RFC7721 stable IIDs (for example
>>> Linux kernel and NetworkManager).
>> Maybe you can create a patch that would implement IA_TA in odhcpd, if that 
>> isn’t implemented yet (I do not know, have a look at the code).
>> That would satisfy another use case.
> This could/should also be done, but many as-purchased devices just don't 
> handle IA_TA (well). Okay, more generically IP6 isn't often handled 
> (well). It will be hard to test robustly. IA_TA can deliver a plurality 
> of addresses for machine/connection obscurity. "How many?" becomes a 
> compatibility and complexity issue as one example.
What policies the server could implement while serving a requested IA_TA ? (In 
case the server has to deal with a (rare) client that does requests that).
I ask this question since the nature of this IA probably restricts what 
policies one can implement.

> 
> Hurdle: If IT is conservative about in house modification and wants to 
> deploy user-end equipment as-purchased, then this could limit their 
> supplier options and the buyers negotiation leverage. Modifying and 
> maintaining infrastructure is an IT job. Supporting all the daily user 
> issues is often part of the service contract with the user equipment 
> provider. If we want providers support, then use the equipment 
> as-purchased or within boundaries as specified in the contract.
> 
> ___
> 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] libnl: Fix building with uClibc

[Alexey Brodkin]

uClibc doesn't implement strerror_l() and thus libnl starting from
3.2.29 couldn't be compiled with it any longer, see
https://github.com/thom311/libnl/commit/6c2d77e91184073c44f83d4a6182aaba06d7

To work-around that problem we'll just do a check on strerror_l()
availability during configuration and if it's not there just fall back
to locale-less strerror().

Patch for libnl is alreadfy merged upstream, see
https://github.com/thom311/libnl/commit/e15966ac7f3b43df2acf869f98089762807d0568
and once the next libnl release happens this one must be removed from
Lede/OpenWrt.

Signed-off-by: Alexey Brodkin 
Cc: Felix Fietkau 
Cc: John Crispin 
Cc: Daniel Engberg 
---
 ...usage-of-strerror_l-if-it-doesn-t-exist-i.patch | 105 +
 1 file changed, 105 insertions(+)
 create mode 100644 
package/libs/libnl/patches/0001-lib-Escape-usage-of-strerror_l-if-it-doesn-t-exist-i.patch

diff --git 
a/package/libs/libnl/patches/0001-lib-Escape-usage-of-strerror_l-if-it-doesn-t-exist-i.patch
 
b/package/libs/libnl/patches/0001-lib-Escape-usage-of-strerror_l-if-it-doesn-t-exist-i.patch
new file mode 100644
index 00..a31ef47729
--- /dev/null
+++ 
b/package/libs/libnl/patches/0001-lib-Escape-usage-of-strerror_l-if-it-doesn-t-exist-i.patch
@@ -0,0 +1,105 @@
+From 098a4cc35b0da4438b8b67a914edecebef5bb6a9 Mon Sep 17 00:00:00 2001
+From: Alexey Brodkin 
+Date: Fri, 10 Mar 2017 13:22:14 +0300
+Subject: [PATCH] lib: Escape usage of strerror_l() if it doesn't exist in libc
+
+uClibc doesn't implement strerror_l() and thus libnl starting from
+3.2.29 couldn't be compiled with it any longer.
+
+To work-around that problem we'll just do a check on strerror_l()
+availability during configuration and if it's not there just fall back
+to locale-less strerror().
+
+Signed-off-by: Alexey Brodkin 
+Cc: Andre Draszik 
+Cc: Thomas Haller 
+---
+
+This patch is now accepted upstream and will be a part of the next libnl
+release, see
+https://github.com/thom311/libnl/commit/e15966ac7f3b43df2acf869f98089762807d0568
+
+ configure.ac| 2 ++
+ lib/utils.c | 8 +++-
+ src/lib/utils.c | 6 ++
+ 3 files changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 68b285e5b15c..2739b997ee3a 100644
+--- a/configure.ac
 b/configure.ac
+@@ -121,6 +121,8 @@ fi
+ 
+ AC_CONFIG_SUBDIRS([doc])
+ 
++AC_CHECK_FUNCS([strerror_l])
++
+ AC_CONFIG_FILES([
+ Makefile
+ libnl-3.0.pc
+diff --git a/lib/utils.c b/lib/utils.c
+index fb350d13fd2f..06273c5b291e 100644
+--- a/lib/utils.c
 b/lib/utils.c
+@@ -30,7 +30,9 @@
+ #include 
+ #include 
+ #include  /* exit() */
++#ifdef HAVE_STRERROR_L
+ #include 
++#endif
+ 
+ /**
+  * Global variable indicating the desired level of debugging output.
+@@ -123,9 +125,10 @@ int __nl_read_num_str_file(const char *path, int 
(*cb)(long, const char *))
+ 
+ const char *nl_strerror_l(int err)
+ {
++  const char *buf;
++#ifdef HAVE_STRERROR_L
+   int errno_save = errno;
+   locale_t loc = newlocale(LC_MESSAGES_MASK, "", (locale_t)0);
+-  const char *buf;
+ 
+   if (loc == (locale_t)0) {
+   if (errno == ENOENT)
+@@ -140,6 +143,9 @@ const char *nl_strerror_l(int err)
+   }
+ 
+   errno = errno_save;
++#else
++  buf = strerror(err);
++#endif
+   return buf;
+ }
+ /** @endcond */
+diff --git a/src/lib/utils.c b/src/lib/utils.c
+index 5878f279c364..feb1d4ef4056 100644
+--- a/src/lib/utils.c
 b/src/lib/utils.c
+@@ -81,6 +81,7 @@ void nl_cli_fatal(int err, const char *fmt, ...)
+   fprintf(stderr, "\n");
+   } else {
+   char *buf;
++#ifdef HAVE_STRERROR_L
+   locale_t loc = newlocale(LC_MESSAGES_MASK, "", (locale_t)0);
+   if (loc == (locale_t)0) {
+   if (errno == ENOENT)
+@@ -91,9 +92,14 @@ void nl_cli_fatal(int err, const char *fmt, ...)
+   }
+   if (loc != (locale_t)0)
+   buf = strerror_l(err, loc);
++#else
++  buf = strerror(err);
++#endif
+   fprintf(stderr, "%s\n", buf);
++#ifdef HAVE_STRERROR_L
+   if (loc != (locale_t)0)
+   freelocale(loc);
++#endif
+   }
+ 
+   exit(abs(err));
+-- 
+2.7.4
+
-- 
2.11.0


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

Re: [LEDE-DEV] [PATCH umdns 0/3] Stop storing hosts as services

[John Crispin]

On 10/03/17 08:59, Rafał Miłecki wrote:

From: Rafał Miłecki 

I find storing hosts as services a bit confusing & making code a bit
more complex by requiring extra checks.

This patchset shouldn't change any behavior. I verified it by doing:
ubus call umdns hosts
ubus call umdns browse
before and after every commit. I tested it in environment with:
1) 17.01.0-rc2 running umdns
2) Android smartphone running Bonjour Browser
3) D-Link DCS-2210L IP camera


Acked-by: John Crispin 

thanks, looks like a nice cleanup


Rafał Miłecki (3):
   Access cached records (instead of services) to read list of hosts
   Refresh DNS records A and  directly
   Don't cache hosts as services

  cache.c | 30 ++
  cache.h |  5 ++---
  ubus.c  | 20 
  3 files changed, 32 insertions(+), 23 deletions(-)




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