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

[Paul Oranje]

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

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

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

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


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

Re: [LEDE-DEV] [PATCH] busybox: re-enable telnet applet

[Paul Oranje]

Who needs telnet when nc is there ?

> Op 18 feb. 2018, om 19:25 heeft Philip Prindeville 
>  het volgende geschreven:
> 
> 
> 
>> On Feb 18, 2018, at 2:27 AM, John Crispin  wrote:
>> 
>> 
>> 
>>> On 20/06/17 19:13, Stefan Tomanek wrote:
>>> While sshd should be favoured over telnetd, having a telnet client on the
>>> router is useful for connecting to other devices in the same LAN.
>>> 
>>> Signed-off-by: Stefan Tomanek 
>> 
>> sorry for the late reply, it has been discussed over and over and the 
>> decision was made to not enable telnet by default. sorry ...
>> 
>>John
> 
> Too bad.  While it’s a liability for logging in, it’s a great tool for 
> testing remote services like HTTP, SMTP, IMAP, JetDirect printers, etc.
> 
> 
>>> ---
>>> package/utils/busybox/Config-defaults.in |4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/package/utils/busybox/Config-defaults.in 
>>> b/package/utils/busybox/Config-defaults.in
>>> index 1977e7f..9e0efcf 100644
>>> --- a/package/utils/busybox/Config-defaults.in
>>> +++ b/package/utils/busybox/Config-defaults.in
>>> @@ -2289,10 +2289,10 @@ config BUSYBOX_DEFAULT_TCPSVD
>>> default n
>>> config BUSYBOX_DEFAULT_TELNET
>>> bool
>>> -default n
>>> +default y
>>> config BUSYBOX_DEFAULT_FEATURE_TELNET_TTYPE
>>> bool
>>> -default n
>>> +default y
>>> config BUSYBOX_DEFAULT_FEATURE_TELNET_AUTOLOGIN
>>> bool
>>> default n
>> 
>> 
>> ___
>> 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 mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Paul Oranje]

People that build there own images and choose OpenSSH would be expected to know 
what they are doing and for that reason not allowing password logins as a 
default seems reasonable, but ... even those knowledgeable users may sometimes 
forget to add a public key and find their lovely router soft bricked.

Users that choose OpenSSH, may indeed want to disable passwords. They can do so 
safely *once* they've set-up their public keys, either at image build-time or 
at run-time, even when the default allows passwords.

In general avoiding locking out users by allowing passwords as a (first) 
default seems reasonable as it does not interfere with securing a box. (this 
adheres to John Stuart Mill's harm principle)

To many words, bye,
Paul


> Op 15 feb. 2018, om 20:50 heeft Magnus Kroken  het 
> volgende geschreven:
> 
> On 15.02.2018 16.52, Philip Prindeville wrote:
>> Well, right!  That was my first approach with a “config" option to do 
>> exactly that, but it was shot down:
>> 
>> https://github.com/openwrt/packages/pull/5520
>> 
>> I even defaulted the option to continue to allow passwords so that only 
>> people who (a) selected OpenSSH and (b) turned this option off would be 
>> affected… which has to be a small portion of the population.
> 
> Sorry, I must have missed this. I'm in favor of the current state of that 
> pull request (my concern is the direct consequences of the patch, not the way 
> it is implemented, more below).
> 
>>> Consider a scenario where a user builds an image with OpenSSH, without 
>>> Dropbear (because they have OpenSSH), and without a web interface (because 
>>> they want to save space). This is easily done by selecting and deselecting 
>>> packages in menuconfig/imagebuilder, no custom files needed today. With 
>>> this change, if the image is missing authorized_keys, the only way to log 
>>> in is serial console (failsafe will be locked out too), which requires 
>>> soldering - or using bootloader recovery features, which may also require 
>>> soldering and aren't consistently documented.
>> 
>> 
>> Actually, most of the boxes that *I* work on (Geos, Alix 2D, net5501, Xeon 
>> 1U servers, etc.) all have serial ports and most of them have VGA as well 
>> (or could if you install the optional header).
> 
> True, I was thinking of typical 5-port wireless routers. Still, the lockout 
> problem is real on those devices, and OpenWrt targets and supports a lot of 
> them.
> 
>>> This is just about the default configuration, it's not a choice between 
>>> conflicting compile time options with varying security implications. While 
>>> key authentication may be best practice, allowing SSH password logins isn't 
>>> on the level of reimplementing LuCI in PHP 4. The change is *literally* a 
>>> handful of sed commands, why can't advanced users take care of that 
>>> themselves? Why do we want to make it easier to build a soft-bricking image 
>>> than it is today?
>> 
>> 
>> Conversely, why can’t advanced users have a clear, standardized way of doing 
>> this?  That they’re “advanced” doesn’t mean they don’t also appreciate 
>> convenience, an easy way to save and export/import configurations, etc.
> 
> I'm not against general development, improvement or standardization of config 
> handling. I'm against the default state of the patch that started this mail 
> thread. The convenience of this patch opens up a new way to break the 
> convenience of failsafe on a lot of devices, and I don't think many people 
> would expect the particular package selection to cause such a behavior. I 
> consider failsafe to be more important. You've already addressed that in your 
> pull request, and I'm in favor of "this should be configurable at build time, 
> but the default behavior should not change". How that is implemented is a 
> different matter, which so far I haven't thought much about.
> 
>> In a perfect world, no one should ever have to build with patches, anything 
>> in files/, cherry-picked commits, etc.  Everything would be expressed in the 
>> .config (or kernel-config).
> 
> I have a bunch of uci-defaults scripts (currently loaded via files) that 
> configure my devices after flashing (if any interface has MAC address X, run 
> a bunch of commands (uci stuff, sed, cat, service reloads, whatever)). I keep 
> adding to them without structuring things, and they become unmanageable. One 
> of many things I've thought of and never gotten around to is creating a 
> package feed of config script packages. A package would e.g. be 
> set_lan_ip4_addr, it would have configuration option(s) to set the desired IP 
> address in menuconfig, and then install a generic uci-defaults script with 
> the desired IP address inserted via sed. Maybe there are better ways to do 
> this (install a /etc/config/deployment file that all the scripts read from?), 
> anyway it would be an improvement of what I do now. In theory, that could be 
> used to get any number of possibilities into 

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Paul Oranje]

Your aptness for seeing the possible attack vectors warrants your judgement ...

> Op 10 feb. 2018, om 17:07 heeft Philip Prindeville 
> <philipp_s...@redfish-solutions.com> het volgende geschreven:
> 
> 
>> On Feb 10, 2018, at 3:28 AM, Paul Oranje <p...@oranjevos.nl> wrote:
>> 
>> Wouldn't it be appropriate to disallow password authentication on wan only 
>> and allow it on all networks "behind" the router?
> 
> Not necessarily.
> 
> That’s why UPnP is such an issue. A machine inside a firewall gets infected 
> by a virus through a download or email... then the first thing the virus does 
> is punch holes in the firewall to allow outside scans of the remaining hosts.
> 
> Allowing password logins from an infected host just means that the virus has 
> to do slightly more work before it owns the router (ie run a password attack).
> 
> Not substantially more secure...
> 
> -Philip
> 
>> 
>>> Op 9 feb. 2018, om 01:28 heeft Philip Prindeville 
>>> <phil...@redfish-solutions.com> het volgende geschreven:
>>> 
>>> From: Philip Prindeville <phil...@redfish-solutions.com>
>>> 
>>> Allowing password logins leaves you vulnerable to dictionary
>>> attacks.  We disable password-based authentication, limiting
>>> authentication to keys only which are more secure.
>>> 
>>> Note: You'll need to pre-populate your image with some initial
>>> keys. To do this:
>>> 
>>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh"
>>> from your top-level directory;
>>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
>>> "files/root/.ssh/authorized_keys" and indeed, you can collect
>>> keys from several sources this way by concatenating them;
>>> 3. Set the permissions on "authorized_keys" to 644 or 640.
>>> 
>>> Signed-off-by: Philip Prindeville <phil...@redfish-solutions.com>
>>> ---
>>> net/openssh/Makefile | 7 +--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/net/openssh/Makefile b/net/openssh/Makefile
>>> index 
>>> 3a19387b0d0110fc5c25d7ffccb524a61c0588c4..7ca61f6ce6d5916016a554b4a283a874e950232c
>>>  100644
>>> --- a/net/openssh/Makefile
>>> +++ b/net/openssh/Makefile
>>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>>> 
>>> PKG_NAME:=openssh
>>> PKG_VERSION:=7.6p1
>>> -PKG_RELEASE:=1
>>> +PKG_RELEASE:=2
>>> 
>>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>>> PKG_SOURCE_URL:=https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ \
>>> @@ -248,7 +248,10 @@ define Package/openssh-server/install
>>>   $(INSTALL_DIR) $(1)/etc/ssh
>>>   chmod 0700 $(1)/etc/ssh
>>>   $(INSTALL_DATA) $(PKG_INSTALL_DIR)/etc/ssh/sshd_config $(1)/etc/ssh/
>>> -sed -r -i 's,^#(HostKey 
>>> /etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' $(1)/etc/ssh/sshd_config
>>> +sed -r -i \
>>> +-e 's,^#(HostKey 
>>> /etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' \
>>> +-e 's,^#PasswordAuthentication yes,PasswordAuthentication no,' 
>>> \
>>> +$(1)/etc/ssh/sshd_config
>>>   $(INSTALL_DIR) $(1)/etc/init.d
>>>   $(INSTALL_BIN) ./files/sshd.init $(1)/etc/init.d/sshd
>>>   $(INSTALL_DIR) $(1)/usr/sbin
>>> -- 
>>> 2.7.4
>>> 
>>> 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] Debugging steps for FS#1246 - Ubnt Nanostation Loco M2 - WDS link drops out after a few hours

[Paul Oranje]

As a work-around you might setup a crontab that restarts wifi every 8 hours or 
something like that.
Once the root cause, whatever it is, has been dealt with the crontab entry can 
be disabled again.

with "crontab -e" you edit the file
for syntax, see: "man 5 crontab"

Regards,
Paul


> Op 26 jan. 2018, om 01:56 heeft Aaron Z  het volgende 
> geschreven:
> 
> I opened a ticket in late Dec but haven't heard anything. Does anyone
> have any suggestions on where to go next to troubleshoot this issue?
> My wife is getting very tired of the internet randomly dropping out on
> our WDS link.
> 
> Ticket: https://bugs.openwrt.org/index.php?do=details_id=1246
> 
> Cliffs:
> I have a pair of Nanostation Loco M2 access points setup as a wireless
> bridge over a ~1300 foot (~400M) line of sight link.
> 
> One is setup as a WDS AP and the other is setup as a WDS Client, after
> a few hours (4-12 hours?) the link drops out but still says that is
> connected (if I go to status it shows the other AP as connected but I
> cannot ping or do anything else across the link).
> 
> If I restart the wireless service on the client device, the connection
> comes right back and all is well for a 4-12 hours.
> 
> I have had LEDE 17.01.3, 17.0.4 and OpenWrt SNAPSHOT r5499-575178e /
> LuCI Master (git-17.343.27587-8e6b1a6) and now OpenWrt SNAPSHOT
> r5902-9c2ac19b03 / LuCI Master (git-18.021.64448-4dddecf) installed at
> both ends with the same results.
> 
> Anyone have any suggestions on where to look next to figure out why
> this is happening?
> 
> Thanks
> 
> Aaron Z
> A human being should be able to change a diaper, plan an invasion,
> butcher a hog, conn a ship, design a building, write a sonnet, balance
> accounts, build a wall, set a bone, comfort the dying, take orders,
> give orders, cooperate, act alone, solve equations, analyze a new
> problem, pitch manure, program a computer, cook a tasty meal, fight
> efficiently, die gallantly. Specialization is for insects.
> — Robert Heinlein, Time Enough for Love
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [OpenWrt-Devel] owrt landing page

[Paul Oranje]

A practica;l note on the style differences.
The white LEDE style is very clearly different from the darkish OpenWrt style: 
one does notice very easily which version of the wiki (and other stuff as well) 
one sees.

A good reason to maintain the visual different styles for the near future.
Paul

p.s.
And personally I like the light style better as it looks less crowded.


> Op 14 jan. 2018, om 18:39 heeft Thomas Endt  het volgende 
> geschreven:
> 
> FYI - LEDE wiki styling updated
> 
> - Sidebar background added
> - Sidebar fontsize increased
> 
> --> https://lede-project.org/_media/wiki/ledewiki-owrtstyling2.jpg
> 
> Of course, sidebar content to be adapted to OpenWrt i/o LEDE, but apart from 
> that: Can we go live with that styling?
> 
> Thomas
> 
>> -Ursprüngliche Nachricht-
>> Von: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] Im Auftrag
>> von Alberto Bursi
>> Gesendet: Donnerstag, 11. Januar 2018 19:54
>> An: lede-dev@lists.infradead.org
>> Betreff: Re: [LEDE-DEV] [OpenWrt-Devel] owrt landing page
>> 
>> 1) sidebar
>> 
>> I think it should have some background to make it readable, and
>> possible a slight font increase.
>> 
>> 
>> 2)  logo
>> 
>> see [1] for the thread about the logo. Nothing was decided.
>> 
>> I personally agree that having one of the logos from there would be
>> great, we'd need to ask the developers/project owners for a vote on
>> this
>> as the logo is their own decision to make.
>> 
>> This will probably take months, so for now just use the current logo.
>> 
>> 3) my idea was to move in a "legacy" section only the parts the current
>> LEDE wiki already has (and are the up-to-date ones), while all other
>> stuff that does not have an equivalent is just added as-is to the
>> current wiki (just linked in the right place).
>> 
>> 
>> 
>> 1. http://lists.infradead.org/pipermail/lede-dev/2017-May/007783.html
>> 
>> -Alberto
>> 
>> 
>> On 01/10/2018 10:56 PM, Thomas Endt wrote:
>>> Hi John,
>>> 
>>> First results on a private demowiki, see: https://lede-
>> project.org/_media/wiki/ledewiki-owrtstyling.jpg
>>> 
>>> 1) red marking: What are we going to do with the sidebar (raw,
>> untouched styling; could be beautified)? Keep or remove?
>>> 2) blue marking: I remember there was some discussion about a new,
>> fresh logo.
>>>I think now with the move to the LEDE codebase is the right time
>> to refresh the wiki a bit too.
>>>Does anybody remember where that discussion happened and what the
>> outcome was?
>>> 3) I changed my mind regarding hard cut. The OpenWrt wiki is still
>> rw, and we should keep it that way until we have a plan on how to
>> accomplish the actual merge of the wikis.
>>> 
>>> 
>>> Thomas
>>> 
 -Ursprüngliche Nachricht-
 Von: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> Im
 Auftrag von Thomas Endt
 Gesendet: Samstag, 6. Januar 2018 18:06
 An: 'John Crispin'; 'LEDE Development List'; 'LEDE Project
 Administration'; 'OpenWrt Development List'
 Betreff: Re: [OpenWrt-Devel] [LEDE-DEV] owrt landing page
 
 Hi John,
 
 Since the styling is based on CSS, we would need the OpenWrt wiki's
>> CSS
 for that. Once we have that, it will be relatively easy.
 But instead of doing the merge of the wikis step by step, I would
 suggest a hard cut.
 
 1.) Make OpenWrt wiki read only -> I can do that or Imre
 2.) Create .tgz of OpenWrt wiki and hand it over to LEDE wiki admins
>> ->
 Imre
 3.) Move LEDE wiki to OpenWrt styling (apply OpenWrt theme and CSS
>> to
 LEDE
 wiki) -> I can do that. Some help of CSS experienced guys could be
 necessary for hard cases.
 4.) Move content of old OpenWrt wiki to new OpenWrt wiki (former
>> LEDE)
 -> I can take the toh part (devicepages); dataentries will be
>> taken
 from LEDE since they are way more up to date and contain more
 datafields.
 -> Rest of the wiki: A plan needs to be worked out what will be
 carried over from old to new OpenWrt wiki -> Community discussion
 
 I'm in the starting blocks since weeks, waiting only for the GO and
>> the
 OpenWrt wiki sources, and I'm sure, we will have some helping heands
 ready to start the wiki merge.
 
 Thomas
 
> -Ursprüngliche Nachricht-
> Von: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] Im
 Auftrag
> von John Crispin
> Gesendet: Freitag, 5. Januar 2018 18:54
> An: LEDE Development List; LEDE Project Administration; OpenWrt
> Development List
> Betreff: [LEDE-DEV] owrt landing page
> 
> Hi,
> 
> could someone please help us with rebranding the lede landing page
>> to
> an openwrt colour/theme ? i would like to see this swithced over
> within the next 7 days.
> 
> John
>>> 
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> 

Re: [LEDE-DEV] Bug? Routes of disabled interfaces appear in routing table

[Paul Oranje]

The common option on an interface that disables/enables it is named "disabled".
Just corrected wiki entry accordingly.

Regards,
Paul

> Op 8 jan. 2018, om 20:06 heeft yanosz  het volgende 
> geschreven:
> 
> Hallo,
> 
> 
> Am 2018-01-08 um 16:41 schrieb Jo-Philipp Wich:
>> Hi yanosz,
>> 
>> "option enabled" is not defined for /etc/config/network, config
>> interface as far as I know. Maybe you meant "option auto 0" instead?
> 
> Interesting. Looking at the docs it is supported:
> https://lede-project.org/docs/user-guide/network_configuration#options_valid_for_all_protocol_types
> 
> If you're we should update the docs.
> 
> Greetz, yanosz
> 
>> 
> 
> -- 
> For those of you without hope, we have rooms with color TV,
> cable and air conditioning
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH v3] kernel: bump 4.4 to 4.4.106 for 17.01

[Paul Oranje]

Is the declared and initialized variable chipnr used otherwise ? (seen since 
4.4.104)
If not, how would that make a difference ?

Regards,
Paul

