Skip to contentSkip to conversation

package/busybox/udhcpc.script: fix network interface tag comments

PATCH New Quentin Rameau 3 participants 3 messages Dec 8, 2019 – Dec 26, 2019

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 package/busybox/udhcpc.script: fix network interface tag comments

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(-)
package/busybox/udhcpc.script +4 -4
index 711963f974..35b4bead85 100755
@@ -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
Signature · 1 line
2.24.0
#1 lore raw

PATCH 1/1 package/busybox/udhcpc.script: fix network interface tag comments

Hello Quentin,

Quoted 2 lines · On Mon, 9 Dec 2019 00:37:56 +0100 Quentin Rameau <[email protected]> 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

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
#2 lore raw

PATCH 1/1 package/busybox/udhcpc.script: fix network interface tag comments

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

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

Hello,

Quoted 4 lines

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.

Signature · 1 line
Bye, Peter Korsgaard