[Buildroot] [PATCH] package/busybox/udhcpc.script: fix network interface tag comments

[Buildroot] [PATCH] package/busybox/udhcpc.script: fix network interface tag comments

[Quentin Rameau]

Per Linux man-pages resolv.conf(5): "Lines that contain a semicolon (;)
or hash character (#) in the first column are treated as comments."
---
 package/busybox/udhcpc.script | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/busybox/udhcpc.script b/package/busybox/udhcpc.script
index 711963f974..35b4bead85 100755
--- a/package/busybox/udhcpc.script
+++ b/package/busybox/udhcpc.script
@@ -37,7 +37,7 @@ case "$1" in
 		# drop info from this interface
 		# resolv.conf may be a symlink to /tmp/, so take care
 		TMPFILE=$(mktemp)
-		grep -vE "# $interface\$" $RESOLV_CONF > $TMPFILE
+		sed "/^# $interface$/{N;d;}" $RESOLV_CONF > $TMPFILE
 		cat $TMPFILE > $RESOLV_CONF
 		rm -f $TMPFILE
 
@@ -75,7 +75,7 @@ case "$1" in
 		# drop info from this interface
 		# resolv.conf may be a symlink to /tmp/, so take care
 		TMPFILE=$(mktemp)
-		grep -vE "# $interface\$" $RESOLV_CONF > $TMPFILE
+		sed "/^# $interface$/{N;d;}" $RESOLV_CONF > $TMPFILE
 		cat $TMPFILE > $RESOLV_CONF
 		rm -f $TMPFILE
 
@@ -87,11 +87,11 @@ case "$1" in
 		fi
 
 		[ -n "$search_list" ] &&
-			echo "search $search_list # $interface" >> $RESOLV_CONF
+			printf '%s\n' "# $interface" "search $search_list" >> $RESOLV_CONF
 
 		for i in $dns ; do
 			echo adding dns $i
-			echo "nameserver $i # $interface" >> $RESOLV_CONF
+			printf '%s\n' "# $interface" "nameserver $i" >> $RESOLV_CONF
 		done
 		;;
 esac
-- 
2.24.0

[Buildroot] [PATCH] package/busybox/udhcpc.script: fix network interface tag comments

[Thomas Petazzoni]

Hello Quentin,

On Mon, 9 Dec 2019 00:37:56 +0100
Quentin Rameau <quinq@fifth.space> wrote:

> Per Linux man-pages resolv.conf(5): "Lines that contain a semicolon (;)
> or hash character (#) in the first column are treated as comments."

Thanks a lot for your patch! Could you resend it with a "Signed-off-by"
tag with your name/e-mail at the end of the commit log?

Also, I think the commit log should be a bit more verbose, as it took
me some time to reconstruct what is the problem that you're trying to
solve.

A better commit log is probably:

"""

Commit 584f418ec1ae3f0b5e09c10133c82578d78a3e03 ("busybox:
udhcpc.script: fix resolv.conf handling with multiple interfaces")
added some logic in udhcpc.script to "tag" the lines in resolv.conf
according to the network interface they come from, in order to only
remove the relevant lines when an interface goes down.

Due to this, the resolv.conf file looks like this:

nameserver 1.1.1.1 # eth0
nameserver 2.2.2.2 # eth1

However, resolv.conf(5) states that:

       Lines that contain a semicolon (;) or hash character (#) in the first column are treated
       as comments.

So, it seems like comments starting in the middle of the line are not
standard. This commit changes the logic in udhcpc.script to put the
network interface "tag" and the nameserver directive on two separate
lines:

# eth0
nameserver 1.1.1.1
# eth1
nameserver 2.2.2.2

and adjust the logic to delete the appropriate lines when the interface
goes down.
"""

It would be even better if you could describe if you noticed a
practical problem with this. In the commit from 2013, the author (Peter
Korsgaard) said he checked the glibc and uClibc implementation. Did you
encounter a problem with the musl C library ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/busybox/udhcpc.script: fix network interface tag comments

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

[the original mail apparently didn't make it to my mailbox?]

Hello,

 > It would be even better if you could describe if you noticed a
 > practical problem with this. In the commit from 2013, the author (Peter
 > Korsgaard) said he checked the glibc and uClibc implementation. Did you
 > encounter a problem with the musl C library ?

Yes, I wonder what the practical issue is? We have used the current
behaviour for a very long time, so chances are that somebody relies on
it somewhere (E.G. I have myself written code to parse /etc/resolv.conf and
used the marker to know what servers came from DHCP or not), so I would
prefer to not change the implementation if at all possible.

-- 
Bye, Peter Korsgaard