> Op 19 dec. 2017, om 23:26 heeft Hauke Mehrtens  het 
> volgende geschreven:
> 
> On 12/17/2017 06:56 PM, Kevin Darbyshire-Bryant wrote:
>> 
>> 
>>> On 17 Dec 2017, at 17:22, Etienne Haarsma  wrote:
>>> 
>>> uint8_t *oob = ops->oobbuf;
>>> uint8_t *buf = ops->datbuf;
>>> -@@ -2662,7 +2697,7 @@ err_out:
>>> - static int panic_nand_write(struct mtd_info *mtd, loff_t to, size_t len,
>>> -   size_t *retlen, const uint8_t *buf)
>>> - {
>>> --  struct nand_chip *chip = mtd->priv;
>>> -+  struct nand_chip *chip = mtd_to_nand(mtd);
>>> -   struct mtd_oob_ops ops;
>>> -   int ret;
>>> -
>> 
>> I’m unconvinced this is the correct thing to do - in essence just dropping 
>> that bit of the patch.  Will panic to nand still work?
>> 
>> Kevin
>> 
> Hi,
> 
> I agree, the correct part should look like this:
> 
> @@ -2512,10 +2512,10 @@ Signed-off-by: John Crispin 
>  {
> - struct nand_chip *chip = mtd->priv;
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + int chipnr = (int)(to >> chip->chip_shift);
>   struct mtd_oob_ops ops;
>   int ret;
> -
> -@@ -2722,15 +2757,12 @@ static int nand_do_write_oob(struct mtd_
> 
> @Etienne will you send a new version.
> 
> Hauke
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH netifd] interface-ip: add missing IPv6 policy rule

[Paul Oranje]

git show 2f31bff38d4dc2f36006ded6b8a7d039cb569eaa
yields:
fatal: bad object 2f31bff38d4dc2f36006ded6b8a7d039cb569eaa

Paul

> Op 16 nov. 2017, om 15:42 heeft Hans Dedecker  het 
> volgende geschreven:
> 
> Commit 2f31bff38d4dc2f36006ded6b8a7d039cb569eaa added interface routing
> table support; as a result for IPv6 the prefix route linked to the IPv6
> address is added to the specified IPv6 interface routing table.
> In order to route traffic having as destination the IPv6 prefix a policy
> rule is required using the prefix destination as policy so the traffic is
> passed to the correct routing table.
> The IPv6 prefix address logic was not installing this policy rule effectively
> breaking routing when trying to reach a global or ULA IPv6 address in the
> lan from either the device or another wan device.
> 
> Signed-off-by: Hans Dedecker 
> ---
> interface-ip.c | 22 --
> 1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/interface-ip.c b/interface-ip.c
> index 45ffc66..1490ca4 100644
> --- a/interface-ip.c
> +++ b/interface-ip.c
> @@ -787,6 +787,10 @@ interface_set_prefix_address(struct 
> device_prefix_assignment *assignment,
>   if (!addr.valid_until || addr.valid_until - now > 7200)
>   addr.valid_until = now + 7200;
> 
> + if (iface->ip6table)
> + set_ip_source_policy(false, true, 
> IPRULE_PRIORITY_ADDR_MASK, ,
> + addr.mask < 64 ? 64 : addr.mask, 
> iface->ip6table, NULL, NULL, false);
> +
>   if (prefix->iface) {
>   if (prefix->iface->ip6table)
>   set_ip_source_policy(false, true, 
> IPRULE_PRIORITY_NW, ,
> @@ -803,13 +807,19 @@ interface_set_prefix_address(struct 
> device_prefix_assignment *assignment,
>   } else if (add && (iface->state == IFS_UP || iface->state == IFS_SETUP) 
> &&
>   !system_add_address(l3_downlink, )) {
> 
> - if (prefix->iface && !assignment->enabled) {
> - set_ip_source_policy(true, true, 
> IPRULE_PRIORITY_REJECT, ,
> - addr.mask, 0, iface, "unreachable", 
> true);
> + if (!assignment->enabled) {
> + if (iface->ip6table)
> + set_ip_source_policy(true, true, 
> IPRULE_PRIORITY_ADDR_MASK, ,
> + addr.mask < 64 ? 64 : 
> addr.mask, iface->ip6table, NULL, NULL, false);
> 
> - if (prefix->iface->ip6table)
> - set_ip_source_policy(true, true, 
> IPRULE_PRIORITY_NW, ,
> - addr.mask, 
> prefix->iface->ip6table, iface, NULL, true);
> + if (prefix->iface) {
> + set_ip_source_policy(true, true, 
> IPRULE_PRIORITY_REJECT, ,
> + addr.mask, 0, iface, 
> "unreachable", true);
> +
> + if (prefix->iface->ip6table)
> + set_ip_source_policy(true, true, 
> IPRULE_PRIORITY_NW, ,
> + addr.mask, 
> prefix->iface->ip6table, iface, NULL, true);
> + }
>   }
> 
>   route.metric = iface->metric;
> -- 
> 1.9.1
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] Lede/Openwrt documentation

[Paul Oranje]

M2C:

Wiki's are wonderful for documentation purposes as it allows anyone to 
attribute without much difficulty. But how to ensure that the documentation 
follows project code changes ?

Add to https://lede-project.org/submitting-patches the instruction that any 
change that would have consequences for documentation, be it for users (e.g. 
UCI), be it for developers:
- should mention in the commit message that the change affects user and/or 
developer docs (reviewers should check this)
- should be followed by an update of the wiki once the change has been merged 
(by submitter or someone else)

A more formal approach might be that any commit that changes API (developper 
documentation) or UCI (user documentation) must also contain a patch to that 
effect. A means to apply such a patch (and its format) to the wiki would be 
needed.

Last, assuming we maintain one set of user docs for all branches, the docs 
should, in case the branch matters, document those differences.
The developers documentation would presumably just need to document the master 
branch.

Paul


> Op 12 nov. 2017, om 02:32 heeft Alexander Couzens  het 
> volgende geschreven:
> 
> Here is my IMHO:
> 
> wiki = OpenWrt and LEDE
> 
> The wiki is working for me. it's great to have the ToH. Also the device
> pages are great. However the wiki is not always completely correct and
> may be just wrong. It's a wiki, change it! A wiki is always changing.
> 
> But I still see the case, where I would like to have a documentation
> which is released for a specific version e.g. lede 17.01.
> I think this documentation should cover the base systems [1]. It should
> be describe things in a good and short way.
> And this documentation is reviewed before something changed. So it may
> be "guaranteed" [2] everything is right.
> 
> If it get's to depth into a topic, write it into the wiki.
> Documentation and Wiki would work this way hand in hand. Not erasing
> each other out.
> 
> best
> lynxis
> 
> ps. thanks to everybody who contributed to the wiki and documentation!
> 
> [1] what base system means in this context is to be defined.
> [2] there is no guarantee ;)
> 
> -- 
> Alexander Couzens
> 
> mail: lyn...@fe80.eu
> jabber: lyn...@fe80.eu
> mobile: +4915123277221
> gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
> ___
> 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] Fwd: [FSFE PR][EN] FSFE makes copyrights computer readable

[Paul Oranje]

Would reuse.software (SPDX) be something that could benefit LEDE/OpenWrt ?


> Begin doorgestuurd bericht:
> 
> Van: pr...@fsfe.org
> Onderwerp: [FSFE PR][EN] FSFE makes copyrights computer readable
> Datum: 8 november 2017 11:19:56 CET
> Aan: press-rele...@lists.fsfe.org
> Antwoord aan: pr...@fsfeurope.org, pr...@fsfe.org
> 
> = FSFE makes copyrights computer readable =
> 
> [ Read online: https://fsfe.org/news/2017/news-20171108-01.en.html ]
> 
> The Free Software Foundation Europe (FSFE) is proud to release its next
> version of our REUSE practices [1] designed to make computers understand
> software copyrights and licenses.
> 
> The REUSE practices help software developers make simple additions to
> license headers which make it easier for a computer to determine what
> license applies to the various parts of a programs source code. By
> following the REUSE practices, software developers can ensure their
> intent to license software under a particular license is understood and
> more readily adhered to.
> 
> Together with the updated practices, which mostly clarify and make
> explicit some points, the FSFE is also releasing a set of developer
> tools and examples which show the REUSE practices in action. Three
> example repositories, together with an example walkthrough of the
> process used to make the cURL project REUSE compliant, are complemented
> with a simple tool to validate whether a program is REUSE compliant.
> 
>With our REUSE initiative, we hope to inspire software developers to
>think about writing copyright and license information -- the
>metadata of software -- in ways which make them easier to parse
>programmatically.
> 
>says Jonas Öberg, Executive Director of the FSFE.
> 
> The new REUSE practices and related documentation and examples can be
> found on: https://reuse.software [2].
> 
> == Tags ==
> 
> - front-page [3]
> 
> - reuse [4]
> 
> - software [5]
> 
> - developer-tools [6]
> 
> - update [7]
> 
> - curl [8]
> 
> 1: https://reuse.software/
> 2: https://reuse.software/
> 3: https://fsfe.org/tags/tagged-frontpage.en.html
> 4: https://fsfe.org/tags/tagged-reuse.en.html
> 5: https://fsfe.org/tags/tagged-software.en.html
> 6: https://fsfe.org/tags/tagged-developertools.en.html
> 7: https://fsfe.org/tags/tagged-update.en.html
> 8: https://fsfe.org/tags/tagged-curl.en.html
> 
>  == About the Free Software Foundation Europe ==
> 
>  Free Software Foundation Europe is a charity that empowers users to
>  control technology. Software is deeply involved in all aspects of our
>  lives; and it is important that this technology empowers rather than
>  restricts us. Free Software gives everybody the rights to use,
>  understand, adapt and share software. These rights help support other
>  fundamental freedoms like freedom of speech, press and privacy.
> 
>  The FSFE helps individuals and organisations to understand how Free
>  Software contributes to freedom, transparency, and self-determination.
>  It enhances users' rights by abolishing barriers to Free Software
>  adoption, encourage people to use and develop Free Software, and
>  provide resources to enable everyone to further promote Free Software
>  in Europe.
> 
>  http://fsfe.org
> ___
> Press-release mailing list
> press-rele...@lists.fsfe.org
> https://lists.fsfe.org/mailman/listinfo/press-release


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

Re: [LEDE-DEV] [PATCH] procd: Remove unnecessary memset calls.

[Paul Oranje]

Thanks, also for the link (https://vorpus.org/blog/why-does-calloc-exist/). 
This article made me aware that using calloc() may be wise.

For security reasons: calloc avoids possible arrhythmic overflows when the 
allocation size for malloc is the product of two numbers.
And because it may offer real performance advantages with big allocations: 
calloc() can make good use of the VM syscalls, whereas memset() needs to 
initialise all allocated memory at once which requires that concerned memory is 
paged in, with calloc() memory is allocated sparsely.

The article makes a good argument for using malloc(), but still one should 
agree with Arjen de Korte, that no changes should be made without necessity. 
When I was an active C programmer I was called "de snoeier" (Dutch for pruner) 
and did, to mine and others dismay, introduce errors. Not making errors, even 
with seemingly trivial changes, is hard.
For new code this disadvantage of changing working code is absent ...

Paul


> Op 8 nov. 2017, om 19:59 heeft ros...@gmail.com het volgende geschreven:
> 
> On Wed, 2017-11-08 at 11:57 +0100, Paul Oranje wrote:
>> Both memset() and calloc() have highly optimised implementations, so
>> the expected gains with this patch for the allocation of zeroed
>> memory will be small at best. As this patch does not fix a bug: why
>> is the change "needed" ?
>> 
> Style changes are strictly speaking not "needed".
>> Just curiosity, bye,
>> Paul
>> 
>>> Op 7 nov. 2017, om 21:05 heeft Rosen Penev <ros...@gmail.com> het
>>> volgende geschreven:
>>> 
>>> Changes allocation to calloc and {} as needed.
>>> 
>>> Signed-off-by: Rosen Penev <ros...@gmail.com>
>>> ---
>>> inittab.c  | 6 ++
>>> plug/hotplug.c | 7 ++-
>>> 2 files changed, 4 insertions(+), 9 deletions(-)
>>> 
>>> diff --git a/inittab.c b/inittab.c
>>> index 21172f7..c27c324 100644
>>> --- a/inittab.c
>>> +++ b/inittab.c
>>> @@ -284,8 +284,7 @@ void procd_inittab(void)
>>> 
>>> regcomp(_inittab, "([a-zA-Z0-9]*):([a-zA-Z0-9]*):([a-zA-Z0-
>>> 9]*):(.*)", REG_EXTENDED);
>>> line = malloc(LINE_LEN);
>>> -   a = malloc(sizeof(struct init_action));
>>> -   memset(a, 0, sizeof(struct init_action));
>>> +   a = calloc(1, sizeof(struct init_action));
>>> 
>>> while (fgets(line, LINE_LEN, fp)) {
>>> char *tags[TAG_PROCESS + 1];
>>> @@ -322,8 +321,7 @@ void procd_inittab(void)
>>> if (add_action(a, tags[TAG_ACTION]))
>>> continue;
>>> line = malloc(LINE_LEN);
>>> -   a = malloc(sizeof(struct init_action));
>>> -   memset(a, 0, sizeof(struct init_action));
>>> +   a = calloc(1, sizeof(struct init_action));
>>> }
>>> 
>>> fclose(fp);
>>> diff --git a/plug/hotplug.c b/plug/hotplug.c
>>> index 49c177f..6e55f67 100644
>>> --- a/plug/hotplug.c
>>> +++ b/plug/hotplug.c
>>> @@ -434,12 +434,10 @@ static void handle_button_complete(struct
>>> blob_attr *msg, struct blob_attr *data
>>> if (!name)
>>> return;
>>> 
>>> -   b = malloc(sizeof(*b));
>>> +   b = calloc(1, sizeof(*b));
>>> if (!b)
>>> return;
>>> 
>>> -   memset(b, 0, sizeof(*b));
>>> -
>>> b->data = malloc(blob_pad_len(data));
>>> b->name = strdup(name);
>>> b->seen = timeout;
>>> @@ -584,11 +582,10 @@ void hotplug_last_event(uloop_timeout_handler
>>> handler)
>>> 
>>> void hotplug(char *rules)
>>> {
>>> -   struct sockaddr_nl nls;
>>> +   struct sockaddr_nl nls = {};
>>> int nlbufsize = 512 * 1024;
>>> 
>>> rule_file = strdup(rules);
>>> -   memset(,0,sizeof(struct sockaddr_nl));
>>> nls.nl_family = AF_NETLINK;
>>> nls.nl_pid = getpid();
>>> nls.nl_groups = -1;
>>> -- 
>>> 2.13.6
>>> 
>>> 
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>> 
>> 


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

Re: [LEDE-DEV] [PATCH] procd: Remove unnecessary memset calls.

[Paul Oranje]

Both memset() and calloc() have highly optimised implementations, so the 
expected gains with this patch for the allocation of zeroed memory will be 
small at best. As this patch does not fix a bug: why is the change "needed" ?

Just curiosity, bye,
Paul

> Op 7 nov. 2017, om 21:05 heeft Rosen Penev  het volgende 
> geschreven:
> 
> Changes allocation to calloc and {} as needed.
> 
> Signed-off-by: Rosen Penev 
> ---
> inittab.c  | 6 ++
> plug/hotplug.c | 7 ++-
> 2 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/inittab.c b/inittab.c
> index 21172f7..c27c324 100644
> --- a/inittab.c
> +++ b/inittab.c
> @@ -284,8 +284,7 @@ void procd_inittab(void)
> 
>   regcomp(_inittab, 
> "([a-zA-Z0-9]*):([a-zA-Z0-9]*):([a-zA-Z0-9]*):(.*)", REG_EXTENDED);
>   line = malloc(LINE_LEN);
> - a = malloc(sizeof(struct init_action));
> - memset(a, 0, sizeof(struct init_action));
> + a = calloc(1, sizeof(struct init_action));
> 
>   while (fgets(line, LINE_LEN, fp)) {
>   char *tags[TAG_PROCESS + 1];
> @@ -322,8 +321,7 @@ void procd_inittab(void)
>   if (add_action(a, tags[TAG_ACTION]))
>   continue;
>   line = malloc(LINE_LEN);
> - a = malloc(sizeof(struct init_action));
> - memset(a, 0, sizeof(struct init_action));
> + a = calloc(1, sizeof(struct init_action));
>   }
> 
>   fclose(fp);
> diff --git a/plug/hotplug.c b/plug/hotplug.c
> index 49c177f..6e55f67 100644
> --- a/plug/hotplug.c
> +++ b/plug/hotplug.c
> @@ -434,12 +434,10 @@ static void handle_button_complete(struct blob_attr 
> *msg, struct blob_attr *data
>   if (!name)
>   return;
> 
> - b = malloc(sizeof(*b));
> + b = calloc(1, sizeof(*b));
>   if (!b)
>   return;
> 
> - memset(b, 0, sizeof(*b));
> -
>   b->data = malloc(blob_pad_len(data));
>   b->name = strdup(name);
>   b->seen = timeout;
> @@ -584,11 +582,10 @@ void hotplug_last_event(uloop_timeout_handler handler)
> 
> void hotplug(char *rules)
> {
> - struct sockaddr_nl nls;
> + struct sockaddr_nl nls = {};
>   int nlbufsize = 512 * 1024;
> 
>   rule_file = strdup(rules);
> - memset(,0,sizeof(struct sockaddr_nl));
>   nls.nl_family = AF_NETLINK;
>   nls.nl_pid = getpid();
>   nls.nl_groups = -1;
> -- 
> 2.13.6
> 
> 
> ___
> 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 v5] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

With this patch the dnsmasq init script manages resolv.conf if and only if
when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
Also adds ::1 to the resolver file.

For unbound a likewise patch exists (PR#4454).
Fixes (combined with the unbound PR) FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
The intended invariant is that resolv.conf is managed whenever a resolver
listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well 
(but only when dnsmasq is not already listens on 127.0.0.1#53).
When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 then
resolv.conf is not touched by dnsmasq.

Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
that will run, even when no dnsmasq instance will listen on localhost:53. So
for unbound PR#4454  has been submitted to make sure it always manages
resov.conf when it owns localhost:domain.


Tests performed:

- with/without unbound, dhcp linkages none and dnsmasq
- dnsmasq listens on #53, not #53 (dnsmasq takes precedence when also on #53)
- listen on localhost, not localhost
- noresolv false and true
- one/multiple dnsmasq instances (useless combinations are omitted in testing)

single dnsmasq instance
standard setup
==> dnsmasq manages resolv.conf

two dnsmasq instances, each serving another LAN
both dnsmasq on #53
dnsmasq-2 notinterface loopback
==> dnsmasq-1 manages resolv.conf

two dnsmasq unstances and unbound (dhcp_link: none, one dnsmasq behind ubound)
both dnsmasq on #53
dnsmasq-2 on #53, notinterface loopback
noresolv true and server 127.0.0.1#1053
unbound on #1053
==> dnsmasq-1 manages resolv.conf

two dnsmasq instances and unbound (dhcp_link: dnsmasq)
dnsmasq-1 on #1053, noresolv true
dnsmasq-2 on #2053, noresolv true
unbound on #53
forward LAN1 to 127.0.0.1#1053, forward LAN2 to 127.0.0.1#2053
==> unbound manages resolv.conf

on stops resolv.conf is reset to the auto
   if it was written by the instance resolvfile.


History:
v2  corrected synxtax error
increased PKG_RELEASE
v2  was reverted with commit 8180bbac7c237a31bd6e06c63e342c72342b7303
v3  rewritten and thoroughly tested
v4  corrected test on existence of resolvfile
v5  replaces cat ... case with grep in _resolv_teardown()
rebased on master

Paul
---

 package/network/services/dnsmasq/Makefile  |  2 +-
 .../network/services/dnsmasq/files/dnsmasq.init| 77 +++---
 2 files changed, 53 insertions(+), 26 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index 35ac6b2891..11baff37e8 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.77
-PKG_RELEASE:=4
+PKG_RELEASE:=5
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 065d1fd8c2..c16079d73a 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -714,9 +714,49 @@ dhcp_relay_add() {
fi
 }
 
+_resolv_setup()
+{
+   local cfg="$1"
+   local port notinterfaces
+
+   config_get port "$cfg" port "53"
+   [ $port = "53" ] || return
+
+   config_get notinterfaces "$cfg" notinterface ""
+   [ -n "$notinterfaces" ] && list_contains notinterfaces "loopback" && 
return
+
+   # dnsmasq instance is designated to listen on 127.0.0.1#53.
+   # rewrite /tmp/resolv.conf
+   rm -f /tmp/resolv.conf
+   {
+   echo "# /tmp/resolv.conf generated by dnsmasq $cfg $( date )"
+   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
+   echo "search $DOMAIN"
+   }
+   DNS_SERVERS="$DNS_SERVERS 127.0.0.1 ::1"
+   for DNS_SERVER in $DNS_SERVERS ; do
+   echo "nameserver $DNS_SERVER"
+   done
+   } > /tmp/resolv.conf
+
+   return
+}
+
+_resolv_teardown()
+{
+   cfg="$1"
+
+   grep -q -e "generated by dnsmasq $cfg" /tmp/resolv.conf 2>/dev/null && {
+   # resolv.conf was written by this instance,
+   # reset /tmp/resolv.conf to default.
+   [ -f /tmp/resolv.conf ] && rm -f /tmp/resolv.conf
+   ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
+   }
+}
+
 dnsmasq_start()
 {
-   local cfg="$1" disabled resolvfile user_dhcpscript
+   local cfg="$1" disabled noresolv resolvfile user_dhcpscri

Re: [LEDE-DEV] [PATCH v4] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

Please see in-line,
regards,
Paul


> Op 22 jun. 2017, om 17:09 heeft Hans Dedecker <dedec...@gmail.com> het 
> volgende geschreven:
> 
> On Thu, Jun 22, 2017 at 12:52 PM, Paul Oranje <p...@xs4all.nl> wrote:
>> Hello Hans,
>> So far I did not see a patchwork message on the latest submission.
>> Just a direct quick question: did something go wrong here ?
>> Paul
> Hi Paul,
> 
> I've been discussing the patch with jow on the IIRC channel yesterday;
> the patch has become highly discutable for different reasons.
> As already mentioned by me he mentioned the use case of DNAT (thus not
> listening on port 53); also in his opinion we should first create a
> resolv service which allows to change the resolv file in an atomic way
> and then adapt the services.
I have considered these issues (port rewrites and atomiticity), but thought it 
wiser to handle the rewrite use-case in a separate patch.

About supporting the port rewrite use-case:
It seems a not very likely use-case, but to be able to designate a resolver for 
the local processes (thus is to be refered to in resolv.conf) when it does 
**not** listen directly on port 127.0.0.1#53 and do that without having to 
parse the firewall for port redirection rules (, probably an extra UCI dnsmasq 
option will be needed that just assigns that role and overrules any other 
selection criteria (listens on 127.0.0.1#53). The ratio is that this will 
support very specific set-ups that aren't easily anticipated and leaving the 
decision to the administrator is more prudent in those cases.
In the cases that a non-local resolver is to be referred to from resolv.conf, 
dnsmasq just has no role. The resolvfile is then likely generated somehow 
outside of its scope anyway.

About atomicity of resolv.conf handling:
As long as resolv.conf is changed only **after** the resolver service has been 
started (and is reset before the service stops), the likelihood of some race 
condition that would cause a local proces try to resolve against a 
non-yet-listening resolver, will be very slim (when resolver daemon fails to 
start; code does not check that). Creation of a separate resolv.conf 
handler/service (extension of netifd as it already handles the WAN ifup/down 
case) may offer a generic and guaranteed atomic handling, would be nice, but it 
would surprise me if that were needed urgently.

> In the patch I noticed the cat which I don't really like in the
> _resolv_teardown, a grep looks more appropriate.
No problem, that is easily changed.

> But jow also  pointed
> out that $cfg cannot be used as identifier as uci can reorder the
> different sections resulting into a different identifier.
Okay, but ...
When one is having a dnsmasq configuration with multiple instances, one is 
likely to have named each section specifically; doing so offers an easy 
work-around for these quite specific cases.
Besides, this obstacle equally affects the daemon's PID handling, because the 
run PID file is named /var/run/dnsmasq/dnsmasq.$cfg.pid.

> The handling of resolv.conf has been ugly since it has been created;
> but in jows opinion the patch as it's now won't improve the current
> situation
Pity to read that.
The current implementation definitely has some errors that are fixed with the 
patch (see LEDE FS#785) and with respect to the problems named "highly 
discutable", the submitted patch does not make those worse. To the contrary, 
the point of handling of resolv.conf has explicitly been moved in the program 
flow such (at start last, at stop first) that it avoids possible races in the 
current code.

> Hans
>> 
>> p.s.
>> When and when not to raise the patch version number is not really clear to 
>> me.
>> 
>> 
>>> Op 21 jun. 2017, om 14:42 heeft Paul Oranje <p...@xs4all.nl> het volgende 
>>> geschreven:
>>> 
>>> With this patch the dnsmasq init script manages resolv.conf if and only if
>>> when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
>>> Also adds ::1 to the resolver file.
>>> 
>>> For unbound a likewise patch exists (PR#4454).
>>> Fixes (combined with the unbound PR) FS#785
>>> 
>>> Signed-off-by: Paul Oranje <p...@xs4all.nl>
>>> ---
>>> The intended invariant is that resolv.conf is managed whenever a resolver
>>> listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well
>>> (but only when dnsmasq is not already listens on 127.0.0.1#53).
>>> When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 
>>> then
>>> resolv.conf is not touched by dnsmasq.
>>> 
>>> Currently unbound handles resolv.conf also, but leaves it to dnsmasq 
>>> whenever
>>> that will run, even when no dnsmasq i

[LEDE-DEV] [PATCH v4] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

With this patch the dnsmasq init script manages resolv.conf if and only if
when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
Also adds ::1 to the resolver file.

For unbound a likewise patch exists (PR#4454).
Fixes (combined with the unbound PR) FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
The intended invariant is that resolv.conf is managed whenever a resolver
listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well 
(but only when dnsmasq is not already listens on 127.0.0.1#53).
When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 then
resolv.conf is not touched by dnsmasq.

Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
that will run, even when no dnsmasq instance will listen on localhost:53. So
for unbound PR#4454  has been submitted to make sure it always manages
resov.conf when it owns localhost:domain.


Tests performed:

- with/without unbound, dhcp linkages none and dnsmasq
- dnsmasq listens on #53, not #53 (dnsmasq takes precedence when also on #53)
- listen on localhost, not localhost
- noresolv false and true
- one/multiple dnsmasq instances (useless combinations are omitted in testing)

single dnsmasq instance
standard setup
==> dnsmasq manages resolv.conf

two dnsmasq instances, each serving another LAN
both dnsmasq on #53
dnsmasq-2 notinterface loopback
==> dnsmasq-1 manages resolv.conf

two dnsmasq unstances and unbound (dhcp_link: none, one dnsmasq behind ubound)
both dnsmasq on #53
dnsmasq-2 on #53, notinterface loopback
noresolv true and server 127.0.0.1#1053
unbound on #1053
==> dnsmasq-1 manages resolv.conf

two dnsmasq instances and unbound (dhcp_link: dnsmasq)
dnsmasq-1 on #1053, noresolv true
dnsmasq-2 on #2053, noresolv true
unbound on #53
forward LAN1 to 127.0.0.1#1053, forward LAN2 to 127.0.0.1#2053
==> unbound manages resolv.conf

on stops resolv.conf is reset to the auto resolvfile.


History:
v1 -> v2corrected synxtax error
increased PKG_RELEASE
v2  reverted with commit 8180bbac7c237a31bd6e06c63e342c72342b7303
v2 -> v3rewritten and thoroughly tested
v3 -> v4corrected test on existence of resolvfile (thanks e9hack)

Paul
---
 package/network/services/dnsmasq/Makefile  |  2 +-
 .../network/services/dnsmasq/files/dnsmasq.init| 79 +++---
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index f9ab13aef0..35ac6b2891 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.77
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index d5177ecb0c..f22d5c3257 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -707,9 +707,51 @@ dhcp_relay_add() {
fi
 }
 
+_resolv_setup()
+{
+   local cfg="$1"
+   local port notinterfaces
+
+   config_get port "$cfg" port "53"
+   [ $port = "53" ] || return
+
+   config_get notinterfaces "$cfg" notinterface ""
+   [ -n "$notinterfaces" ] && list_contains notinterfaces "loopback" && 
return
+
+   # dnsmasq instance is designated to listen on 127.0.0.1#53.
+   # rewrite /tmp/resolv.conf
+   rm -f /tmp/resolv.conf
+   {
+   echo "# /tmp/resolv.conf generated by dnsmasq $cfg $( date )"
+   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
+   echo "search $DOMAIN"
+   }
+   DNS_SERVERS="$DNS_SERVERS 127.0.0.1 ::1"
+   for DNS_SERVER in $DNS_SERVERS ; do
+   echo "nameserver $DNS_SERVER"
+   done
+   } > /tmp/resolv.conf
+
+   return
+}
+
+_resolv_teardown()
+{
+   cfg="$1"
+
+   case $( cat /tmp/resolv.conf ) in
+   *"generated by dnsmasq $cfg"*)
+   # resolv.conf was written by this instance,
+   # reset /tmp/resolv.conf to default.
+   [ -f /tmp/resolv.conf ] && rm -f /tmp/resolv.conf
+   ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
+   ;;
+   esac
+}
+
 dnsmasq_start()
 {
-   local cfg="$1" disabled resolvfile user_dhcpscript
+   local cfg="$1" disabled noresolv resolvfile user_dhcpscript
 
config_get_bool disabled "$cfg" d

Re: [LEDE-DEV] [PATCH v3] dnsmasq: manage resolv.conf if when listening on 127.0.0.1#53

[Paul Oranje]

You are absolutely right.
Thanks, I post an update of the patch.
Paul


> Op 20 jun. 2017, om 16:41 heeft e9hack <e9h...@gmail.com> het volgende 
> geschreven:
> 
> Am 18.06.2017 um 09:46 schrieb Paul Oranje:
>> @@ -854,14 +895,15 @@ dnsmasq_start()
>>  config_get_bool cachelocal "$cfg" cachelocal 1
>> 
>>  config_get_bool noresolv "$cfg" noresolv 0
>> -if [ "$noresolv" != "1" ]; then
>> +if [ "$noresolv" = "1" ]; then
>> +xappend "--no-resolv"
>> +else
>>  config_get resolvfile "$cfg" resolvfile "/tmp/resolv.conf.auto"
>> +xappend "--resolv-file=$resolvfile"
>>  # So jail doesn't complain if file missing
>> -[ -n "$resolvfile" -a \! -e "$resolvfile" ] && touch 
>> "$resolvfile"
>> +[ -e "$resolvfile" ] && touch "$resolvfile"
> 
> Are your sure, that the last line is correct? I'm missing a NOT in the test.
> 
> If option resolvfile is not given and multiple configuration does exist, 
> every instance updates the same resolve file.
> Wouldn't it be better to use unique file names?
> 
> Regards,
> Hartmut
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH v3] dnsmasq: manage resolv.conf if when listening on 127.0.0.1#53

[Paul Oranje]

For those that want to test the dnsmasq patch on LEDE 17.01, see the attached 
patch file adapted for 17.01(.2).
In the LEDE source root dir:

git apply 
0001-dnsmasq-manage-resolv.conf-iff-when-listening-on-127-lede-17.01.2.patch

For those that also want to test the accompanying unbound patch on LEDE 17.01, 
see the attached patch file adapted for 17.01(.2).
In the feeds/packages dir:

git apply 0001-unbound-manage-resolv.conf-iff-when-listening-on-127-17.01.patch

Good luck,
Paul

> Op 19 jun. 2017, om 21:08 heeft Ben Pfountz <netpri...@vt.edu> het volgende 
> geschreven:
> 
> I tested this patch with a standard install, as well as with noresolv=1 and 2 
> servers configured with opendns, and it worked fine. /etc/resolv.conf still 
> correctly listed 127.0.0.1 and ::1 as the local nameserver.
> 
> Ben
> 
> On 6/19/2017 6:16 AM, Paul Oranje wrote:
>> this patch has been resend with corrected title (not "if", but "iff")
>> sorry for the spamming
>>> Op 18 jun. 2017, om 09:46 heeft Paul Oranje <p...@xs4all.nl> het volgende 
>>> geschreven:
>>> 
>>> With this patch the dnsmasq init script manages resolv.conf if and only if
>>> when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
>>> Also adds ::1 to the resolver file.
>>> 
>>> For unbound a likewise patch exists (PR#4454).
>>> Fixes (combined with the unbound PR) FS#785
>>> 
>>> Signed-off-by: Paul Oranje <p...@xs4all.nl>
>>> ---
>>> The intended invariant is that resolv.conf is managed whenever a resolver
>>> listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well
>>> (but only when dnsmasq is not already listens on 127.0.0.1#53).
>>> When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 
>>> then
>>> resolv.conf is not touched by dnsmasq.
>>> 
>>> Currently unbound handles resolv.conf also, but leaves it to dnsmasq 
>>> whenever
>>> that will run, even when no dnsmasq instance will listen on localhost:53. So
>>> for unbound PR#4454  has been submitted to make sure it always manages
>>> resov.conf when it owns localhost:domain.
>>> 
>>> 
>>> Tests performed:
>>> 
>>> - with/without unbound, dhcp linkages none and dnsmasq
>>> - dnsmasq listens on #53, not #53 (dnsmasq takes precedence when also on 
>>> #53)
>>> - listen on localhost, not localhost
>>> - noresolv false and true
>>> - one/multiple dnsmasq instances (useless combinations are omitted in 
>>> testing)
>>> 
>>> single dnsmasq instance
>>>standard setup
>>> ==> dnsmasq manages resolv.conf
>>> 
>>> two dnsmasq instances, each serving another LAN
>>>both dnsmasq on #53
>>>dnsmasq-2 notinterface loopback
>>> ==> dnsmasq-1 manages resolv.conf
>>> 
>>> two dnsmasq unstances and unbound (dhcp_link: none, one dnsmasq behind 
>>> ubound)
>>>both dnsmasq on #53
>>>dnsmasq-2 on #53, notinterface loopback
>>>noresolv true and server 127.0.0.1#1053
>>>unbound on #1053
>>> ==> dnsmasq-1 manages resolv.conf
>>> 
>>> two dnsmasq instances and unbound (dhcp_link: dnsmasq)
>>>dnsmasq-1 on #1053, noresolv true
>>>dnsmasq-2 on #2053, noresolv true
>>>unbound on #53
>>>forward LAN1 to 127.0.0.1#1053, forward LAN2 to 127.0.0.1#2053
>>> ==> unbound manages resolv.conf
>>> 
>>> on init stops resolv.conf is reset to the auto resolvfile.
>>> 
>>> 
>>> History:
>>> v1 -> v2corrected synxtax error
>>> increased PKG_RELEASE
>>> v2  reverted with commit 8180bbac7c237a31bd6e06c63e342c72342b7303
>>> v3  corected errors, setup/teardown routines and thoroughly tested
>>> 
>>> Paul
>>> 
>>> 
>>> package/network/services/dnsmasq/Makefile  |  2 +-
>>> .../network/services/dnsmasq/files/dnsmasq.init| 79 
>>> +++---
>>> 2 files changed, 55 insertions(+), 26 deletions(-)
>>> 
>>> diff --git a/package/network/services/dnsmasq/Makefile 
>>> b/package/network/services/dnsmasq/Makefile
>>> index f9ab13aef0..35ac6b2891 100644
>>> --- a/package/network/services/dnsmasq/Makefile
>>> +++ b/package/network/services/dnsmasq/Makefile
>>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>>> 
>>> PKG_NAME:=dnsmasq
>>> PKG_V

Re: [LEDE-DEV] [PATCH v3] dnsmasq: manage resolv.conf if when listening on 127.0.0.1#53

[Paul Oranje]

this patch has been resend with corrected title (not "if", but "iff")
sorry for the spamming

> Op 18 jun. 2017, om 09:46 heeft Paul Oranje <p...@xs4all.nl> het volgende 
> geschreven:
> 
> With this patch the dnsmasq init script manages resolv.conf if and only if
> when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
> Also adds ::1 to the resolver file.
> 
> For unbound a likewise patch exists (PR#4454).
> Fixes (combined with the unbound PR) FS#785
> 
> Signed-off-by: Paul Oranje <p...@xs4all.nl>
> ---
> The intended invariant is that resolv.conf is managed whenever a resolver
> listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well 
> (but only when dnsmasq is not already listens on 127.0.0.1#53).
> When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 then
> resolv.conf is not touched by dnsmasq.
> 
> Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
> that will run, even when no dnsmasq instance will listen on localhost:53. So
> for unbound PR#4454  has been submitted to make sure it always manages
> resov.conf when it owns localhost:domain.
> 
> 
> Tests performed:
> 
> - with/without unbound, dhcp linkages none and dnsmasq
> - dnsmasq listens on #53, not #53 (dnsmasq takes precedence when also on #53)
> - listen on localhost, not localhost
> - noresolv false and true
> - one/multiple dnsmasq instances (useless combinations are omitted in testing)
> 
> single dnsmasq instance
>standard setup
> ==> dnsmasq manages resolv.conf
> 
> two dnsmasq instances, each serving another LAN
>both dnsmasq on #53
>dnsmasq-2 notinterface loopback
> ==> dnsmasq-1 manages resolv.conf
> 
> two dnsmasq unstances and unbound (dhcp_link: none, one dnsmasq behind ubound)
>both dnsmasq on #53
>dnsmasq-2 on #53, notinterface loopback
>noresolv true and server 127.0.0.1#1053
>unbound on #1053
> ==> dnsmasq-1 manages resolv.conf
> 
> two dnsmasq instances and unbound (dhcp_link: dnsmasq)
>dnsmasq-1 on #1053, noresolv true
>dnsmasq-2 on #2053, noresolv true
>unbound on #53
>forward LAN1 to 127.0.0.1#1053, forward LAN2 to 127.0.0.1#2053
> ==> unbound manages resolv.conf
> 
> on init stops resolv.conf is reset to the auto resolvfile.
> 
> 
> History:
> v1 -> v2corrected synxtax error
>   increased PKG_RELEASE
> v2reverted with commit 8180bbac7c237a31bd6e06c63e342c72342b7303
> v3corected errors, setup/teardown routines and thoroughly tested
> 
> Paul
> 
> 
> package/network/services/dnsmasq/Makefile  |  2 +-
> .../network/services/dnsmasq/files/dnsmasq.init| 79 +++---
> 2 files changed, 55 insertions(+), 26 deletions(-)
> 
> diff --git a/package/network/services/dnsmasq/Makefile 
> b/package/network/services/dnsmasq/Makefile
> index f9ab13aef0..35ac6b2891 100644
> --- a/package/network/services/dnsmasq/Makefile
> +++ b/package/network/services/dnsmasq/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> 
> PKG_NAME:=dnsmasq
> PKG_VERSION:=2.77
> -PKG_RELEASE:=3
> +PKG_RELEASE:=4
> 
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
> PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index d5177ecb0c..2a4d7b2239 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -707,9 +707,51 @@ dhcp_relay_add() {
>   fi
> }
> 
> +_resolv_setup()
> +{
> + local cfg="$1"
> + local port notinterfaces
> +
> + config_get port "$cfg" port "53"
> + [ $port = "53" ] || return
> +
> + config_get notinterfaces "$cfg" notinterface ""
> + [ -n "$notinterfaces" ] && list_contains notinterfaces "loopback" && 
> return
> +
> + # dnsmasq instance is designated to listen on 127.0.0.1#53.
> + # rewrite /tmp/resolv.conf
> + rm -f /tmp/resolv.conf
> + {
> + echo "# /tmp/resolv.conf generated by dnsmasq $cfg $( date )"
> + [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
> + echo "search $DOMAIN"
> + }
> + DNS_SERVERS="$DNS_SERVERS 127.0.0.1 ::1"
> + for DNS_SERVER in $DNS_SERVERS ; do
> + echo "nameserver $DNS_SERVER"
> + done
> + } >

[LEDE-DEV] [PATCH v3] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

With this patch the dnsmasq init script manages resolv.conf if and only if
when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
Also adds ::1 to the resolver file.

For unbound a likewise patch exists (PR#4454).
Fixes (combined with the unbound PR) FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
The intended invariant is that resolv.conf is managed whenever a resolver
listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well 
(but only when dnsmasq is not already listens on 127.0.0.1#53).
When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 then
resolv.conf is not touched by dnsmasq.

Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
that will run, even when no dnsmasq instance will listen on localhost:53. So
for unbound PR#4454  has been submitted to make sure it always manages
resov.conf when it owns localhost:domain.


Tests performed:

- with/without unbound, dhcp linkages none and dnsmasq
- dnsmasq listens on #53, not #53 (dnsmasq takes precedence when also on #53)
- listen on localhost, not localhost
- noresolv false and true
- one/multiple dnsmasq instances (useless combinations are omitted in testing)

single dnsmasq instance
standard setup
==> dnsmasq manages resolv.conf

two dnsmasq instances, each serving another LAN
both dnsmasq on #53
dnsmasq-2 notinterface loopback
==> dnsmasq-1 manages resolv.conf

two dnsmasq unstances and unbound (dhcp_link: none, one dnsmasq behind ubound)
both dnsmasq on #53
dnsmasq-2 on #53, notinterface loopback
noresolv true and server 127.0.0.1#1053
unbound on #1053
==> dnsmasq-1 manages resolv.conf

two dnsmasq instances and unbound (dhcp_link: dnsmasq)
dnsmasq-1 on #1053, noresolv true
dnsmasq-2 on #2053, noresolv true
unbound on #53
forward LAN1 to 127.0.0.1#1053, forward LAN2 to 127.0.0.1#2053
==> unbound manages resolv.conf

on stops resolv.conf is reset to the auto resolvfile.


History:
v1 -> v2corrected synxtax error
increased PKG_RELEASE
v2  reverted with commit 8180bbac7c237a31bd6e06c63e342c72342b7303
v3  rewritten and thoroughly tested
corrected title ("iff", i.e. if and only if, i.s.o. "if")

Paul

---
 package/network/services/dnsmasq/Makefile  |  2 +-
 .../network/services/dnsmasq/files/dnsmasq.init| 79 +++---
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index f9ab13aef0..35ac6b2891 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.77
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index d5177ecb0c..2a4d7b2239 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -707,9 +707,51 @@ dhcp_relay_add() {
fi
 }
 
+_resolv_setup()
+{
+   local cfg="$1"
+   local port notinterfaces
+
+   config_get port "$cfg" port "53"
+   [ $port = "53" ] || return
+
+   config_get notinterfaces "$cfg" notinterface ""
+   [ -n "$notinterfaces" ] && list_contains notinterfaces "loopback" && 
return
+
+   # dnsmasq instance is designated to listen on 127.0.0.1#53.
+   # rewrite /tmp/resolv.conf
+   rm -f /tmp/resolv.conf
+   {
+   echo "# /tmp/resolv.conf generated by dnsmasq $cfg $( date )"
+   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
+   echo "search $DOMAIN"
+   }
+   DNS_SERVERS="$DNS_SERVERS 127.0.0.1 ::1"
+   for DNS_SERVER in $DNS_SERVERS ; do
+   echo "nameserver $DNS_SERVER"
+   done
+   } > /tmp/resolv.conf
+
+   return
+}
+
+_resolv_teardown()
+{
+   cfg="$1"
+
+   case $( cat /tmp/resolv.conf ) in
+   *"generated by dnsmasq $cfg"*)
+   # resolv.conf was written by this instance,
+   # reset /tmp/resolv.conf to default.
+   [ -f /tmp/resolv.conf ] && rm -f /tmp/resolv.conf
+   ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
+   ;;
+   esac
+}
+
 dnsmasq_start()
 {
-   local cfg="$1" disabled resolvfile user_dhcpscript
+   local cfg="$1" disabled noresolv resolvfile user_dhcpscript
 
config_get_bool disabled &quo

[LEDE-DEV] [PATCH v3] dnsmasq: manage resolv.conf if when listening on 127.0.0.1#53

[Paul Oranje]

With this patch the dnsmasq init script manages resolv.conf if and only if
when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
Also adds ::1 to the resolver file.

For unbound a likewise patch exists (PR#4454).
Fixes (combined with the unbound PR) FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
The intended invariant is that resolv.conf is managed whenever a resolver
listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well 
(but only when dnsmasq is not already listens on 127.0.0.1#53).
When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 then
resolv.conf is not touched by dnsmasq.

Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
that will run, even when no dnsmasq instance will listen on localhost:53. So
for unbound PR#4454  has been submitted to make sure it always manages
resov.conf when it owns localhost:domain.


Tests performed:

- with/without unbound, dhcp linkages none and dnsmasq
- dnsmasq listens on #53, not #53 (dnsmasq takes precedence when also on #53)
- listen on localhost, not localhost
- noresolv false and true
- one/multiple dnsmasq instances (useless combinations are omitted in testing)

single dnsmasq instance
standard setup
==> dnsmasq manages resolv.conf

two dnsmasq instances, each serving another LAN
both dnsmasq on #53
dnsmasq-2 notinterface loopback
==> dnsmasq-1 manages resolv.conf

two dnsmasq unstances and unbound (dhcp_link: none, one dnsmasq behind ubound)
both dnsmasq on #53
dnsmasq-2 on #53, notinterface loopback
noresolv true and server 127.0.0.1#1053
unbound on #1053
==> dnsmasq-1 manages resolv.conf

two dnsmasq instances and unbound (dhcp_link: dnsmasq)
dnsmasq-1 on #1053, noresolv true
dnsmasq-2 on #2053, noresolv true
unbound on #53
forward LAN1 to 127.0.0.1#1053, forward LAN2 to 127.0.0.1#2053
==> unbound manages resolv.conf

on init stops resolv.conf is reset to the auto resolvfile.


History:
v1 -> v2corrected synxtax error
increased PKG_RELEASE
v2  reverted with commit 8180bbac7c237a31bd6e06c63e342c72342b7303
v3  corected errors, setup/teardown routines and thoroughly tested

Paul


 package/network/services/dnsmasq/Makefile  |  2 +-
 .../network/services/dnsmasq/files/dnsmasq.init| 79 +++---
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index f9ab13aef0..35ac6b2891 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.77
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index d5177ecb0c..2a4d7b2239 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -707,9 +707,51 @@ dhcp_relay_add() {
fi
 }
 
+_resolv_setup()
+{
+   local cfg="$1"
+   local port notinterfaces
+
+   config_get port "$cfg" port "53"
+   [ $port = "53" ] || return
+
+   config_get notinterfaces "$cfg" notinterface ""
+   [ -n "$notinterfaces" ] && list_contains notinterfaces "loopback" && 
return
+
+   # dnsmasq instance is designated to listen on 127.0.0.1#53.
+   # rewrite /tmp/resolv.conf
+   rm -f /tmp/resolv.conf
+   {
+   echo "# /tmp/resolv.conf generated by dnsmasq $cfg $( date )"
+   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
+   echo "search $DOMAIN"
+   }
+   DNS_SERVERS="$DNS_SERVERS 127.0.0.1 ::1"
+   for DNS_SERVER in $DNS_SERVERS ; do
+   echo "nameserver $DNS_SERVER"
+   done
+   } > /tmp/resolv.conf
+
+   return
+}
+
+_resolv_teardown()
+{
+   cfg="$1"
+
+   case $( cat /tmp/resolv.conf ) in
+   *"generated by dnsmasq $cfg"*)
+   # resolv.conf was written by this instance,
+   # reset /tmp/resolv.conf to default.
+   [ -f /tmp/resolv.conf ] && rm -f /tmp/resolv.conf
+   ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
+   ;;
+   esac
+}
+
 dnsmasq_start()
 {
-   local cfg="$1" disabled resolvfile user_dhcpscript
+   local cfg="$1" disabled noresolv resolvfile user_dhcpscript
 
config_get_bool disabled "$cfg" disabled 0
[ "$disabled" -gt 0 ]

[LEDE-DEV] [PATCH] dnsmasq: fix error in call of list_contains()

[Paul Oranje]

Fixes the first parameter to the call of list_contains() in dnsmasq_ismain()

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
Commit a53f8ba6771de64c9c82a2e6867791226f3003cb introduces an error that has not
shown up in my tests of that commit (testing sh script is tough).
Thanks to Hartmut (e9hack).
---
 package/network/services/dnsmasq/Makefile   | 2 +-
 package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index 35ac6b2891..11baff37e8 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.77
-PKG_RELEASE:=4
+PKG_RELEASE:=5
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index fda11401db..8dc11288af 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -716,7 +716,7 @@ dnsmasq_ismain()
[ $port = "53" ] || return 1
 
config_get notinterfaces "$cfg" notinterface ""
-   [ -n $notinterfaces ] && list_contains $notinterfaces "loopback" || 
return 1
+   [ -n $notinterfaces ] && list_contains notinterfaces "loopback" || 
return 1
 
# dnsmasq instance is designated to listen on 127.0.0.1#53.
return 0
-- 
2.13.1


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

[LEDE-DEV] [PATCH] dnsmasq: fix error in call of list_contains()

[Paul Oranje]

Fixes the first parameter to the call of list_contains() in dnsmasq_ismain()

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
Commit a53f8ba6771de64c9c82a2e6867791226f3003cb introduces an error that has not
shown up in my tests of that commit (testing sh script is tough).
Thanks to Hartmut (e9hack).
---
 package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index fda11401db..8dc11288af 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -716,7 +716,7 @@ dnsmasq_ismain()
[ $port = "53" ] || return 1
 
config_get notinterfaces "$cfg" notinterface ""
-   [ -n $notinterfaces ] && list_contains $notinterfaces "loopback" || 
return 1
+   [ -n $notinterfaces ] && list_contains notinterfaces "loopback" || 
return 1
 
# dnsmasq instance is designated to listen on 127.0.0.1#53.
return 0
-- 
2.13.1


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

Re: [LEDE-DEV] [PATCH] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

Thanks, did not show up im my tests. (damm, sh script is difficult to test 
well).
I'll post a patch to fix that.

Paul


> Op 12 jun. 2017, om 21:46 heeft e9hack  het volgende 
> geschreven:
> 
> 
> Hi,
> 
> there is a bug in dnsmasq_ismain(). The first parameter in the call of 
> list_contains() must be the variable which
> contains the list and not the list itself.
> 
> [ -n $notinterfaces ] && list_contains $notinterfaces "loopback" || return 1
> 
> $notinterfaces must be replace by notinterfaces.
> 
> 
> Regards,
> Hartmut
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH v2] ramips: add support for Ubiquiti EdgeRouter X-SFP

[Paul Oranje]

Isn't this related to FS#764 ?


> Op 12 jun. 2017, om 20:14 heeft p.wa...@gmx.at het volgende geschreven:
> 
> Ok - I've got some interesting news.
> First, the stalls started to appear on multiple CPUs/tasks simultaneously:
> (find an excerpt from dmesg under [1]).
> 
> For further testing, I've disabled SQM, rebooted and whoaa...
> These kernel errors are gone. Running fine since 13 hours.
> So it seems that it's not an issue with the Edgerouters but with SQM.
> 
> My SQM configuration was basically just using cake + piece_of_cake.qos,
> but that's clearly off topic for now. (I'm also CC'ing this mail to Toke,
> the maintainer of sqm-scripts).
> 
> Regards,
> P. Wassi
> 
> [1]:
>> [  260.61] Task dump for CPU 2:
>> [  334.23] Task dump for CPU 2:
>> [  399.34] Task dump for CPU 2:
>> [  579.39] Task dump for CPU 2:
>> [13074.72] Task dump for CPU 2:
>> [13074.85] Task dump for CPU 3:
>> [30220.46] Task dump for CPU 2:
>> [30220.59] Task dump for CPU 3:
>> [52142.07] Task dump for CPU 2:
>> [52142.20] Task dump for CPU 3:
>> [59972.98] Task dump for CPU 2:
>> [59973.11] Task dump for CPU 3:
>> [70239.02] Task dump for CPU 2:
>> [70239.15] Task dump for CPU 3:
>> [93181.85] Task dump for CPU 2:
>> [93181.98] Task dump for CPU 3:
>> [113636.63] Task dump for CPU 2:
>> [113636.76] Task dump for CPU 3:
>> [136534.46] Task dump for CPU 2:
>> [136534.59] Task dump for CPU 3:
>> [156163.23] Task dump for CPU 2:
>> [156163.36] Task dump for CPU 3:
>> [173499.28] Task dump for CPU 2:
>> [173499.41] Task dump for CPU 3:
>> [173873.73] Task dump for CPU 2:
>> [173873.86] Task dump for CPU 3:
>> [181271.62] Task dump for CPU 0:
>> [181271.62] Task dump for CPU 2:
>> [181271.62] Task dump for CPU 3:
>> [181271.62] Task dump for CPU 0:
>> [189143.29] Task dump for CPU 2:
>> [189143.42] Task dump for CPU 3:
>> [207190.15] Task dump for CPU 2:
>> [207190.28] Task dump for CPU 3:
> 
> 
> --
> 
>> 
>> On 09/06/17 08:48, p.wa...@gmx.at wrote:
>>> Hi guys,
>>> 
>>> I may be hijacking this specific thread, but as 'testing' was mentioned 
>>> here...
>>> I'm running an Edgerouter X since yesterday (not the -SPF version!) on LEDE 
>>> r4356
>>> and am getting these kernel errors/warnings every five minutes or so:
>> 
>> Hi,
>> 
>> can you try with v4.9 please ?
>> 
>> John
>> 
 [  470.41] INFO: rcu_sched detected stalls on CPUs/tasks:
 [  470.42] 1-...: (127 GPs behind) idle=ee6/0/0 softirq=9641/9643 
 fqs=1
 [  470.43] (detected by 3, t=6004 jiffies, g=898, c=897, q=606)
 [  470.44] Task dump for CPU 1:
 [  470.45] swapper/1   R running  0 0  1 0x0010
 [  470.46] Stack :  0e406087 006d  0061 
 7795a2c0 804df2a4 8049
 [  470.46]   8048c75c 0001 0001 8048c540 8048c724 8049 
  800135e4
 [  470.46]   1100fc03 0003 8fc7 8fc71ec0 8049 8005ecc8 
 1100fc03 0001
 [  470.46]    8049 804df2a4 8005ecc0 8049 8001b1a8 
 1100fc03 
 [  470.46]   0004 8048c4a0 00a0 8001b1b0 b6fd a02eacbf 
 5d3cafc3 7dbbdccc
 [  470.46]   ...
 [  470.53] Call Trace:
 [  470.54] [<8000be98>] __schedule+0x574/0x758
 [  470.55] [<800135e4>] r4k_wait_irqoff+0x0/0x20
 [  470.55]
 [  470.56] rcu_sched kthread starved for 6016 jiffies! g898 c897 f0x0 
 s3 ->state=0x1
>>> Kernel is 4.4.71
>>> 
>>> Also, just while editing a config file the router rebooted.
>>> Does someone else also have this issue?
>>> 
>>> Best regards,
>>> P. Wassi
>>> 
>>> 
 On 07/06/17 12:10, John Crispin wrote:
 
 
 On 07/06/17 01:36, Sven Roederer wrote:
> John,
> 
> just checked with master build f500799 as initrd-kernel. Looks fine as
> I can see from bootlog.
> Anything special to test?
> 
> [1.71] MediaTek Nand driver init, version v2.1 Fix AHB virt2phys 
> error
> [1.72] Allocate 16 byte aligned buffer: 80592f90
> [1.73] Enable NFI Clock
> [1.74] # MTK NAND # : Use HW ECC
> [1.74] Device found in MTK table, ID: 1da, EXT_ID: 909546
> [1.76] Support this Device in MTK table! 1da
> [1.77] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xda
> [1.78] nand: AMD/Spansion NAND 256MiB 3,3V 8-bit
> [1.79] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, 
> OOB size: 128
> [1.80] [NAND]select ecc bit:12, sparesize :112 spare_per_sector=28
> [1.82] Scanning device for bad blocks
> [2.52] 6 ofpart partitions found on MTD device MT7621-NAND
> [2.53] Creating 6 MTD partitions on "MT7621-NAND":
> [2.54] 

Re: [LEDE-DEV] [PATCH] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

Did the change break existing code ?

What I did understand about the dnsmasq options --resolv-file (UCI 
dhcp:dnsmasq.resolvfile) and --no-resolv (UCI dhcp:dnsmasq.noresolv) is:

- the --no-resolv option governs whether dnsmasq ignores the nameservers listed 
in the resolvfile.
- the resolvfile dnsmasq reads by default is the file /etc/resolv.conf unless 
set otherwise with --resolv-file (LEDE soft links that file to /tmp/dnsmasq 
which by default soft links again to /tmp/resolv.conf.auto which is written by 
netifd).
- the contents of the resolvfile is normally populated with the DNS servers of 
the upstream link.
- nameservers to be used by dnsmasq can (also) be configured with the --server 
option (UCI:dhcp dnsmasq.server); several may of these option may be passed.

With LEDE/OpenWrt different instance of dnsmasq can run each with separate UCI 
options.
When running multiple instances and one of those must **not** use the upstream 
nameservers, than set dhcp:dnsmasq[i].noresolv to '1' and if needed specify one 
or more name servers with the UCI dhcp:dnsmasq[i].server list option.

One could write different resolvfiles manually and specify different UCI 
dhcp:dnsmasq.resolvfile options for each instance, but that is not what those 
files are meant for. The resolvfile is for use by the resolver routines of the 
C library which are used by processes running on the host [1]. By reading the 
resolvfile dnsmasq gets to know the nameservers of the upstream link; most 
times those are the nameservers dnsmasq will use, but not necessarily.

Conclusion: in order to get dnsmasq **not** to share nameservers with other 
instances, set noresolv to '1' and specify one or more nameservers to use with 
the server list option.

Hopefully I did understand your problem well, bye,
Paul

[1] man 5 resolv.conf


> Op 12 jun. 2017, om 18:09 heeft e9hack  het volgende 
> geschreven:
> 
> Hi,
> 
> IMHO, usage of the resolve file is completely wrong. If option 'resolvfile' 
> is not given for a configuration, dnsmasq
> must run without a parameter resolv-file='..' and uses /etc/resolv.conf which 
> is a symbolic link to /tmp/resolv.conf. In
> this case, the init script writes to /tmp/resolv.conf. If option 'resolvfile' 
> is given, dnsmasq must run with a
> parameter resolv-file='..'. The init script writes to the given resolve file. 
> This is important, if two instances of
> dnsmasq are running with different configurations and which cannot share any 
> data, e.g. 1th dnsmasq for the normal lan,
> 2th dnsmasq for a tor proxy.
> 
> Regards,
> Hartmut


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

[LEDE-DEV] [PATCH v2] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

With this patch the dnsmasq init script manages resolv.conf if and only if
when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
Also, resolvfile is now set irrespective of the value of noresolv.

Fixes (partially) FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
History
v1 -> v2corrected synxtax error
increased PKG_RELEASE

The intended invariant is that resolv.conf is managed whenever a resolver
listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well.
When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 then
resolv.conf is not touched.

Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
that will run, even when no dnsmasq instance will listen on localhost:53. So
for unbound PR#4454  has been submitted to make sure it always manages
resov.conf when it owns localhost:domain.

Paul
---
 package/network/services/dnsmasq/Makefile  |  2 +-
 .../network/services/dnsmasq/files/dnsmasq.init| 60 +-
 2 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index 307b4defe7..5b1073fc2c 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.77
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 62a3169c67..a03c402f6d 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -695,6 +695,21 @@ dhcp_relay_add() {
fi
 }
 
+dnsmasq_ismain()
+{
+   local cfg="$1"
+   local port notinterfaces
+
+   config_get port "$cfg" port "53"
+   [ $port = "53" ] || return 1
+
+   config_get notinterfaces "$cfg" notinterface ""
+   [ -n $notinterfaces ] && list_contains $notinterfaces "loopback" || 
return 1
+
+   # dnsmasq instance is designated to listen on 127.0.0.1#53.
+   return 0
+}
+
 dnsmasq_start()
 {
local cfg="$1" disabled resolvfile user_dhcpscript
@@ -839,14 +854,10 @@ dnsmasq_start()
[ -n "$leasefile" -a \! -e "$leasefile" ] && touch "$leasefile"
config_get_bool cachelocal "$cfg" cachelocal 1
 
-   config_get_bool noresolv "$cfg" noresolv 0
-   if [ "$noresolv" != "1" ]; then
-   config_get resolvfile "$cfg" resolvfile "/tmp/resolv.conf.auto"
-   # So jail doesn't complain if file missing
-   [ -n "$resolvfile" -a \! -e "$resolvfile" ] && touch 
"$resolvfile"
-   fi
-
-   [ -n "$resolvfile" ] && xappend "--resolv-file=$resolvfile"
+   config_get resolvfile "$cfg" resolvfile "/tmp/resolv.conf.auto"
+   xappend "--resolv-file=$resolvfile"
+   # So jail doesn't complain if file missing
+   [ \! -e "$resolvfile" ] && touch "$resolvfile"
 
config_get hostsfile "$cfg" dhcphostsfile
[ -e "$hostsfile" ] && xappend "--dhcp-hostsfile=$hostsfile"
@@ -959,16 +970,6 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
-   rm -f /tmp/resolv.conf
-   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
-   echo "search $DOMAIN" >> /tmp/resolv.conf
-   }
-   DNS_SERVERS="$DNS_SERVERS 127.0.0.1"
-   for DNS_SERVER in $DNS_SERVERS ; do
-   echo "nameserver $DNS_SERVER" >> /tmp/resolv.conf
-   done
-   }
 
procd_open_instance $cfg
procd_set_param command $PROG -C $CONFIGFILE -k -x 
/var/run/dnsmasq/dnsmasq."${cfg}".pid
@@ -986,20 +987,29 @@ dnsmasq_start()
procd_add_jail_mount_rw /var/run/dnsmasq/ $leasefile
 
procd_close_instance
+
+
+   # write /tmp/resolve.conf only for main instance
+   dnsmasq_ismain $cfg && {
+   rm -f /tmp/resolv.conf
+   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
+   echo "search $DOMAIN" >> /tmp/resolv.conf
+   }
+   DNS_SERVERS="$DNS_SERVERS 127.0.0.1"
+   for DNS_SERVER in $D

[LEDE-DEV] [PATCH v2] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

With this patch the dnsmasq init script manages resolv.conf if and only if
when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
Also, resolvfile is now set irrespective of the value of noresolv.

Fixes (partially) FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
History
v1 -> v2corrected synxtax error

The intended invariant is that resolv.conf is managed whenever a resolver
listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well.
When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 then
resolv.conf is not touched.

Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
that will run, even when no dnsmasq instance will listen on localhost:53. So
for unbound PR#4454  has been submitted to make sure it always manages
resov.conf when it owns localhost:domain.

Paul
---
 .../network/services/dnsmasq/files/dnsmasq.init| 60 +-
 1 file changed, 35 insertions(+), 25 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 62a3169c67..a03c402f6d 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -695,6 +695,21 @@ dhcp_relay_add() {
fi
 }
 
+dnsmasq_ismain()
+{
+   local cfg="$1"
+   local port notinterfaces
+
+   config_get port "$cfg" port "53"
+   [ $port = "53" ] || return 1
+
+   config_get notinterfaces "$cfg" notinterface ""
+   [ -n $notinterfaces ] && list_contains $notinterfaces "loopback" || 
return 1
+
+   # dnsmasq instance is designated to listen on 127.0.0.1#53.
+   return 0
+}
+
 dnsmasq_start()
 {
local cfg="$1" disabled resolvfile user_dhcpscript
@@ -839,14 +854,10 @@ dnsmasq_start()
[ -n "$leasefile" -a \! -e "$leasefile" ] && touch "$leasefile"
config_get_bool cachelocal "$cfg" cachelocal 1
 
-   config_get_bool noresolv "$cfg" noresolv 0
-   if [ "$noresolv" != "1" ]; then
-   config_get resolvfile "$cfg" resolvfile "/tmp/resolv.conf.auto"
-   # So jail doesn't complain if file missing
-   [ -n "$resolvfile" -a \! -e "$resolvfile" ] && touch 
"$resolvfile"
-   fi
-
-   [ -n "$resolvfile" ] && xappend "--resolv-file=$resolvfile"
+   config_get resolvfile "$cfg" resolvfile "/tmp/resolv.conf.auto"
+   xappend "--resolv-file=$resolvfile"
+   # So jail doesn't complain if file missing
+   [ \! -e "$resolvfile" ] && touch "$resolvfile"
 
config_get hostsfile "$cfg" dhcphostsfile
[ -e "$hostsfile" ] && xappend "--dhcp-hostsfile=$hostsfile"
@@ -959,16 +970,6 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
-   rm -f /tmp/resolv.conf
-   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
-   echo "search $DOMAIN" >> /tmp/resolv.conf
-   }
-   DNS_SERVERS="$DNS_SERVERS 127.0.0.1"
-   for DNS_SERVER in $DNS_SERVERS ; do
-   echo "nameserver $DNS_SERVER" >> /tmp/resolv.conf
-   done
-   }
 
procd_open_instance $cfg
procd_set_param command $PROG -C $CONFIGFILE -k -x 
/var/run/dnsmasq/dnsmasq."${cfg}".pid
@@ -986,20 +987,29 @@ dnsmasq_start()
procd_add_jail_mount_rw /var/run/dnsmasq/ $leasefile
 
procd_close_instance
+
+
+   # write /tmp/resolve.conf only for main instance
+   dnsmasq_ismain $cfg && {
+   rm -f /tmp/resolv.conf
+   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
+   echo "search $DOMAIN" >> /tmp/resolv.conf
+   }
+   DNS_SERVERS="$DNS_SERVERS 127.0.0.1"
+   for DNS_SERVER in $DNS_SERVERS ; do
+   echo "nameserver $DNS_SERVER" >> /tmp/resolv.conf
+   done
+   }
 }
 
 dnsmasq_stop()
 {
local cfg="$1"
 
-   config_get resolvfile "$cfg" "resolvfile"
-
#relink /tmp/resolve.conf only for main instance
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
-   [ -f /tmp/resolv.conf ] && {
-   rm -f /tmp/resolv.conf
-   ln -s "$resolvfile" /tmp/resolv.conf
-   }
+   dnsmasq_ismain $cfg && {
+   [ -f /tmp/resolv.conf ] && rm -f /tmp/resolv.conf
+   ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
}
 
rm -f ${BASEDHCPSTAMPFILE}.${cfg}.*.dhcp
-- 
2.13.1


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

Re: [LEDE-DEV] [PATCH] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

Hi Hans,

Please see my reaction/question on your remark about #53 and the main instance.

Thanks for reviewing,
Paul


> Op 8 jun. 2017, om 16:34 heeft Hans Dedecker <dedec...@gmail.com> het 
> volgende geschreven:
> 
> On Wed, Jun 7, 2017 at 12:07 PM, Paul Oranje <p...@xs4all.nl> wrote:
>> With this patch the dnsmasq init script manages resolv.conf if and only if
>> when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
>> Also, resolvfile is now set irrespective of the value of noresolv.
>> 
>> Fixes (partially) FS#785
>> 
>> Signed-off-by: Paul Oranje <p...@xs4all.nl>
>> ---
>> The intended invariant is that resolv.conf is managed whenever a resolver
>> listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well.
>> When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 
>> then
>> resolv.conf is not touched.
>> 
>> Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
>> that will run, even when no dnsmasq instance will listen on localhost:53. So
>> for unbound PR#4454a  has been submitted to make sure it always manages
>> resov.conf when it owns localhost:domain.
>> 
>> Background:
>> This patch has been discussed with Hans Dedecker and Eric Luerhsen and 
>> replaces
>> an earlier patch that is hereby retracted:
>>dnsmasq: write resolv.conf also when noresolv = 1
>> 
>> Paul
>> 
>> ---
>> .../network/services/dnsmasq/files/dnsmasq.init| 60 
>> +-
>> 1 file changed, 35 insertions(+), 25 deletions(-)
>> 
>> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
>> b/package/network/services/dnsmasq/files/dnsmasq.init
>> index 62a3169c67..cab3d2843c 100644
>> --- a/package/network/services/dnsmasq/files/dnsmasq.init
>> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
>> @@ -695,6 +695,21 @@ dhcp_relay_add() {
>>fi
>> }
>> 
>> +dnsmasq_ismain()
>> +{
>> +   local cfg="$1"
>> +   local port notinterfaces
>> +
>> +   config_get port "$cfg" port "53"
>> +   [ $port = "53" ] || return 1
> Any reason why a dnsmasq instance has to be bound on port 53 to be
> considered as main instance ? If port is not 0 it can be considered as
> a dnsmasq main instance as a dnat rule can rewrite the udp destination
> port
The "main instance" is with respect to /etc/resolv.conf and its format does not 
support setting a port for the nameserver [1].
A dnat rule that rewrites the destination port absolutely did not cross my mind 
- would one rewrite a local port ?

The management of resolv.conf by the init script of dnsmasq (and of unbound) is 
about making **itself** the nameserver for the processes running on the same 
host. When it cannot be assumed that 127.0.0.1#53 is listened on by a local 
daemon, how can one pick the "right" instance when multiple instances resolver 
are possible ?

If rewriting of a local port to another local port must be coped with, then a 
separate config value that explicitly denotes the instance that will run as the 
nameserver for the local processes might be needed.

[1] man 5 resolv.conf


>> +
>> +   config_get notinterfaces "$cfg" notinterface ""
>> +   [ -n $notinterfaces -a list_contains $notinterfaces "loopback" ] || 
>> return 1
> Has this been tested ?
> Following error is thrown "sh: loopback: unknown operand" when doing
> dnsmasq restart
Yes tested, evidently not enough, not with dnsmasq owning #53, so the test did 
not cover this code path.
Will take care of that (and test with dnsmasq owning #53).
A grep on this erroneous syntax revealed it being the only one.

>> +
>> +   # dnsmasq instance is designated to listen on 127.0.0.1#53.
>> +   return 0
>> +}
>> +
>> dnsmasq_start()
>> {
>>local cfg="$1" disabled resolvfile user_dhcpscript
>> @@ -839,14 +854,10 @@ dnsmasq_start()
>>[ -n "$leasefile" -a \! -e "$leasefile" ] && touch "$leasefile"
>>config_get_bool cachelocal "$cfg" cachelocal 1
>> 
>> -   config_get_bool noresolv "$cfg" noresolv 0
>> -   if [ "$noresolv" != "1" ]; then
>> -   config_get resolvfile "$cfg" resolvfile 
>> "/tmp/resolv.conf.auto"
>> -   # So jail doesn't complain if file missing
>> -   [ -n "$resolvfile" -a \! -e "$resolvfile" ] &a

[LEDE-DEV] [PATCH] dnsmasq: manage resolv.conf iff when listening on 127.0.0.1#53

[Paul Oranje]

With this patch the dnsmasq init script manages resolv.conf if and only if
when dnsmasq will listen on 127.0.0.1#53 (is main resolver instance).
Also, resolvfile is now set irrespective of the value of noresolv.

Fixes (partially) FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
The intended invariant is that resolv.conf is managed whenever a resolver
listens on 127.0.0.1#53. Besides dnsmasq, unbound can take that role as well.
When no instance of dnsmasq has been configured to listen on 127.0.0.1#53 then
resolv.conf is not touched.

Currently unbound handles resolv.conf also, but leaves it to dnsmasq whenever
that will run, even when no dnsmasq instance will listen on localhost:53. So
for unbound PR#4454a  has been submitted to make sure it always manages
resov.conf when it owns localhost:domain.

Background:
This patch has been discussed with Hans Dedecker and Eric Luerhsen and replaces
an earlier patch that is hereby retracted:
dnsmasq: write resolv.conf also when noresolv = 1

Paul

---
 .../network/services/dnsmasq/files/dnsmasq.init| 60 +-
 1 file changed, 35 insertions(+), 25 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 62a3169c67..cab3d2843c 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -695,6 +695,21 @@ dhcp_relay_add() {
fi
 }
 
+dnsmasq_ismain()
+{
+   local cfg="$1"
+   local port notinterfaces
+
+   config_get port "$cfg" port "53"
+   [ $port = "53" ] || return 1
+
+   config_get notinterfaces "$cfg" notinterface ""
+   [ -n $notinterfaces -a list_contains $notinterfaces "loopback" ] || 
return 1
+
+   # dnsmasq instance is designated to listen on 127.0.0.1#53.
+   return 0
+}
+
 dnsmasq_start()
 {
local cfg="$1" disabled resolvfile user_dhcpscript
@@ -839,14 +854,10 @@ dnsmasq_start()
[ -n "$leasefile" -a \! -e "$leasefile" ] && touch "$leasefile"
config_get_bool cachelocal "$cfg" cachelocal 1
 
-   config_get_bool noresolv "$cfg" noresolv 0
-   if [ "$noresolv" != "1" ]; then
-   config_get resolvfile "$cfg" resolvfile "/tmp/resolv.conf.auto"
-   # So jail doesn't complain if file missing
-   [ -n "$resolvfile" -a \! -e "$resolvfile" ] && touch 
"$resolvfile"
-   fi
-
-   [ -n "$resolvfile" ] && xappend "--resolv-file=$resolvfile"
+   config_get resolvfile "$cfg" resolvfile "/tmp/resolv.conf.auto"
+   xappend "--resolv-file=$resolvfile"
+   # So jail doesn't complain if file missing
+   [ \! -e "$resolvfile" ] && touch "$resolvfile"
 
config_get hostsfile "$cfg" dhcphostsfile
[ -e "$hostsfile" ] && xappend "--dhcp-hostsfile=$hostsfile"
@@ -959,16 +970,6 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
-   rm -f /tmp/resolv.conf
-   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
-   echo "search $DOMAIN" >> /tmp/resolv.conf
-   }
-   DNS_SERVERS="$DNS_SERVERS 127.0.0.1"
-   for DNS_SERVER in $DNS_SERVERS ; do
-   echo "nameserver $DNS_SERVER" >> /tmp/resolv.conf
-   done
-   }
 
procd_open_instance $cfg
procd_set_param command $PROG -C $CONFIGFILE -k -x 
/var/run/dnsmasq/dnsmasq."${cfg}".pid
@@ -986,20 +987,29 @@ dnsmasq_start()
procd_add_jail_mount_rw /var/run/dnsmasq/ $leasefile
 
procd_close_instance
+
+
+   # write /tmp/resolve.conf only for main instance
+   dnsmasq_ismain $cfg && {
+   rm -f /tmp/resolv.conf
+   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
+   echo "search $DOMAIN" >> /tmp/resolv.conf
+   }
+   DNS_SERVERS="$DNS_SERVERS 127.0.0.1"
+   for DNS_SERVER in $DNS_SERVERS ; do
+   echo "nameserver $DNS_SERVER" >> /tmp/resolv.conf
+   done
+   }
 }
 
 dnsmasq_stop()
 {
local cfg="$1"
 
-   config_get resolvfile "$cfg" "resolvfile"
-
#relink /tmp/resolve.conf only for main instance
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
-   [ -f /tmp/resolv.conf ] && {
-   rm -f /tmp/resolv.conf
-   ln -s "$resolvfile" /tmp/resolv.conf
-   }
+   dnsmasq_ismain $cfg && {
+   [ -f /tmp/resolv.conf ] && rm -f /tmp/resolv.conf
+   ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
}
 
rm -f ${BASEDHCPSTAMPFILE}.${cfg}.*.dhcp
-- 
2.13.0


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

Re: [LEDE-DEV] ddns problem

[Paul Oranje]

Often besides CGNAT for IPv4, you'll have an IPv6 address (and a delegated 
prefix).
The latter may allow access from the Internet.
-- 
Paul


> Op 5 jun. 2017, om 17:39 heeft Toke Høiland-Jørgensen  het 
> volgende geschreven:
> 
> "Giuseppe Lippolis"  writes:
> 
>> Dear All,
>> I have a problem with the pkg ddns-scripts_2.7.6-14_all.
>> I'm using the option service_name 'dyndns.org'.
>> 
>> After running the script I get in logread:
>> 
>> Mon Jun  5 15:27:27 2017 user.err ddns-scripts[2591]: myddns_ipv4: No or
>> private or invalid IP '100.67.31.70' given! Please check your
>> configuration
> 
> It means what it says: that IP is in a private address space (allocated
> for carrier grade NAT; see
> https://en.wikipedia.org/wiki/Private_network#Dedicated_space_for_carrier_grade_NAT_deployments).
> So you can't get your real public IP off the router; and probably, you
> won't be able to access the router from the outside regardless of
> whether your dyndns setup works, sadly... :/

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


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

Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1

[Paul Oranje]

tance, i.e. will listen on 
>> 127.0.0.1#53.
>> 
>> Do you agree ?
>> 
>> If so, could you share your thoughts on how best to do the unbound change ?
>> A few different approaches to the determination of $resolvsym seem possible, 
>> but I’m sure that picking best/easiest/whatever approach is best chosen by 
>> you.
>> 
>> Regards,
>> Paul
>> 
>> 
>>> Op 4 jun. 2017, om 16:26 heeft Paul Oranje <p...@xs4all.nl> het volgende 
>>> geschreven:
>>> 
>>> Good afternoon,
>>> 
>>> Conclusions:
>>> 1) Always initialise $resolvfile (i.e. independently of the state of 
>>> noresolv).
>>> 2) The value of $resolvfile cannot not be used the determine the dnsmasq 
>>> main instance since several instances likely will an equal value.
>>> 3) The main dnsmasq instance is the instance that listens on 127.0.0.1:53 
>>> (of which there can only be one or none).
>>> 4) When no local DNS resolver runs /tmp/resolv.conf should soft-link 
>>> $resolvfile (and that could possible be something else than 
>>> /tmp/resolv.conf.auto).
>>> 
>>> ad 3)
>>> The designated main instance can be determined at runtime by:
>>> - at start of an instance X, when this instance is configured to listen on 
>>> 127.0.0.1#53 and no process listens on that socket, then
>>> - at stop of an instance X, when this instance is configured to listen on 
>>> 127.0.0.1#53 and a process listens on that socket, then
>>> 
>>> For a listening-on test something like “nslookup localhost 127.0.0.1#53 
>>> >/dev/null” would seemingly work (though not on OWRT CC), but that will 
>>> incur a timeout delay (10 sec ?) when no daemon is listening.
>>> Understandably, suggestions for an alternative test that will not incur 
>>> such a timeout are welcome.
>>> 
>>> The above determination of the main instance assume that only one of 
>>> multiple instances is configured to listen on 127.0.0.1#53, otherwise the 
>>> tests may result erroneously in undefined behaviour.
>>> 
>>> ad 4)
>>> A use-case for setting resolvfile to a non-default might be the use of 
>>> different upstream resolvers for different subnets, though that could 
>>> easily be achieved with the server options of UCI dhcp.dnsmasq[x].
>>> 
>>> 
>>> Regards,
>>> Paul
>>> 
>>> 
>>> 
>>>> Op 4 jun. 2017, om 00:09 heeft Hans Dedecker <dedec...@gmail.com> het 
>>>> volgende geschreven:
>>>> 
>>>> On Sat, Jun 3, 2017 at 3:33 PM, Paul Oranje <p...@xs4all.nl> wrote:
>>>>> Thanks, please see a few quick reactions of mine inline ...
>>>>> Paul
>>>>> 
>>>>>> Op 3 jun. 2017, om 14:18 heeft Hans Dedecker <dedec...@gmail.com> het 
>>>>>> volgende geschreven:
>>>>>> 
>>>>>> On Thu, Jun 1, 2017 at 12:00 PM, Paul Oranje <p...@xs4all.nl> wrote:
>>>>>>> Hello Hans,
>>>>>>> 
>>>>>>> A new version of this small patch is worked on -overlooked your 
>>>>>>> previous comment and have lately been busy with other stuff-, but after 
>>>>>>> studying the code a little more I’ve a few questions. The intended 
>>>>>>> patch changes code that was added with commit 
>>>>>>> a35f9bbc43c3da06eed042f80dc09e8c1da681b4 (dnsmasq: Multiple dnsmasq 
>>>>>>> instances support) that was authored by you.
>>>>>>> 
>>>>>>> 
>>>>>>> The routines dnsmasq_start() and dnsmasq_stop() contain a guard on 
>>>>>>> writing and resetting /tmp/resolv.conf:
>>>>>>>  [ "$resolvfile" = "/tmp/resolv.conf.auto” ] &&
>>>>>>> 
>>>>>>> As explained in FS#785, the guard test fails when $noresolv is true and 
>>>>>>> $resolvfile has not been explicitly configured to its default 
>>>>>>> "/tmp/resolv.conf.auto", causing /tmp/resolv.conf to remain a soft link 
>>>>>>> to /tmp/resolv.conf.auto (the WAN its DNS).
>>>>>>> 
>>>>>>> The routine dnsmasq_stop() the guard is commented with
>>>>>>>  #relink /tmp/resolve.conf only for main instance
>>>>>>> 
>>>>>>> This suggests that only for the main (first ?) ins

Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1

[Paul Oranje]

Hello Eric,

While trying to solve FS#785 some questions about rewriting /tmp/resolv.conf 
have arisen - insight has grown.
(in short: when dnsmasq.noresolv=1 and dnsmasq.resolvfile is unset, then 
/tmp/resolv.conf is not handled).

After some analysis the conclusion is that the dnsmasq init script should 
handle /tmp/resolv.conf, if and only if, when its main instance is run. The 
main instance is designated the one that will listen on 127.0.0.1#53 (naturally 
there can be only one such instance).

When using unbound with UCI unbound.dhcp_link set to “dnsmasq”, the unbound 
init script does **not** handle /tmp/resolv.conf and leaves it to dnsmasq to do 
so. In the dhcp_link=dnsmasq setup it is unbound that listens on 127.0.0.1#53 
and so no instance of dnsmasq can possibly be the main instance. Which makes 
sense.

An attempt to solve this problem just within the scope of the dnsmasq init 
script has proven to be more convoluted than I first thought.

A simple, sane and much more elegant solution would be:
a) dnsmasq indeed only handles /tmp/resolv.conf when it runs the main instance 
and
b) unbound does so when it the main instance, i.e. will listen on 127.0.0.1#53.

Do you agree ?

If so, could you share your thoughts on how best to do the unbound change ?
A few different approaches to the determination of $resolvsym seem possible, 
but I’m sure that picking best/easiest/whatever approach is best chosen by you.

Regards,
Paul


> Op 4 jun. 2017, om 16:26 heeft Paul Oranje <p...@xs4all.nl> het volgende 
> geschreven:
> 
> Good afternoon,
> 
> Conclusions:
> 1) Always initialise $resolvfile (i.e. independently of the state of 
> noresolv).
> 2) The value of $resolvfile cannot not be used the determine the dnsmasq main 
> instance since several instances likely will an equal value.
> 3) The main dnsmasq instance is the instance that listens on 127.0.0.1:53 (of 
> which there can only be one or none).
> 4) When no local DNS resolver runs /tmp/resolv.conf should soft-link 
> $resolvfile (and that could possible be something else than 
> /tmp/resolv.conf.auto).
> 
> ad 3)
> The designated main instance can be determined at runtime by:
> - at start of an instance X, when this instance is configured to listen on 
> 127.0.0.1#53 and no process listens on that socket, then
> - at stop of an instance X, when this instance is configured to listen on 
> 127.0.0.1#53 and a process listens on that socket, then
> 
> For a listening-on test something like “nslookup localhost 127.0.0.1#53 
> >/dev/null” would seemingly work (though not on OWRT CC), but that will incur 
> a timeout delay (10 sec ?) when no daemon is listening.
> Understandably, suggestions for an alternative test that will not incur such 
> a timeout are welcome.
> 
> The above determination of the main instance assume that only one of multiple 
> instances is configured to listen on 127.0.0.1#53, otherwise the tests may 
> result erroneously in undefined behaviour.
> 
> ad 4)
> A use-case for setting resolvfile to a non-default might be the use of 
> different upstream resolvers for different subnets, though that could easily 
> be achieved with the server options of UCI dhcp.dnsmasq[x]. 
> 
> 
> Regards,
> Paul
> 
> 
> 
>> Op 4 jun. 2017, om 00:09 heeft Hans Dedecker <dedec...@gmail.com> het 
>> volgende geschreven:
>> 
>> On Sat, Jun 3, 2017 at 3:33 PM, Paul Oranje <p...@xs4all.nl> wrote:
>>> Thanks, please see a few quick reactions of mine inline ...
>>> Paul
>>> 
>>>> Op 3 jun. 2017, om 14:18 heeft Hans Dedecker <dedec...@gmail.com> het 
>>>> volgende geschreven:
>>>> 
>>>> On Thu, Jun 1, 2017 at 12:00 PM, Paul Oranje <p...@xs4all.nl> wrote:
>>>>> Hello Hans,
>>>>> 
>>>>> A new version of this small patch is worked on -overlooked your previous 
>>>>> comment and have lately been busy with other stuff-, but after studying 
>>>>> the code a little more I’ve a few questions. The intended patch changes 
>>>>> code that was added with commit a35f9bbc43c3da06eed042f80dc09e8c1da681b4 
>>>>> (dnsmasq: Multiple dnsmasq instances support) that was authored by you.
>>>>> 
>>>>> 
>>>>> The routines dnsmasq_start() and dnsmasq_stop() contain a guard on 
>>>>> writing and resetting /tmp/resolv.conf:
>>>>>  [ "$resolvfile" = "/tmp/resolv.conf.auto” ] &&
>>>>> 
>>>>> As explained in FS#785, the guard test fails when $noresolv is true and 
>>>>> $resolvfile has not been explicitly configured to its default 
>>>>> "/tmp/resolv.conf.au

Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1

[Paul Oranje]

Good afternoon,

Conclusions:
1) Always initialise $resolvfile (i.e. independently of the state of noresolv).
2) The value of $resolvfile cannot not be used the determine the dnsmasq main 
instance since several instances likely will an equal value.
3) The main dnsmasq instance is the instance that listens on 127.0.0.1:53 (of 
which there can only be one or none).
4) When no local DNS resolver runs /tmp/resolv.conf should soft-link 
$resolvfile (and that could possible be something else than 
/tmp/resolv.conf.auto).

ad 3)
The designated main instance can be determined at runtime by:
- at start of an instance X, when this instance is configured to listen on 
127.0.0.1#53 and no process listens on that socket, then
- at stop of an instance X, when this instance is configured to listen on 
127.0.0.1#53 and a process listens on that socket, then

For a listening-on test something like “nslookup localhost 127.0.0.1#53 
>/dev/null” would seemingly work (though not on OWRT CC), but that will incur a 
timeout delay (10 sec ?) when no daemon is listening.
Understandably, suggestions for an alternative test that will not incur such a 
timeout are welcome.

The above determination of the main instance assume that only one of multiple 
instances is configured to listen on 127.0.0.1#53, otherwise the tests may 
result erroneously in undefined behaviour.

ad 4)
A use-case for setting resolvfile to a non-default might be the use of 
different upstream resolvers for different subnets, though that could easily be 
achieved with the server options of UCI dhcp.dnsmasq[x]. 


Regards,
Paul



> Op 4 jun. 2017, om 00:09 heeft Hans Dedecker <dedec...@gmail.com> het 
> volgende geschreven:
> 
> On Sat, Jun 3, 2017 at 3:33 PM, Paul Oranje <p...@xs4all.nl> wrote:
>> Thanks, please see a few quick reactions of mine inline ...
>> Paul
>> 
>>> Op 3 jun. 2017, om 14:18 heeft Hans Dedecker <dedec...@gmail.com> het 
>>> volgende geschreven:
>>> 
>>> On Thu, Jun 1, 2017 at 12:00 PM, Paul Oranje <p...@xs4all.nl> wrote:
>>>> Hello Hans,
>>>> 
>>>> A new version of this small patch is worked on -overlooked your previous 
>>>> comment and have lately been busy with other stuff-, but after studying 
>>>> the code a little more I’ve a few questions. The intended patch changes 
>>>> code that was added with commit a35f9bbc43c3da06eed042f80dc09e8c1da681b4 
>>>> (dnsmasq: Multiple dnsmasq instances support) that was authored by you.
>>>> 
>>>> 
>>>> The routines dnsmasq_start() and dnsmasq_stop() contain a guard on writing 
>>>> and resetting /tmp/resolv.conf:
>>>>   [ "$resolvfile" = "/tmp/resolv.conf.auto” ] &&
>>>> 
>>>> As explained in FS#785, the guard test fails when $noresolv is true and 
>>>> $resolvfile has not been explicitly configured to its default 
>>>> "/tmp/resolv.conf.auto", causing /tmp/resolv.conf to remain a soft link to 
>>>> /tmp/resolv.conf.auto (the WAN its DNS).
>>>> 
>>>> The routine dnsmasq_stop() the guard is commented with
>>>>   #relink /tmp/resolve.conf only for main instance
>>>> 
>>>> This suggests that only for the main (first ?) instance /tmp/resolv.conf 
>>>> would be handled, which makes sense, but the test to accomplish that seems 
>>>> wrong.
>>>> 
>>>> Q1:
>>>> What is the supposed relation between dnsmasq instance and the value of 
>>>> the value/setting of resolvfile ?
>>> The DNS servers learned on the wan interface(s) by netifd are written
>>> in /tmp/resolv.conf.auto. By default a dnsmasq instance uses
>>> /tmp/resolv.conf.auto as resolver file unless configured otherwise.
>> Indeed and whether dnsmasq uses the (whatever) resolvfile is governed by the 
>> noresolv parameter; these two parameters are orthogonal.
>> The init script though skips setting resolvfile when noresolv is true.
> Agree the value of noresolv should have no influence on reading he
> resolvfile parameter; this behavior has been introduced in commit
> 2ac21bd793946a214295b760cd652b4150d3dc07
So I blamed the wrong commit.

>> 
>>> Using /tmp/rsolv.conf.auto as resolver file triggers logic to rewrite
>>> /tmp/resolv.conf
>> Why would the question whether local DNS resolution is handled by the DNS 
>> available on WAN interface be determined by this specific **value** of 
>> $resolvfile (and irrespective of the actual existence of that file) ?
>> 
>> Also the above question (Q1) is about the relation with the dnsmasq 
>> **instance**.
>> Could you pl

Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1

[Paul Oranje]

Thanks, please see a few quick reactions of mine inline ...
Paul

> Op 3 jun. 2017, om 14:18 heeft Hans Dedecker <dedec...@gmail.com> het 
> volgende geschreven:
> 
> On Thu, Jun 1, 2017 at 12:00 PM, Paul Oranje <p...@xs4all.nl> wrote:
>> Hello Hans,
>> 
>> A new version of this small patch is worked on -overlooked your previous 
>> comment and have lately been busy with other stuff-, but after studying the 
>> code a little more I’ve a few questions. The intended patch changes code 
>> that was added with commit a35f9bbc43c3da06eed042f80dc09e8c1da681b4 
>> (dnsmasq: Multiple dnsmasq instances support) that was authored by you.
>> 
>> 
>> The routines dnsmasq_start() and dnsmasq_stop() contain a guard on writing 
>> and resetting /tmp/resolv.conf:
>>[ "$resolvfile" = "/tmp/resolv.conf.auto” ] &&
>> 
>> As explained in FS#785, the guard test fails when $noresolv is true and 
>> $resolvfile has not been explicitly configured to its default 
>> "/tmp/resolv.conf.auto", causing /tmp/resolv.conf to remain a soft link to 
>> /tmp/resolv.conf.auto (the WAN its DNS).
>> 
>> The routine dnsmasq_stop() the guard is commented with
>>#relink /tmp/resolve.conf only for main instance
>> 
>> This suggests that only for the main (first ?) instance /tmp/resolv.conf 
>> would be handled, which makes sense, but the test to accomplish that seems 
>> wrong.
>> 
>> Q1:
>> What is the supposed relation between dnsmasq instance and the value of the 
>> value/setting of resolvfile ?
> The DNS servers learned on the wan interface(s) by netifd are written
> in /tmp/resolv.conf.auto. By default a dnsmasq instance uses
> /tmp/resolv.conf.auto as resolver file unless configured otherwise.
Indeed and whether dnsmasq uses the (whatever) resolvfile is governed by the 
noresolv parameter; these two parameters are orthogonal.
The init script though skips setting resolvfile when noresolv is true.

> Using /tmp/rsolv.conf.auto as resolver file triggers logic to rewrite 
> /tmp/resolv.conf
Why would the question whether local DNS resolution is handled by the DNS 
available on WAN interface be determined by this specific **value** of 
$resolvfile (and irrespective of the actual existence of that file) ?

Also the above question (Q1) is about the relation with the dnsmasq 
**instance**.
Could you please share your thoughts on the relation behind first instance and 
the value of $resolvfile ?


>> A fix I considered is to omit this guard altogether (so different from the 
>> patch previously submitted), so that the local DNS service will allways be 
>> used for local (router) DNS resolution when dnsmasq is started; at stop of 
>> dnsmasq the local resolution would return to use $resolvfile. Obviously 
>> doing so in dnsmasq_start() and dnsmasq_stop() routines that start or stop 
>> an instance would be the wrong place to do so, since that code will be 
>> called for each instance. These routines ar spawned from the start_service() 
>> and stop_service() routines that do iterate on the instances.
>> 
>> Q2:
>> Would placement of the /tmp/resolv.conf handling not be better placed in the 
>> start_ and stop_service() routines or, be guarded by a better test in the 
>> dnsmasq_start() and _stop() routines ? In other words: what would be a 
>> correct test ?
> we could move rewriting of /tmp/resolv.conf to the start routine; but
> this will not be trivial as for every dnsmasq instance DNS_SERVERS and
> DOMAIN state will need to be kept
The objective is to rewrite /tmp/resolv.conf to use local resolution whenever a 
local resolver runs (i.e. dnsmasq, unbound, ... listening on localhost:53). As 
multiple instances may be started, triggering on the first/main one seems to 
make sense (for lack of a better criterium).
So the question is: what do you think is a (practical) guard for that (and in 
what routines would those be placed best) ?

>> In the stop routine the file /tmp/resolv.conf is (re)set to a soft link to 
>> $resolvfile, which currently because of the test always is 
>> "/tmp/resolv.conf.auto”, irrespective whether that file exists or not.
>> 
>> Q3:
>> What would be the desired state of /tmp/resolv.conf after dnsmasq has been 
>> stopped ?
> In case dnsmasq is stopped /tmp/resolv.conf needs to use only the wan
> DNS servers; which are written by netifd in /tmp/resolv.conf.auto; and
> not anymore 127.0.0.1.
Okay, so that should never be any self user defined resolvfile ?

> Hans
>> 
>> 
>> Bye,
>> Paul
>> 
>> 
>> 
>>> Op 20 mei 2017, om 20:58 heeft Hans Dedecker <dedec...@gmail.com&g

Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1

[Paul Oranje]

Hello Hans,

A new version of this small patch is worked on -overlooked your previous 
comment and have lately been busy with other stuff-, but after studying the 
code a little more I’ve a few questions. The intended patch changes code that 
was added with commit a35f9bbc43c3da06eed042f80dc09e8c1da681b4 (dnsmasq: 
Multiple dnsmasq instances support) that was authored by you.


The routines dnsmasq_start() and dnsmasq_stop() contain a guard on writing and 
resetting /tmp/resolv.conf:
[ "$resolvfile" = "/tmp/resolv.conf.auto” ] &&

As explained in FS#785, the guard test fails when $noresolv is true and 
$resolvfile has not been explicitly configured to its default 
"/tmp/resolv.conf.auto", causing /tmp/resolv.conf to remain a soft link to 
/tmp/resolv.conf.auto (the WAN its DNS).

The routine dnsmasq_stop() the guard is commented with
#relink /tmp/resolve.conf only for main instance

This suggests that only for the main (first ?) instance /tmp/resolv.conf would 
be handled, which makes sense, but the test to accomplish that seems wrong.

Q1:
What is the supposed relation between dnsmasq instance and the value of the 
value/setting of resolvfile ?


A fix I considered is to omit this guard altogether (so different from the 
patch previously submitted), so that the local DNS service will allways be used 
for local (router) DNS resolution when dnsmasq is started; at stop of dnsmasq 
the local resolution would return to use $resolvfile. Obviously doing so in 
dnsmasq_start() and dnsmasq_stop() routines that start or stop an instance 
would be the wrong place to do so, since that code will be called for each 
instance. These routines ar spawned from the start_service() and stop_service() 
routines that do iterate on the instances.

Q2:
Would placement of the /tmp/resolv.conf handling not be better placed in the 
start_ and stop_service() routines or, be guarded by a better test in the 
dnsmasq_start() and _stop() routines ? In other words: what would be a correct 
test ?


In the stop routine the file /tmp/resolv.conf is (re)set to a soft link to 
$resolvfile, which currently because of the test always is 
"/tmp/resolv.conf.auto”, irrespective whether that file exists or not.

Q3:
What would be the desired state of /tmp/resolv.conf after dnsmasq has been 
stopped ?


Bye,
Paul



> Op 20 mei 2017, om 20:58 heeft Hans Dedecker <dedec...@gmail.com> het 
> volgende geschreven:
> 
> On Sat, May 20, 2017 at 12:41 AM, Paul Oranje <p...@xs4all.nl> wrote:
>> When UCI dhcp.dnsmasq.noresolv is true, dnsmasq ignores the (wan) resolv.conf
>> for upstream name resolution and the dnsmasq init script ialso skips writing
>> /tmp/resolv.conf (/etc/resolv.conf soft links that file).
>> 
>> Not using the local running DNS service when noresolv is true does not make
>> sence; the semantics of that config value do not imply this. With this patch
>> the init script also writes /tmp/resolv.conf when noresolv is true.
>> 
>> fixes FS#785
>> 
>> Signed-off-by: Paul Oranje <p...@xs4all.nl>
>> ---
>> This patch replaces an earlier patch with subject
>>  dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
>> which is obsoleted because that subject was required to be shorter.
>> ---
>> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
>> b/package/network/services/dnsmasq/files/dnsmasq.init
>> index 30fec7a4ee..197aae9de1 100644
>> --- a/package/network/services/dnsmasq/files/dnsmasq.init
>> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
>> @@ -947,7 +947,7 @@ dnsmasq_start()
>>echo >> $CONFIGFILE_TMP
>>mv -f $CONFIGFILE_TMP $CONFIGFILE
>> 
>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>>rm -f /tmp/resolv.conf
>>[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
>>echo "search $DOMAIN" >> /tmp/resolv.conf
>> @@ -982,7 +982,7 @@ dnsmasq_stop()
>>config_get resolvfile "$cfg" "resolvfile"
>> 
>>#relink /tmp/resolve.conf only for main instance
>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> As mentioned in the previous code review noresolv value must be read

Re: [LEDE-DEV] openwrt and lede - remerge proposal V3

[Paul Oranje]

The current workflow for handling patches involves 
https://patchwork.ozlabs.org/project/lede/.
Is that something that shouldn't be addressed also in the merging process ?

Paul

> Op 29 mei 2017, om 09:03 heeft John Crispin  het volgende 
> geschreven:
> 
> (resend, this time as plain text)
> 
> Hi,
> 
> here is a V3 of the remerge proposal, I tried to fold all the comments people 
> made into it, if anything is missing let me know. Please remeber that post 
> remerge anything can be voted on, so cluttering the proposal with many 
> details will delay the remerge even more.
> 
> Ideally we manage to vote during this week.
> 
> 
>John
> 
> *) rules
> - owrt will adopt the lede rules and voting system
> 
> *) branding
> - the owrt side sees no option of using the lede brand
> - a (minor) majority voted for openwrt as a name over lede whilst most people 
> said they did not care
> - as the last vote had a 100% ACK for a remerge using the owrt brand is the 
> only feasible option
> 
> *) domain
> - transfer owner ship to SPI for openwrt.org and lede-project.org
> - add them to the pool of urls at digital ocean
> - post remerge build a setup where we have several DNS servers in various 
> locations
> - point git.openwrt.org at the lede git server
> - point bugs.openwrt.org to the lede flyspray instance
> - keep both wikis and forums as is (we should decide post remerge how to 
> proceed to avoid these issues blocking the progress)
> - update the lede domain entries for build/download/rsync/... servers so that 
> the openwrt domain also points at them
> 
> *) SPI
> - nominate a new liaison team (imre and john offer to do this, if anyone else 
> is interested let us know)
> - inform SPI of the new liaisons, voters and project rules
> - this should be done early in the remerge process s.t. the domains can be 
> handed over
> 
> *) github
> - start pushing to the openwrt organisation
> - cleanup the list of owners in the openwrt organisation
> - obsolete all issues on the openwrt organisation and close the issue tracker
> - go through the open openwrt and lede PRs, pickup whats useful and close the 
> rest, asking people to repost (things wont be rebasable anyhow)
> - close the lede PR tracker
> - obsolete the lede github org after a grace period of 3-6 months
> 
> *) landing page
> - add a letter of intent / notice to both current landing pages announcing 
> the remerge
> - update the lede landing page to represent the openwrt name
> - update the landing page to have the same look & feel as the current openwrt 
> landing page
> - point openwrt.org at the lede landing page
> - try to find some design guru that will transform the owrt theme to one 
> appropriate to this century
> 
> *) trac
> - trac is already readonly, keep content so that search engines can still 
> find the it
> - edit the trac html templates, adding a note pointing at the bug.openwrt.org 
> instance
> 
> *) IRC
> - add back cloaking
> - give people channel ownership/admin rights
> 
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts (the 3 owrt 
> devs would like to keep theirs active)
> - turn all the webmaster@, hostmaster@, ... accounts into aliases that anyone 
> with voting rights can be subscribed to
> - ask those people that are no longer active to voluntarily give up their 
> accounts
> - mail addresses may under no conditions be used for any personal business, 
> consultancy, applying for jobs, ... purposes
> - any mail sent from an openwrt.org account needs to adhere the trademark 
> policy and should only be used for FOSS purposes
> 
> *) wiki / forum
> - TBD
> - asking in either forum/wiki will get a biased vote so keep them both around
> - start a separate discussion regarding these post remerge
> 
> *) LF
> - find out what doubts folks have about LF
> - find out benefits - we would have their hosting and sponsorship ?!
> - start a separate discussion regarding these post remerge
> 
> *) git trees
> - rebrand the lede tree to openwrt
> - work out what has happened inside the openwrt tree since the reboot and 
> pick up the useful bits (zoltan has done some prior work on this already)
> 
> *) mailing list
> - ask david to add the openwrt-adm and openwrt lists
> - send out invitation mails to the new list
> - setup redirect/auto-reply for the existing lists
> 
> *) trademark policy
> - review/ack imres trademark policy (https://openwrt.org/trademark)
> 
> *) timeline
> - vote / agree on the proposal within the next week
> - work on the action items in the 4 weeks after that
> 
>John
> 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-de...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
> 
> 

Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal V2

[Paul Oranje]

Who are/will be entitled to an [IRC] project cloak ?
Paul

> Op 22 mei 2017, om 19:11 heeft Imre Kaloz  het volgende 
> geschreven:
> 
> Hi,
> 
> On 2017-05-22 03:10, John Crispin wrote:
>> 
>> 
>> On 22/05/17 11:02, Rafał Miłecki wrote:
>>> On 05/22/2017 09:40 AM, John Crispin wrote:
 *) branding
 - the owrt side sees no option of using the lede brand
 - a (minor) majority voted for openwrt as a name over lede whilst most 
 people said they did not care
 - as the last vote had a 100% ACK for a remerge using the owrt brand is 
 the only feasible option
>>> 
>>> Since the project is going to be known/accessible under OpenWrt name now, I
>>> want also mbm and Kaloz to share #openwrt and #openwrt-devel privileges.
>>> 
>>> There were many times op was needed but mbm/Kaloz weren't around.
>>> 
>>> I was refused/ignored multiple times when asking for that, so I wanted to
>>> bring it as this point to be clear. Is that OK for you guys?
>>> 
>> i'll add it to V3
> Sorry Rafal, don't get me wrong but this isn't true. It might haven't been 
> documented well (like quite a few things) but you have been told years ago: 
> everyone who has a project cloak has access to everything. What have been 
> refused is to make a special exception just for you to get it without that.
> 
> 
> Imre
> 
> ___
> 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] dnsmasq: write resolv.conf also when noresolv = 1

[Paul Oranje]

When UCI dhcp.dnsmasq.noresolv is true, dnsmasq ignores the (wan) resolv.conf
for upstream name resolution and the dnsmasq init script ialso skips writing
/tmp/resolv.conf (/etc/resolv.conf soft links that file).

Not using the local running DNS service when noresolv is true does not make
sence; the semantics of that config value do not imply this. With this patch
the init script also writes /tmp/resolv.conf when noresolv is true.

fixes FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
This patch replaces an earlier patch with subject
  dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
which is obsoleted because that subject was required to be shorter.
---
 package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..197aae9de1 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
 
#relink /tmp/resolve.conf only for main instance
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
-- 
2.13.0


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

Re: [LEDE-DEV] [PATCH v5] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

Question: when the subject is changed in order the make it less than 50 
characters long, does that result in a distinct new patch ?
Paul

> Op 19 mei 2017, om 12:58 heeft Paul Oranje <p...@xs4all.nl> het volgende 
> geschreven:
> 
> Oké, I’ll submit another version with the requested changes later today.
> This trivial change is turning out a ping pong lesson. Thanks anyway,
> Paul
> 
> 
>> Op 18 mei 2017, om 16:53 heeft Hans Dedecker <dedec...@gmail.com> het 
>> volgende geschreven:
>> 
>> On Sun, May 14, 2017 at 8:22 PM, Paul Oranje <p...@xs4all.nl> wrote:
>>> 
>>> fixes FS#785
>>> 
>> Hi,
>> 
>> Thanks for the patch but be more verbose in the comment description
>> what problem you're trying to solve; the commit subject should be
>> limited to 50 characters.
>> See also https://lede-project.org/submitting-patches
>>> 
>>> Signed-off-by: Paul Oranje <p...@xs4all.nl>
>>> ---
>>> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
>>> b/package/network/services/dnsmasq/files/dnsmasq.init
>>> index 30fec7a4ee..197aae9de1 100644
>>> --- a/package/network/services/dnsmasq/files/dnsmasq.init
>>> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
>>> @@ -947,7 +947,7 @@ dnsmasq_start()
>>>   echo >> $CONFIGFILE_TMP
>>>   mv -f $CONFIGFILE_TMP $CONFIGFILE
>>> 
>>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && 
>>> {
>>>   rm -f /tmp/resolv.conf
>>>   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
>>>   echo "search $DOMAIN" >> /tmp/resolv.conf
>>> @@ -982,7 +982,7 @@ dnsmasq_stop()
>>>   config_get resolvfile "$cfg" "resolvfile"
>>> 
>>>   #relink /tmp/resolve.conf only for main instance
>>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && 
>>> {
>> noresolv needs to be read from the config which is not the case
>>>   [ -f /tmp/resolv.conf ] && {
>>>   rm -f /tmp/resolv.conf
>>>   ln -s "$resolvfile" /tmp/resolv.conf
>> this will generate an error now if resolvfile is empty
>>> --
>>> 2.12.2
>>> 
>>> 
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>> 
>> Hans
>> 
>> ___
>> 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 mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v5] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

Oké, I’ll submit another version with the requested changes later today.
This trivial change is turning out a ping pong lesson. Thanks anyway,
Paul


> Op 18 mei 2017, om 16:53 heeft Hans Dedecker <dedec...@gmail.com> het 
> volgende geschreven:
> 
> On Sun, May 14, 2017 at 8:22 PM, Paul Oranje <p...@xs4all.nl> wrote:
>> 
>> fixes FS#785
>> 
> Hi,
> 
> Thanks for the patch but be more verbose in the comment description
> what problem you're trying to solve; the commit subject should be
> limited to 50 characters.
> See also https://lede-project.org/submitting-patches
>> 
>> Signed-off-by: Paul Oranje <p...@xs4all.nl>
>> ---
>> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
>> b/package/network/services/dnsmasq/files/dnsmasq.init
>> index 30fec7a4ee..197aae9de1 100644
>> --- a/package/network/services/dnsmasq/files/dnsmasq.init
>> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
>> @@ -947,7 +947,7 @@ dnsmasq_start()
>>echo >> $CONFIGFILE_TMP
>>mv -f $CONFIGFILE_TMP $CONFIGFILE
>> 
>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>>rm -f /tmp/resolv.conf
>>[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
>>echo "search $DOMAIN" >> /tmp/resolv.conf
>> @@ -982,7 +982,7 @@ dnsmasq_stop()
>>config_get resolvfile "$cfg" "resolvfile"
>> 
>>#relink /tmp/resolve.conf only for main instance
>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> noresolv needs to be read from the config which is not the case
>>[ -f /tmp/resolv.conf ] && {
>>rm -f /tmp/resolv.conf
>>ln -s "$resolvfile" /tmp/resolv.conf
> this will generate an error now if resolvfile is empty
>> --
>> 2.12.2
>> 
>> 
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> Hans
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH v4] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

ad. 1) FS785 describes why, please have a look there.
ad. 2) the patched code has been tested.

Producing the submission of the patch for this trivial and simple change has 
provided me with the opportunity to make almost every error imaginable, and as 
you have noticed, I greatly succeeded at doing just that. The spam is an 
unwanted side effect.

I’ve submitted a last version of this patch, s.y.
Paul


> Op 14 mei 2017, om 18:54 heeft Kevin Darbyshire-Bryant 
> <ke...@darbyshire-bryant.me.uk> het volgende geschreven:
> 
> 
> 
> On 14/05/17 17:48, Alberto Bursi wrote:
>> 
>> 
>> On 05/14/2017 02:46 PM, Paul Oranje wrote:
>>> fixes FS#785
>>> ---
>>> 
>>>  v4: place patch version info in annotation (not in commit message, afraid 
>>> this is learning by practice)
>>>  v3: corrected typo (noreolv)
>>>  v2: also change guard in dnsmasq_stop() routine
>>>  v1: write /tmp/resolv.conf also when noresolv is true
> 
> Having seen so many versions go by...the overriding questions for me are
> 
> 1) Why do we want this?
> 2) Has any of it actually been tested?
> 
> ___
> 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 v5] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

fixes FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
 package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..197aae9de1 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
 
#relink /tmp/resolve.conf only for main instance
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
-- 
2.12.2


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

Re: [LEDE-DEV] [PATCH v3] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

Please ignore, a v4 has been submitted without patch version bla bla in the 
commit message.
Paul

> Op 14 mei 2017, om 13:54 heeft Paul Oranje <p...@xs4all.nl> het volgende 
> geschreven:
> 
> fixes FS#785
> v3: corrected typo (noreolv)
> v2: also change guard in dnsmasq_stop() routine
> v1: write /tmp/resolv.conf also when noresolv is true
> 
> Signed-off-by: Paul Oranje <p...@xs4all.nl>
> ---
> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index 30fec7a4ee..197aae9de1 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -947,7 +947,7 @@ dnsmasq_start()
>   echo >> $CONFIGFILE_TMP
>   mv -f $CONFIGFILE_TMP $CONFIGFILE
> 
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>   rm -f /tmp/resolv.conf
>   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
>   echo "search $DOMAIN" >> /tmp/resolv.conf
> @@ -982,7 +982,7 @@ dnsmasq_stop()
>   config_get resolvfile "$cfg" "resolvfile"
> 
>   #relink /tmp/resolve.conf only for main instance
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>   [ -f /tmp/resolv.conf ] && {
>   rm -f /tmp/resolv.conf
>   ln -s "$resolvfile" /tmp/resolv.conf
> -- 
> 2.12.2
> 
> 
> ___
> 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 v4] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

fixes FS#785
---

 v4: place patch version info in annotation (not in commit message, afraid this 
is learning by practice)
 v3: corrected typo (noreolv)
 v2: also change guard in dnsmasq_stop() routine
 v1: write /tmp/resolv.conf also when noresolv is true


 package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..197aae9de1 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
 
#relink /tmp/resolve.conf only for main instance
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
-- 
2.12.2


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

[LEDE-DEV] [PATCH v3] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

fixes FS#785
v3: corrected typo (noreolv)
v2: also change guard in dnsmasq_stop() routine
v1: write /tmp/resolv.conf also when noresolv is true

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
 package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..197aae9de1 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
 
#relink /tmp/resolve.conf only for main instance
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
-- 
2.12.2


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

Re: [LEDE-DEV] [PATCH v2] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

Please ignore, contains a syntax error.
new version will follow, sorry,
Paul



> Op 14 mei 2017, om 13:14 heeft Paul Oranje <p...@xs4all.nl> het volgende 
> geschreven:
> 
> fixes FS#785
> v1: write /tmp/resolv.conf also when nosolv is true
> v2: also change guard in dnsmasq_stop() routine
> 
> Signed-off-by: Paul Oranje <p...@xs4all.nl>
> ---
> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index 30fec7a4ee..c7506ed4ea 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -947,7 +947,7 @@ dnsmasq_start()
>   echo >> $CONFIGFILE_TMP
>   mv -f $CONFIGFILE_TMP $CONFIGFILE
> 
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>   rm -f /tmp/resolv.conf
>   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
>   echo "search $DOMAIN" >> /tmp/resolv.conf
> @@ -982,7 +982,7 @@ dnsmasq_stop()
>   config_get resolvfile "$cfg" "resolvfile"
> 
>   #relink /tmp/resolve.conf only for main instance
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>   [ -f /tmp/resolv.conf ] && {
>   rm -f /tmp/resolv.conf
>   ln -s "$resolvfile" /tmp/resolv.conf
> -- 
> 2.12.2
> 
> 
> ___
> 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 v2] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

fixes FS#785
v1: write /tmp/resolv.conf also when nosolv is true
v2: also change guard in dnsmasq_stop() routine

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
 package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..c7506ed4ea 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
 
#relink /tmp/resolve.conf only for main instance
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
-- 
2.12.2


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

[LEDE-DEV] [PATCH] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Paul Oranje]

fixes FS#785

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
 package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..8c052b48a0 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
-- 
2.12.2


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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Paul Oranje]

Dear David, dear community,
Please, see my comments below in-line.
With the highest esteem,
Paul

> Op 12 mei 2017, om 02:04 heeft David Lang <da...@lang.hm> het volgende 
> geschreven:
> 
> On Fri, 12 May 2017, Paul Oranje wrote:
> 
>>> Op 11 mei 2017, om 14:18 heeft Imre Kaloz <ka...@openwrt.org> het volgende 
>>> geschreven:
>>> On 2017-05-11 00:33, Paul Oranje wrote:
>>>>> Op 10 mei 2017, om 11:31 heeft Imre Kaloz <ka...@openwrt.org> het 
>>>>> volgende geschreven:
>>>>> On 2017-05-10 00:52, Jo-Philipp Wich wrote:
>>>> [cut]
>>>>> *) SPI
>>>>>>> - TBD post remerge
>>>>>> I'd prefer to tackle this first.
>>>>> Before the merge non-OpenWrt people are outsiders from both SPI's and the 
>>>>> world's PoV. After the merge everyone can vote on these topics.
>>>> This does not feel right. The desire to have the ownership of the domain 
>>>> being properly handled before bringing the project - which currently is 
>>>> LEDE - back under the openwrt domain name is very reasonable. The fork 
>>>> this have a cause.
>>>> If I’ve misunderstood Imre’s position, please tell.
>>> You did :) If you take a look at the original mail from John, that "TBD" is 
>>> there for SPI, the handling of the domain is before that point. This part 
>>> is about how to pick and elect the liaisons, as it has been explained 
>>> before in John's reply to Rafal.
>>> The SPI has a relationship with OpenWrt, not LEDE. When LEDE devs are 
>>> OpenWrt devs, they "become visible" for SPI. It's matter of steps you have 
>>> to do in order, nothing else.
>> Thank for the extra info.
>> So okay, but then agreement on the rules that governs the liason would 
>> probably still be required before.
>> 
>> Stating that OpenWrt has an exclusive position with SPI - certainly true for 
>> the name OpenWrt - ignores that the LEDE project itself now has so much to 
>> offer and momentum that it could very well consider self setting up a 
>> relation with SPI.
> 
> why should people spend time setting up a new relationship with SPI when the 
> re-merge is going to let them use the existing one? That sounds like a lot of 
> effort for nothing.
True, unneeded efforts are a waist. But when the existing relation of OpenWrt 
with SPI brings privileges for those that currently hold a position in OpenWrt, 
then it may be prudent to consider the odds.

> 
>>>>>>> - start pushing to the openwrt organisation
>>>>>> By force-overwriting the history of openwrt/openwrt ?
>>>>> No one said it won't cause a bit of pain, but would ease the transition 
>>>>> on the long run.
>>>> Seems the solution to un-fork may cause more problems than it solves. And 
>>>> all that for just the name ?
>>> I don't think rebasing your changes is that much of a pain, and this only 
>>> causes a hiccup for people who are using the OpenWrt git tree for real.
>> Probably true, but does concern pain of others ... Why wouldn’t the 
>> re-merged project have its living repository named LEDE ? Is that a problem 
>> ? (or is it wished for taht all commits on LEDE seem to be in openwrt ?)
> 
> The decision was made last year that the resulting codebase would be the LEDE 
> codebase, the OpenWRT devs were given commit rights to the LEDE repo so that 
> they could migrate over anything they considered significant.
> 
> So why would there be a separate LEDE and OpenWRT repo?
Why would the OpenWrt repo be re-animated ?
New commits are push onto LEDE and OpenWrt will just not accept any new commits 
and remain in its current state. This scenario would not bring any 
disadvantages, would it ?
Personally it doesn't matter much, the opinion of most active devs should, of 
coarse, be regarded more relevant.

> 
> 
>> What I referred to is that LEDE explicitly decided not to issue e-mail 
>> addresses in order to avoid that such address would place some people in a 
>> special position, in order to avoid undue discrimination. Making exceptions 
>> could amount to some being more equal than others.
> 
> There is 'some are more equal than others' and there is not breaking existing 
> communications channels.
> 
> You can never eliminate @openwrt.org addresses from all the documentation on 
> the Internet, or from everyone's address books, so it makes sense to have the 
> existing addresses keep working.
> 
> It has been decided that such addresses should not be handed out and 
> generally used going 

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Paul Oranje]

Taking part in this discussion feels a bit awkward - without question I have 
less at stake than you and most other involved devs - but since I did speak-up 
...
-- 
Paul

> Op 11 mei 2017, om 14:18 heeft Imre Kaloz <ka...@openwrt.org> het volgende 
> geschreven:
> 
> Hi Paul,
> 
> 
> On 2017-05-11 00:33, Paul Oranje wrote:
>> Although being someone that’s merely following the developments of this 
>> project, I want to comment on what’s going on in this thread.
>> Some of my remarks may strike as not very positive, so please do not take 
>> any of those personal.
>> s.y.
>> Paul
>> 
>>> Op 10 mei 2017, om 11:31 heeft Imre Kaloz <ka...@openwrt.org> het volgende 
>>> geschreven:
>>> 
>>> On 2017-05-10 00:52, Jo-Philipp Wich wrote:
>> [cut]
>> 
>>> *) SPI
>>>>> - TBD post remerge
>>>> I'd prefer to tackle this first.
>>> Before the merge non-OpenWrt people are outsiders from both SPI's and the 
>>> world's PoV. After the merge everyone can vote on these topics.
>> This does not feel right. The desire to have the ownership of the domain 
>> being properly handled before bringing the project - which currently is LEDE 
>> - back under the openwrt domain name is very reasonable. The fork this have 
>> a cause.
>> If I’ve misunderstood Imre’s position, please tell.
> You did :) If you take a look at the original mail from John, that "TBD" is 
> there for SPI, the handling of the domain is before that point. This part is 
> about how to pick and elect the liaisons, as it has been explained before in 
> John's reply to Rafal.
> 
> The SPI has a relationship with OpenWrt, not LEDE. When LEDE devs are OpenWrt 
> devs, they "become visible" for SPI. It's matter of steps you have to do in 
> order, nothing else.
Thank for the extra info.
So okay, but then agreement on the rules that governs the liason would probably 
still be required before.
Stating that OpenWrt has an exclusive position with SPI - certainly true for 
the name OpenWrt - ignores that the LEDE project itself now has so much to 
offer and momentum that it could very well consider self setting up a relation 
with SPI.

>>>>> - start pushing to the openwrt organisation
>>>> By force-overwriting the history of openwrt/openwrt ?
>>> No one said it won't cause a bit of pain, but would ease the transition on 
>>> the long run.
>> Seems the solution to un-fork may cause more problems than it solves. And 
>> all that for just the name ?
> I don't think rebasing your changes is that much of a pain, and this only 
> causes a hiccup for people who are using the OpenWrt git tree for real.
Probably true, but does concern pain of others ... 
Why wouldn’t the re-merged project have its living repository named LEDE ? Is 
that a problem ? 
(or is it wished for taht all commits on LEDE seem to be in openwrt ?)

>>>>> - update the landing page to have the same look & feel as the current
>>>>> openwrt landing page
>>>> Why?
>>> Well, we're not wikipedia so it doesn't hurt if the site has at least some 
>>> CSS ;)
>> For all value that OWRT was worth, its website's looks weren’t among them.
> I didn't say it looks awesome - but in 2017 we shouldn't optimize for lynx I 
> think. Actually creating a common look and feel between services (and SSO for 
> them) would make things look way better IMHO.
>>>>> *) email accounts
>>>>> - currently there are around ~20 active openwrt.org mail accounts
>>>>> - turn all the webmaster@, hostmaster@, ... accounts into aliases that
>>>>> anyone with voting rights can be subscribed to
>>>>> - ask those people that are no longer active to voluntarily give up
>>>>> their accounts
>>>>> - mail addresses may under no conditions be used for any personal
>>>>> business, consultancy, applying for jobs, ... purposes
>>>> According to the rules there shall be no personal mail accounts at all.
>>>> There should be plenty of time until the actual remerge to fade them out
>>>> and to set up forwarding elsewhere.
>>> I hope you agree that a merge means both sides are adopting and need to 
>>> find some common ground.
>> All animals are equal, but some animals are more equal than others ...
> I think I've lost you here. In my point of view common ground != everyone 
> looses. This is a "non-zero-sum game”.
What I referred to is that LEDE explicitly decided not to issue e-mail 
addresses in order to avoid that such address would place some people in a 
special position, in order to

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Paul Oranje]

Although being someone that’s merely following the developments of this 
project, I want to comment on what’s going on in this thread.
Some of my remarks may strike as not very positive, so please do not take any 
of those personal.
s.y.
Paul

> Op 10 mei 2017, om 11:31 heeft Imre Kaloz  het volgende 
> geschreven:
> 
> On 2017-05-10 00:52, Jo-Philipp Wich wrote:
[cut]

> *) SPI
>>> - TBD post remerge
>> 
>> I'd prefer to tackle this first.
> 
> Before the merge non-OpenWrt people are outsiders from both SPI's and the 
> world's PoV. After the merge everyone can vote on these topics.
This does not feel right. The desire to have the ownership of the domain being 
properly handled before bringing the project - which currently is LEDE - back 
under the openwrt domain name is very reasonable. The fork this have a cause.
If I’ve misunderstood Imre’s position, please tell.

>>> - start pushing to the openwrt organisation
>> 
>> By force-overwriting the history of openwrt/openwrt ?
> 
> No one said it won't cause a bit of pain, but would ease the transition on 
> the long run.
Seems the solution to un-fork may cause more problems than it solves. And all 
that for just the name ?

>>> - update the landing page to have the same look & feel as the current
>>> openwrt landing page
>> 
>> Why?
> 
> Well, we're not wikipedia so it doesn't hurt if the site has at least some 
> CSS ;)
For all value that OWRT was worth, its website's looks weren’t among them.

>>> *) email accounts
>>> - currently there are around ~20 active openwrt.org mail accounts
>>> - turn all the webmaster@, hostmaster@, ... accounts into aliases that
>>> anyone with voting rights can be subscribed to
>>> - ask those people that are no longer active to voluntarily give up
>>> their accounts
>>> - mail addresses may under no conditions be used for any personal
>>> business, consultancy, applying for jobs, ... purposes
>> 
>> According to the rules there shall be no personal mail accounts at all.
>> There should be plenty of time until the actual remerge to fade them out
>> and to set up forwarding elsewhere.
> 
> I hope you agree that a merge means both sides are adopting and need to find 
> some common ground.
All animals are equal, but some animals are more equal than others ...

> Some of the rules has to change, and as we've discussed it with John, one 
> might want to send upstream submissions to make OpenWrt show up there like 
> other projects do. You might also want to open a private conversation between 
> the upstream platform / driver maintainer where having a project email 
> address could be useful. Personally I only use my owrt address for FOSS 
> related stuff and as far as I know, most people do the same.
> 
> LEDE has a rule which says: "Committers being unreachable for three months in 
> a row shall get their commit and voting rights revoked in order to retain the 
> ability to do majority votes among the remaining active committers." This 
> rule is clearly problematic if you would like to extend voting rights to 
> non-coders which I believe we want to do. Someone maintaining the wiki or the 
> forums might never commit anything, but we do want to get their opinion 
> heard. In the past we didn't make it easy for the community to interfere with 
> decisions, I doubt we want to make the same mistake again.
Intentions matter. Nonetheless a rule that tries to prevent that 
non-cooperation can be used as a way to obstruct, should not be set aside by 
intentions; this rule may very well be a sleeping rule that, unhoped for, might 
just be needed when lesser intentions become a problem. While on the other hand 
in the interpretation of a rule, its intention is very relevant and helps to 
apply it to cases that may seem not to fit when interpreted in a (to) narrowly 
strict way.

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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Paul Oranje]

> Op 8 mei 2017, om 15:19 heeft John Crispin  het volgende 
> geschreven:
> 
> Hi,
> 
> Felix, Imre and myself had 2 calls last week lasting several hours and 
> discussed the following proposal of conditions for a remerge that we would 
> like to propose and have people vote on.
Is a recording or transcription of these talks available ?

Paul



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

Re: [LEDE-DEV] dnsmasq-full should deselect dnsmasq

[Paul Oranje]

Could a case as this one where multiple packages of one software component 
having different build configs exist not be treated as a specific case of 
alternatives (for which Yousong Zhou submitted a patch) ? So install the 
versions in parallel and select one alternative i.s.o. deselecting the inactive 
versions.
-- 
Paul

> Op 3 mei 2017, om 04:00 heeft Eric Luehrsen  het 
> volgende geschreven:
> 
> 
> 
> On 05/02/2017 02:22 PM, Andrew McConachie wrote:
>> 
>> 
>> On 5/2/17 10:13, Jo-Philipp Wich wrote:
>>> Hi Andrew,
>>> 
 When selecting package dnsmasq-full from make menuconfig I believe it
 should deselect package dnsmasq.
>>> this is not easily solvable within the current Kconfig framework and
>>> most likely a "won't fix" item in the foreseeable future.
>>> 
>>> ~ Jo
>> 
>> Hi Jo,
>> 
>> How then should my package depend on dnsmasq-full? If it's not possible
>> to de-select a package as a consequence of selecting another package,
>> then how can there be packages that provide the same files?
>> 
>> Perhaps this is another stupid question, but what's the point of having
>> a package like dnsmasq-full if it cannot be DEPENDed upon?
>> 
>> --Andrew
> 
> Within the build tools there appears to be a construct for a single 
> package, but with options that are selectable (for conditional compile 
> or otherwise). Maybe dnsmasq Makefile should be redone for this method. 
> I am not sure if it fixes the dependency issues. However, should 
> multiple packages provide the "same-different" files is a good question.
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH 5/7] firewall3: add UBUS support for ipset sections

[Paul Oranje]

Assignment within a condition is easily read by (dyslectic) humans as a test 
for equality (==) and is for that reason als better avoided.
Paul

> Op 2 mei 2017, om 18:43 heeft Philip Prindeville 
>  het volgende geschreven:
> 
> 
>> On May 2, 2017, at 6:15 AM, Pierre Lebleu  wrote:
>> 
>> Hi Philip,
>> 
>> 2017-04-29 3:11 GMT+02:00 Philip Prindeville 
>> :
>> Inline…
>> 
>> 
>> [snip]
>>> + if (!(ipset = fw3_alloc_ipset(state)))
>> 
>> 
>> Minor nit…  Assignments inside of conditionals are a bear to step through in 
>> a debugger like GDB.
>> 
>> -Philip
>> 
>> It is a trivial assignment and it is already done in this style along the 
>> file.
>> 
>> --
>> Pierre
>> 
> 
> 
> It’s not about trivial vs. nontrivial.  It’s about whether you could step 
> through the assignment with (say) gdb, execute just the assignment, examine 
> the value, and then step through the “if”.  And the answer is, “you can’t”.  
> Because gdb is a source level debugger where the unit of source is the “line”.
> 
> (Actually, it’s also the unit of source for gcc when it generates debugging 
> symbols.)
> 
> The way to separate to 2 individual statements in C (for the purposes of gdb 
> debugging) is to put them on separate lines.  Yes, that’s a glaring 
> limitation of gcc and gdb, but that’s our reality.
> 
> As for what’s already done in this style in the file… Having separate 
> assignments and tests is *also* done, and indeed it’s done more often.
> 
> -Philip
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

Hi Piotr,

This is going to end up in a fairly steep learning proces for me, so it may 
take up a little more time; so when this small project may wait for your input 
so now and then, should not be a real problem. Still, solving this one might 
further a few other ones.

As, usually see replies/question/comments below.

As a side-note: the vendor firmware deployed OpenWrt with the Atheros LSDK 9.2 
closed-source driver for the AR9285 wifi chip. Could that explain why LEDE with 
the ath9k driver maxes txpower at 16 dBm while the stock firmware maxes out at 
27 (or 26 ?) dBm ?

Thanks for taking your time,
Paul


> Op 9 apr. 2017, om 22:06 heeft Piotr Dymacz <pep...@gmail.com> het volgende 
> geschreven:
> 
> Hello Paul,
> 
> Sorry for a late reply.
> 
> On 06.04.2017 14:24, Paul Oranje wrote:
>> Thanks for the info.
>> The systematics for the generation of the build config from the makefiles is 
>> still quite obscure to me. A wiki lemma that puts some light in this would 
>> be welcome; once I do understand I may write one.
> 
> That would be really kind.
> 
>> See my questions/comments/replies in-line below.
>> 
>> Ciao,
>> Paul
>> 
>> 
>>> Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz <pep...@gmail.com> het volgende 
>>> geschreven:
>>> 
>>> Hello Paul,
>>> 
>>> On 05.04.2017 23:23, Paul Oranje wrote:
>>>> Hello,
>>>> 
>>>> I’m wondering how to make LEDE build automatically an initramfs image (for 
>>>> use with u-boot tftp recovery boot), when the ENH200EXT is selected as the 
>>>> target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working 
>>>> image is build that can be tftp-booted alright, but I would prefer that it 
>>>> is build automatically beside the sysupgrade image.
>>>> 
>>>> The context would, as requested, be "target/linux/ar71xx/image/generic.mk".
>>> 
>>> The "generic" subtarget doesn't have included "ramdisk" feature:
>>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2
>>> 
>>> It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS":
>>> https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34
>> Does that mean that the initramfs can only be triggered by manually setting 
>> “CONFIG_TARGET_ROOTFS_INITRAMFS=y” ?
> 
> AFAIK, yes.
> 
>> That would mean that the LEDE build-bots would not generate initramfs images 
>> and people would need for the initial install to build such images 
>> themselves. Likely I’ve not understood well how it works and what follows 
>> hints how to do it.
>> 
>>> https://github.com/lede-project/source/blob/master/config/Config-images.in#L11
>>> 
>>> On the other hand, "mikrotik" subtarget uses initramfs images as they are 
>>> required for initial LEDE flash:
>>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2
>> 
>> Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in 
>> "target/linux/ar71xx/image/generic.mk” does not work (tried it).
> 
> "FEATURES" variable belongs to the target, not particular device and thus 
> cannot be changed/extended like this.
Meanwhile I’ve spent some time browsing and inductively came to that very same 
conclusion.
> 
>> Since the initramfs is only needed for some ar71xx target profiles, the 
>> FEATURES declaration should not be set in 
>> “target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in the 
>> context of a target.mk, then a new makefile 
>> "target/linux/ar71xx/engenius/target.mk" would be needed, or to what other 
>> makefile could/should "FEATURES += ramdisk” then be added ?
> 
> A separate subtarget just for one device is a bad idea. AFAIK, the only way 
> to include initramfs by default would require extending "FEATURES" in 
> ar71xx/generic subtarget target.mk config, but…
Fair enough.
Does an added ramdisk feature result by default in building initramfs images 
for all profiles below the subtarget ?
If so, would it be doable to undo that effect in the default 
Device/Profile/Build definition ?

>>> Is the initramfs image required for initial LEDE image flash on your device 
>>> or is it just useful with recovery mode?
>> The stock firmware cannot install a LEDE factory image, so the initramfs 
>> image is indeed needed for the initial install.
> 
> I'm not sure if enabling initramfs images for a whole subtarget jus

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

Thanks for the info.
The systematics for the generation of the build config from the makefiles is 
still quite obscure to me. A wiki lemma that puts some light in this would be 
welcome; once I do understand I may write one.

See my questions/comments/replies in-line below.

Ciao,
Paul


> Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz <pep...@gmail.com> het volgende 
> geschreven:
> 
> Hello Paul,
> 
> On 05.04.2017 23:23, Paul Oranje wrote:
>> Hello,
>> 
>> I’m wondering how to make LEDE build automatically an initramfs image (for 
>> use with u-boot tftp recovery boot), when the ENH200EXT is selected as the 
>> target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image 
>> is build that can be tftp-booted alright, but I would prefer that it is 
>> build automatically beside the sysupgrade image.
>> 
>> The context would, as requested, be "target/linux/ar71xx/image/generic.mk".
> 
> The "generic" subtarget doesn't have included "ramdisk" feature:
> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2
> 
> It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS":
> https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34
Does that mean that the initramfs can only be triggered by manually setting 
“CONFIG_TARGET_ROOTFS_INITRAMFS=y” ?
That would mean that the LEDE build-bots would not generate initramfs images 
and people would need for the initial install to build such images themselves. 
Likely I’ve not understood well how it works and what follows hints how to do 
it.

> https://github.com/lede-project/source/blob/master/config/Config-images.in#L11
> 
> On the other hand, "mikrotik" subtarget uses initramfs images as they are 
> required for initial LEDE flash:
> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2

Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in 
"target/linux/ar71xx/image/generic.mk” does not work (tried it).

Since the initramfs is only needed for some ar71xx target profiles, the 
FEATURES declaration should not be set in 
“target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in the 
context of a target.mk, then a new makefile 
"target/linux/ar71xx/engenius/target.mk" would be needed, or to what other 
makefile could/should "FEATURES += ramdisk” then be added ?

> 
> Is the initramfs image required for initial LEDE image flash on your device 
> or is it just useful with recovery mode?
The stock firmware cannot install a LEDE factory image, so the initramfs image 
is indeed needed for the initial install.

> 
>> From what I have understood so far, the clause would be something like:
>> 
>>  define Device/enh200ext
>>DEVICE_TITLE := Engenius ENH200EXT
>>DEVICE_PACKAGES := rssileds
>>BOARDNAME := ENH200EXT
>>CONSOLE := ttyS0,115200
> 
> Side note: this is default under ar71xx target, drop this line in your next 
> patch please.
OK, I’ll drop the CONSOLE line.

> 
> Defaults: 
> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/Makefile#L99
> 
> --
> Cheers,
> Piotr
> 
>>IMAGE_SIZE := 8192k
>>IMAGES := initramfs.bin sysupgrade.bin
>>MTDPARTS := 
>> spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro
>>  endef
>>  TARGET_DEVICES += enh200ext
>> 
>> The sysupgrade image is build, but the initramfs image is not build. I 
>> suppose an IMAGE/initramfs declaration must be added, but I do not know what 
>> to declare or call.
>> 
>> Some help would be appreciated,
>> 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

Hello,

I’m wondering how to make LEDE build automatically an initramfs image (for use 
with u-boot tftp recovery boot), when the ENH200EXT is selected as the target 
device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image is build 
that can be tftp-booted alright, but I would prefer that it is build 
automatically beside the sysupgrade image. 

The context would, as requested, be "target/linux/ar71xx/image/generic.mk".
From what I have understood so far, the clause would be something like:

define Device/enh200ext
  DEVICE_TITLE := Engenius ENH200EXT
  DEVICE_PACKAGES := rssileds
  BOARDNAME := ENH200EXT
  CONSOLE := ttyS0,115200
  IMAGE_SIZE := 8192k
  IMAGES := initramfs.bin sysupgrade.bin
  MTDPARTS := 
spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro
endef
TARGET_DEVICES += enh200ext

The sysupgrade image is build, but the initramfs image is not build. I suppose 
an IMAGE/initramfs declaration must be added, but I do not know what to declare 
or call.

Some help would be appreciated,
-- 
s.y.
Paul



> Op 2 apr. 2017, om 18:16 heeft Piotr Dymacz <pep...@gmail.com> het volgende 
> geschreven:
> 
> Hello Paul,
> 
> On 01.04.2017 13:05, Paul Oranje wrote:
>> Thanks for the comments.
>> See my comments/questions inline below.
>> Paul
>> 
> [...]
>>> Also, make sure you follow rules from [1], especially the one about commit 
>>> message/description (line wrap).
>> I will correct this in patch v2.
> 
> OK.
> 
>> BTW ./scripts/checkpatch.pl ar71xx-enh200ext.patch at my site only yields 
>> the first warning, but not the error; strange.
> 
> Your patch was probably corrupted by your e-mail client.
> 
> You can download your patch which arrived to the mailing list and was then 
> picked up by patchwork using this link:
> 
> http://patchwork.ozlabs.org/patch/745796/raw/
> 
> If you check downloaded patch, you will get same error as I did.
> 
> I don't know how you send patches, but what should always work is git 
> send-email: https://git-scm.com/docs/git-send-email
> 
> [...]
> 
>>> Please, include image support for this device in generic.mk. We really 
>>> don't want to (and won't) include more devices in legacy.mk.
>> What position in generic.mk would you suggest for the entry of the clause 
>> for the ENH200EXT ?
> 
> It's more up to you. It would be good to keep alphabetical order but that 
> file is already "broken" in this subject.
> 
>> And except this entry into generic.mk, would any other change be needed with 
>> respect to the target image makefile(s) ?
> 
> I don't think so, your board seems to use a common pattern for image 
> generation.
> 
> You can also take a look at some of the recent changes which moved Compex 
> board into generic image building code:
> 
> https://github.com/lede-project/source/commit/be11ce8f26bfa58c110434ccf673c0411402b171
> 
> https://github.com/lede-project/source/commit/0af487033e6af390686ed2bc693beab7b467eaf3
> 
> --
> Best regards,
> Piotr Dymacz
> 
>> 
>>> 
>>> [1] https://lede-project.org/submitting-patches
>>> 
>>> --
>>> Cheers,
>>> Piotr
>>> 
>>>> target/linux/ar71xx/mikrotik/config-default|  1 +
>>>> target/linux/ar71xx/nand/config-default|  1 +
>>>> 14 files changed, 122 insertions(+), 3 deletions(-)
>>>> create mode 100644 
>>>> target/linux/ar71xx/files/arch/mips/ath79/mach-enh200ext.c
>>>> 
>>>> diff --git a/package/boot/uboot-envtools/files/ar71xx 
>>>> b/package/boot/uboot-envtools/files/ar71xx
>>>> index 3a5d269..a104c3a 100644
>>>> --- a/package/boot/uboot-envtools/files/ar71xx
>>>> +++ b/package/boot/uboot-envtools/files/ar71xx
>>>> @@ -27,6 +27,7 @@ cpe870|\
>>>> cr3000|\
>>>> cr5000|\
>>>> eap300v2|\
>>>> +enh200ext|\
>>>> gl-ar300m|\
>>>> hornet-ub|\
>>>> hornet-ub-x2|\
>>>> 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 686ae31..cf9c3ae 100755
>>>> --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
>>>> +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
>>>> @@ -28,7 +28,8 @@ alfa-nx)
>>>>ucidef_set_led_netdev "lan" "LAN" "alfa:green:led_3" "eth1"
>>>>;;
>>>> all0258n|\
>>&g

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

See comments/questions inline below.
-- 
Paul Oranje


> Op 1 apr. 2017, om 02:00 heeft Daniel Golle <dan...@makrotopia.org> het 
> volgende geschreven:
> 
> Hi Paul,
> 
> On Fri, Mar 31, 2017 at 10:38:39PM +0200, Paul Oranje wrote:
>> This POE access point suited for outside usage needs an external antenna.
>> According FCC documentation the ENH200EXT (needs external antenna) and the 
>> ENH200 (with internal antenna) are electrically equal to the Allnet ALL0258N.
>> 
>> The stock image does not allow install of a LEDE factory image, but an 
>> initramfs image (lede-ar71xx-generic-enh200ext-initramfs-uImage.bin) can be 
>> loaded via u-boot recovery procedure (long press reset at power-on until all 
>> LEDS burn). The u-boot recovery procedure boots an image named 
>> vmlinux-art-ramdisk from 192.168.1.101.
>> Once booted the sysupgrade image can be flashed from the booted iniramfs 
>> LEDE.
>> 
>> Only abnormality is that for some unknown reason the txpower cannot be set 
>> higher than 16 dBm whereas the Engenius stock firmware allows a maximum of 
>> 27 dBm.
> 
> Yes, difference is software only. ALL0258N came with OpenWrt
> pre-flashed, hence we contributed the needed bits upstream. Also went
> through ODM QA with OpenWrt, so EEPROM might not be identical for
> ENH200 and ALL0258N (the latter was intended to run OpenWrt with ath9k
> as well as Atheros SDK's proprietary driver).
Could the lower maximum txpower be the result of not running with the 
proprietary driver ?
> 
>> 
>> Signed-off-by: Paul Oranje <p...@xs4all.nl>
>> ---
>> package/boot/uboot-envtools/files/ar71xx   |  1 +
>> target/linux/ar71xx/base-files/etc/board.d/01_leds |  3 +-
>> .../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  |  6 +-
>> target/linux/ar71xx/config-4.4 |  1 +
>> .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  9 +++
>> target/linux/ar71xx/files/arch/mips/ath79/Makefile |  1 +
>> .../ar71xx/files/arch/mips/ath79/mach-enh200ext.c  | 89 
>> ++
> ^^^
> Please merge this with mach-all0258n.c so we don't have tons of
> redundant code. Make them share most of the setup code, maybe
> parametrisize the LEDs so you can pass a string and then just have
> two MIPS_MACHINE lines at the bottom of the file. Take a look at
> various mach-tl-*.c files which usually are for several similar
> models each.
What would the source file with the merged support be named, mach-all0258n.c, 
mach-enh20x.c, or … ?

A few more questions:
Apart from this file and putting the dev’s make stances in generic.mk, which of 
the other files that were patched with the v1 patch should be handled 
differently ?
When changing the make stances, what is a good way to rebuild the config 
without going through make clean (my build laptop sports just 3 GB and an Intel 
C2D, so a complete build does take quite some time) ?


> 
> Cheers
> 
> Daniel
> 
> ___
> 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] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

This POE access point suited for outside usage needs an external antenna.
According FCC documentation the ENH200EXT (needs external antenna) and the 
ENH200 (with internal antenna) are electrically equal to the Allnet ALL0258N.

The stock image does not allow install of a LEDE factory image, but an 
initramfs image (lede-ar71xx-generic-enh200ext-initramfs-uImage.bin) can be 
loaded via u-boot recovery procedure (long press reset at power-on until all 
LEDS burn). The u-boot recovery procedure boots an image named 
vmlinux-art-ramdisk from 192.168.1.101.
Once booted the sysupgrade image can be flashed from the booted iniramfs LEDE.

Only abnormality is that for some unknown reason the txpower cannot be set 
higher than 16 dBm whereas the Engenius stock firmware allows a maximum of 27 
dBm.

Signed-off-by: Paul Oranje <p...@xs4all.nl>
---
package/boot/uboot-envtools/files/ar71xx   |  1 +
target/linux/ar71xx/base-files/etc/board.d/01_leds |  3 +-
.../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  |  6 +-
target/linux/ar71xx/config-4.4 |  1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  9 +++
target/linux/ar71xx/files/arch/mips/ath79/Makefile |  1 +
.../ar71xx/files/arch/mips/ath79/mach-enh200ext.c  | 89 ++
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h |  1 +
target/linux/ar71xx/image/legacy-devices.mk|  6 ++
target/linux/ar71xx/image/legacy.mk|  2 +
target/linux/ar71xx/mikrotik/config-default|  1 +
target/linux/ar71xx/nand/config-default|  1 +
14 files changed, 122 insertions(+), 3 deletions(-)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-enh200ext.c

diff --git a/package/boot/uboot-envtools/files/ar71xx 
b/package/boot/uboot-envtools/files/ar71xx
index 3a5d269..a104c3a 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -27,6 +27,7 @@ cpe870|\
cr3000|\
cr5000|\
eap300v2|\
+enh200ext|\
gl-ar300m|\
hornet-ub|\
hornet-ub-x2|\
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 686ae31..cf9c3ae 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -28,7 +28,8 @@ alfa-nx)
ucidef_set_led_netdev "lan" "LAN" "alfa:green:led_3" "eth1"
;;
all0258n|\
-all0315n)
+all0315n|\
+enh200ext)
ucidef_set_rssimon "wlan0" "20" "1"
ucidef_set_led_rssi "rssilow" "RSSILOW" "$board:red:rssilow" "wlan0" 
"1" "40" "0" "6"
ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" 
"$board:yellow:rssimedium" "wlan0" "30" "80" "-29" "5"
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 20b34e8..014404e 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -155,6 +155,7 @@ ar71xx_setup_interfaces()
dlan-hotspot|\
dlan-pro-500-wp|\
dr344|\
+   enh200ext|\
ja76pf2|\
rocket-m-ti|\
ubnt-unifi-outdoor)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 4951e5b..f365feb 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -619,6 +619,9 @@ ar71xx_board_detect() {
*"EmbWir-Dorin-Router")
name="ew-dorin-router"
;;
+   *"ENH200EXT")
+   name="enh200ext"
+   ;;
*"EPG5000")
name="epg5000"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 364a32f..b4a84c2 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -332,7 +332,8 @@ platform_check_image() {
cap324|\
cap4200ag|\
cr3000|\
-   cr5000)
+   cr5000|\
+   enh200ext)
platform_check_image_allnet "$1" && return 0
return 1
;;
@@ -721,7 +722,8 @@ platform_do_upgrade() {
local board=$(ar71xx_board_name)

case "$board" in
-   all0258n)
+   all0258n|\
+   enh200ext)
platform_do_upgrade_allnet "0x9f05" "$ARGV"
;;
all0305|\
diff --git a/target/linux/a

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 <ericluehr...@hotmail.com> 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

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

[Paul Oranje]

Small addition (the following may be non-obvious to those not involved in this 
discussion).
Just saw that A_TA does not have renewal (T1) or rebinding (T2) fields and for 
that reason cannot suit a use-case like a IA just for a work shift.
-- 
Paul


> Op 11 mrt. 2017, om 13:21 heeft Paul Oranje <phora...@gmail.com> het volgende 
> geschreven:
> 
>> 
>> Op 11 mrt. 2017, om 06:09 heeft Eric Luehrsen <ericluehr...@hotmail.com> het 
>> volgende geschreven:
>> 
>> On 03/10/2017 09:09 AM, Bjørn Mork wrote:
>>> Eric Luehrsen <ericluehr...@hotmail.com> writes:
>>>> It appears many other severs and clients dont implement IA_TA. Its a lost 
>>>> option.
>>> Sure. Very few want this feature. We must however assume that those
>>> who do want it will implement it.
>> We must however assume nothing. We may assume something while patiently 
>> waiting for information so we can progress on an idea.
>>>> It should not break "expectations" as this an central administrative
>>>> option.
>>> A client requesting an IA_NA expects a non-temporary address.
>>> 
>> I hate being "legislative" about engineering, but it looks like this is 
>> headed that way, so I'll bite. First in all engineering requirements you 
>> must define your terms. "non-temporary" does not mean "permanent" and it 
>> appears it is carefully avoided as such. In fact the only implied 
>> definition through the chain of RFC is "non-temporary" is just not the 
>> same as "temporary." "temporary" could be summarized as having the 
>> potential for even per connection or per application duration. With that 
>> "non-temporary" can reasonably be defined by the local site 
>> administration as a work shift (8hrs) or something like that.
> rfc3315#section-12 refers to rfc3041 for the definition of temporary 
> addresses.
> The usage of temporary addresses by rfc3041 (Privacy Extensions for Stateless 
> Address Autoconfiguration in IPv6) seems to imply, a contrario, that 
> non-temporary addresses are _not_ to be used for the privacy purposes.
> Strictly logically this implication is incorrect, but still it very much 
> aligns with understandable and reasonable expectations. Anyway, non-temporary 
> isn’t the same as permanent.
> 
>> This means "non-temporary" is a policy decision by the organization 
>> management ("oh no" software engineers cry, "not management"). If 
>> management wants DHCPv6 to provide a single address per user level 
>> machine, then that's their decision to make. If management wants that 
>> each work day or each work shift enumerates all user level machines 
>> differently, then that's their decision to make.  DHCPv6 IA_NA then is 
>> the one and only address that your issued device gets, and it is 
>> different each work day. Static servers may have predefined host 
>> assignments, which I only mention for completeness.
> 
>>>> If central IT doesnt want user base devices to be permanently reachable
>>>> or traceable, then that is their authority to choose.
>>> Definitely.  They can easily achieve this by not providing any IA_NA
>>> adresses.
>> How is that an answer for above management attempting to implement a 
>> particular policy? DHCPv6 IA_TA is not option for (any?) clients. By 
>> your implied definition, a client device would get also an IA_NA that is 
>> "more lasting." It may try to use it, but management doesn't want that. 
>> DHCPv6 without something else leaves devices easily profiled from 
>> external snooping. It's not MAC but not good either. SLAAC exposes the 
>> MAC publicly. SLAAC+privacy is internally difficult to trace, so likely 
>> fail accountability. SLAAC w/ RA rolling hash isn't any more implemented 
>> than IA_TA.
> (mind you, I am not an expert and the following could be utter nonsense).
> Given these use-cases (IAs per work shift etc), why couldn’t these be 
> fulfilled with IA_TA ?
> Both types of associations are within control of the server and hence of 
> whatever management policy, or would the use of IA_NA be necessitated because 
> clients tend not request these ?
> If so, then use of IA_TA is a client policy, and support of those by the 
> DHCPv6 server would be nice. Where the intended enhancement of privacy is a 
> server policy and the client does not request IA_TA, use of IA_NA for this 
> purpose seems alright since whatever address is provided is within the realm 
> of the server for whatever policy it implements thereby.
> 
>>> 
>>>

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

[Paul Oranje]

> Op 11 mrt. 2017, om 06:09 heeft Eric Luehrsen  het 
> volgende geschreven:
> 
> On 03/10/2017 09:09 AM, Bjørn Mork wrote:
>> Eric Luehrsen  writes:
>>> It appears many other severs and clients dont implement IA_TA. Its a lost 
>>> option.
>> Sure. Very few want this feature. We must however assume that those
>> who do want it will implement it.
> We must however assume nothing. We may assume something while patiently 
> waiting for information so we can progress on an idea.
>>> It should not break "expectations" as this an central administrative
>>> option.
>> A client requesting an IA_NA expects a non-temporary address.
>> 
> I hate being "legislative" about engineering, but it looks like this is 
> headed that way, so I'll bite. First in all engineering requirements you 
> must define your terms. "non-temporary" does not mean "permanent" and it 
> appears it is carefully avoided as such. In fact the only implied 
> definition through the chain of RFC is "non-temporary" is just not the 
> same as "temporary." "temporary" could be summarized as having the 
> potential for even per connection or per application duration. With that 
> "non-temporary" can reasonably be defined by the local site 
> administration as a work shift (8hrs) or something like that.
rfc3315#section-12 refers to rfc3041 for the definition of temporary addresses.
The usage of temporary addresses by rfc3041 (Privacy Extensions for Stateless 
Address Autoconfiguration in IPv6) seems to imply, a contrario, that 
non-temporary addresses are _not_ to be used for the privacy purposes.
Strictly logically this implication is incorrect, but still it very much aligns 
with understandable and reasonable expectations. Anyway, non-temporary isn’t 
the same as permanent.

> This means "non-temporary" is a policy decision by the organization 
> management ("oh no" software engineers cry, "not management"). If 
> management wants DHCPv6 to provide a single address per user level 
> machine, then that's their decision to make. If management wants that 
> each work day or each work shift enumerates all user level machines 
> differently, then that's their decision to make.  DHCPv6 IA_NA then is 
> the one and only address that your issued device gets, and it is 
> different each work day. Static servers may have predefined host 
> assignments, which I only mention for completeness.

>>> If central IT doesnt want user base devices to be permanently reachable
>>> or traceable, then that is their authority to choose.
>> Definitely.  They can easily achieve this by not providing any IA_NA
>> adresses.
> How is that an answer for above management attempting to implement a 
> particular policy? DHCPv6 IA_TA is not option for (any?) clients. By 
> your implied definition, a client device would get also an IA_NA that is 
> "more lasting." It may try to use it, but management doesn't want that. 
> DHCPv6 without something else leaves devices easily profiled from 
> external snooping. It's not MAC but not good either. SLAAC exposes the 
> MAC publicly. SLAAC+privacy is internally difficult to trace, so likely 
> fail accountability. SLAAC w/ RA rolling hash isn't any more implemented 
> than IA_TA.
(mind you, I am not an expert and the following could be utter nonsense).
Given these use-cases (IAs per work shift etc), why couldn’t these be fulfilled 
with IA_TA ?
Both types of associations are within control of the server and hence of 
whatever management policy, or would the use of IA_NA be necessitated because 
clients tend not request these ?
If so, then use of IA_TA is a client policy, and support of those by the DHCPv6 
server would be nice. Where the intended enhancement of privacy is a server 
policy and the client does not request IA_TA, use of IA_NA for this purpose 
seems alright since whatever address is provided is within the realm of the 
server for whatever policy it implements thereby.

>> 
>>> But on the flip side, central IT doesnt want the insanity of SLAAC
>>> Privacy all over their network. Consider a fortune 500 company or
>>> university with accountibilty and traceability in legal or internal
>>> policy requirements.
>>> 
>>> RFC are so namef for a reason and a good working model can change them.
>> OK, I think you just explained your level of understanding.  Thanks
> I'll pretend that it doesn't mean how it reads.
I’ve read the sentence a few times over and still cannot make out what would be 
meant be it. Still given the effort made to sensibly discus this subject one 
would be wise to read it positively.
(credo: when a positive explanation exists that is as reasonable as any other, 
pick the positive one)

> 
> - Eric
--
Paul

> ___
> 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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[Paul Oranje]

Nevertheless, wouldn’t it be wise to ask SPI to also handle trademark issues 
around the name lede(-project) ?

Irrespective of the outcome of this discussion about which name to use when the 
projects would be merged, having some protection around the name seems wise and 
SPI exists for that very reason 
(https://en.wikipedia.org/wiki/Software_in_the_Public_Interest). BTW, the TM 
record for LEDE mentioned by Dave has USPTO serial number 86650406.

And about what name to choose, the banner (shell) for LEDE looks much, much, 
nicer than that of OpenWRT.
To leverage the general fame of OpenWRT, as already suggested by John, 
redirects and keeping archives of (outdated) documentation would probably 
suffice.

— 
Paul Oranje


> Op 22 dec. 2016, om 08:17 heeft John Crispin <j...@phrozen.org> het volgende 
> geschreven:
> 
> 
> 
> On 22/12/2016 04:45, Dave Taht wrote:
>> Lede trademark...
>> 
>> Published for Opposition:December 20, 2016
>> 
>> sigh.
>> 
> 
> *slap on the wrist or top posting*
> 
> the project is called lede-project and not lede for a reason ;)
> 
>   John
> 





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

Re: [LEDE-DEV] Documentation for router support means the famous Table of Hardware

[Paul Oranje]

l.s.

For a heritage wiki that I helped set-up a few years ago 
(www.culturalheritageconnections.org) a combination of structured data and 
“normal” unstructured information was used.

This set-up deploys semantic extensions to mediawiki where the structured data 
is captured in semantic properties and edited by means of semantic forms that 
ensure that certain information is automatically assigned to the semantic 
properties. Most if not all structured data is shown on the pages in so-called 
info boxes (like in wilipedia), and the information can be searched by 
properties, by category (really also a property) and also semantic query forms. 
An initial set of such pages can be generated from data contained in an SQL 
database.

In short: a wiki that combines structured data with more or less unstructured 
information is very well possible and the existing dataset can be used as a 
start where all structured data is converted into semantic properties.

Regards,
-- 
Paul Oranje


> Op 14 sep. 2016, om 00:57 heeft Jo-Philipp Wich <j...@mein.io> het volgende 
> geschreven:
> 
> Hi Tarek,
> 
> Thomas Endt and others invested a lot of time to implement a structured
> table of hardware in the OpenWrt wiki, which means that a lot of detail
> information is accessible in a SQLite3 database file which should make
> it easy to generate hardware documentation pages with a little script
> and a few self-join queries.
> 
> I also think that such a model would be a viable option for the future:
> have a structured data entry dialog in the wiki which fills a database,
> have all the surrounding wiki capabilities for free text information and
> use the resulting database backend data to provide other, non-wiki
> services like a vendor/model search to to download link redirection.
> 
> 
> Imho a well maintained hardware database is a very important topic for
> LEDE, OpenWrt and other associated projects but we need to find a sane
> middle ground that does not upset too many potential contributors but
> still yields a reasonable data quality...
> 
> On a related note I wonder if anyone ever thought about joining forces
> with WikiDevi? It seems like a perfectly reasonable thing to do but I
> recall that the site operators are rather hard to contact.
> 
> 
> Just my two cents :)
> 
> 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

Re: [LEDE-DEV] looking for ar7 testers

[Paul Oranje]

> Van: David Lang <da...@lang.hm>
> Onderwerp: Antw.: [LEDE-DEV] looking for ar7 testers
> Datum: 20 juni 2016 02:51:29 CEST
> Aan: Daniel Curran-Dickinson <dan...@daniel.thecshore.com>
> Kopie: John Crispin <j...@phrozen.org>, LEDE Development List 
> <lede-dev@lists.infradead.org>
> 
> ...
> 
> Well, I'll point out that the thread I'm replying to started off with "I no 
> longer have the hardware to test this"
> 
> I agree that random, unsolicited donations are likely to be less useful, but 
> donations of hardware to solve the "I can't test this" or add to a test farm 
> are directly useful.
> 
> And getting a new piece of equipment can get a developer interested enough to 
> go after the NDAs needed to make it work well.
> 
> In some cases the vendors involved are known to 'not play well with others' 
> and so donations of their hardware will do no good.
> 
> But those of us out in the wild can't tell the difference between the 
> different categories.
> 
> That's why I asked for a list of what would be useful to donate :-)
> 
> David Lang

Nice that you offer help, but NDA’s don’t play well with open source 
development and are certainly problematic when such development is under a copy 
left type of licence (GPL/CC SA etc.). Documentation such as datasheets needed 
for coding should be offered unencumbered by NDA provisions.

Paul Oranje


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