Re: PATCH: udhcpc -- don't request set of options by default
On Tuesday 01 April 2008 23:37:38 L. Gabriel Somlo wrote: On Wed, Apr 02, 2008 at 12:14:14AM +0200, Denys Vlasenko wrote: Imagine that I have *two* interfaces, both sit on DHCP configured networks (*different* networks). Here one deconfig-ed iface will happily nuke /etc/resolv.conf created by another interface: The real question is, who wins w.r.t. /etc/resolv.conf when multiple dhcp-configured interfaces are up simultaneously ? This is already a fun problem for laptops that connect both on wireless and on wired ethernet, and it's a trainwreck, ifupdown or not... This fun problem has already been resolved by resolvconf. I have an implementation called openresolv that works on POSIX shells and tools, unlike the Debian original. You can read about it some more here. http://roy.marples.name/openresolv Thanks Roy ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: PATCH: udhcpc -- don't request set of options by default
On Wednesday 02 April 2008 02:58, L. Gabriel Somlo wrote: I am thinking - maybe we should just junk the idea of default options to ask for? We can ask user to always provide explicit list of -O OPTs to ask. What do you think? I agree. Although others might yell at us if we change default behavior :) Yup. So I will not... Patch is applied, thanks! -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: PATCH: udhcpc -- don't request set of options by default
L. Gabriel Somlo schrieb:
I am thinking - maybe we should just junk the idea of default
options to ask for? We can ask user to always provide explicit
list of -O OPTs to ask. What do you think?
I agree. Although others might yell at us if we change default
behavior :)
Please take a look at attached patch - will this work for you?
...
+if (client_config.no_default_options)
+return;
+
This returns before -O explicit options have a chance to be added,
doesn't it ?
packet-options[end + OPT_CODE] = DHCP_PARAM_REQ;
for (i = 0; (c = dhcp_options[i].code) != 0; i++) {
if ((dhcp_options[i].flags OPTION_REQ)
@@ -107,7 +110,9 @@ int send_discover(uint32_t xid, uint32_t
/* Explicitly saying that we want RFC-compliant packets helps
* some buggy DHCP servers to NOT send bigger packets */
add_simple_option(packet.options, DHCP_MAX_SIZE, htons(576));
Junking default options altogether definitely feels cleaner, no need
to monkey around with all this '-o' stuff... :) Would anyone be truly
horrified to see that happen ?
I think I was the one that requested this feature some time ago, and I've no
problem with
this change, as long as it is mentioned on busybox.net :)
Cheers
Stefan
BTW, I really did like the [[ %udhcpc_opts%]] idea, I'd like that at
least to stay... :)
Thanks,
--Gabriel
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: PATCH: udhcpc -- don't request set of options by default
On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote:
Last, but not least, a slightly more complex sample udhcpc.script,
which attempts to react to changes in parameters returned by the dhcp
server in a minimal-effort sort of way (i.e. don't reconfigure the
interface if the only change was in the list of ntp servers, etc.)
Imagine that I have *two* interfaces, both sit on DHCP configured
networks (*different* networks).
Here one deconfig-ed iface will happily nuke /etc/resolv.conf
created by another interface:
+case $1 in
+ deconfig)
+ip addr flush dev $interface
+ip link set up dev $interface
+rm -f $CFG
+if [ $PEERDNS_IF == $interface ] ; then
+ [ -f ${RESOLV_CONF}.dhcsave ] mv -f ${RESOLV_CONF}.dhcsave
$RESOLV_CONF
+fi
+if [ $PEERNTP_IF == $interface ] ; then
+ [ -f ${NTP_CONF}.dhcsave ] mv -f ${NTP_CONF}.dhcsave $NTP_CONF
+fi
+;;
+ bound)
+set $CFG
+ip addr flush dev $interface
+[ -n $mtu ] ip link set mtu $mtu dev $interface
+ip addr add ${ip}/${mask} dev $interface
+[ -n $router ] ip route add default via ${router%% *} dev $interface
+if [ $PEERDNS_IF == $interface ] ; then
+ [ -f $RESOLV_CONF ] mv -f $RESOLV_CONF ${RESOLV_CONF}.dhcsave
+ [ -n $domain ] echo search $domain $RESOLV_CONF
+ for i in $dns ; do
+echo nameserver $i $RESOLV_CONF
+ done
+fi
Attempt to correctly express configurational logic in dhcp scripts
is doomed to fail IMO. It will only get more and more contrived
when you try to cater for more and more weird races.
I tried to explain it here:
http://busybox.net/~vda/no_ifup.txt
--
vda
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: PATCH: udhcpc -- don't request set of options by default
On Wed, Apr 02, 2008 at 12:14:14AM +0200, Denys Vlasenko wrote:
On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote:
Last, but not least, a slightly more complex sample udhcpc.script,
which attempts to react to changes in parameters returned by the dhcp
server in a minimal-effort sort of way (i.e. don't reconfigure the
interface if the only change was in the list of ntp servers, etc.)
Imagine that I have *two* interfaces, both sit on DHCP configured
networks (*different* networks).
Here one deconfig-ed iface will happily nuke /etc/resolv.conf
created by another interface:
I agree with your no_ifup blurb in principle. However, this is not
about ifupdown at all (adding a way to pass no-default-options to
udhcpc from ifupdown was an afterthought since I happen to use
ifupdown, but totally unrelated to the udhcpc sample script).
The real question is, who wins w.r.t. /etc/resolv.conf when multiple
dhcp-configured interfaces are up simultaneously ? This is already a
fun problem for laptops that connect both on wireless and on wired
ethernet, and it's a trainwreck, ifupdown or not...
+case $1 in
+ deconfig)
+if [ $PEERDNS_IF == $interface ] ; then
+ [ -f ${RESOLV_CONF}.dhcsave ] mv -f ${RESOLV_CONF}.dhcsave
$RESOLV_CONF
+fi
+if [ $PEERNTP_IF == $interface ] ; then
+ [ -f ${NTP_CONF}.dhcsave ] mv -f ${NTP_CONF}.dhcsave $NTP_CONF
+fi
In my udhcpc.script sample I declare an interface to be the owner of
resolv.conf (e.g. PEERDNS_IF=eth0), and only when eth0 goes down does
resolv.conf get nuked. Deconfig-ing eth1 doesn't do anything to
resolv.conf.
This does have its own drawbacks, for sure, but we first need to have
a rule about what what happens in this scenario:
- eth0 comes up
- we request a dhcp lease, and receive back a bunch of stuff (e.g.
nameservers)
- we populate /etc/resolv.conf with these nameservers
- now, while eth0 stays up, eth1 comes up also
- we request a dhcp lease for eth1, and receive back a bunch of stuff
(including a *different* set of nameservers)
- ???
Do we overwrite resolv.conf, or do we add the new nameservers to the
list (and if we add them, where, at the front or back of the list ?)
If we add them to the front, it's almost like we overwrote resolv.conf
(the new nameserver gets queried for *everything* with precendence).
If we add to the back, it's like we didn't overwrite resolv.conf at
all (eth0's nameserver gets queried for *everything* with precedence).
So, what I'm trying to say, this is not really an ifupdown is
bad/good/ugly problem, but rather how do we reconcile information
received via dhcp on multiple interfaces?; My (yes, possibly flawed)
answer was hardcode a winner, but what's the right thing to do ?
Thanks,
Gabriel
PS. Here's a simplified patch that only addresses the '-o' or
'--no-default-options' change to udhcpc, leaving out ifupdown and the
sample udhcpc.script, since they are really totally separate issues.
Please apply this one while we figure out what to do with resolv.conf
:)
diff -NarU5 busybox-svn-21617.orig/include/usage.h
busybox-svn-21617/include/usage.h
--- busybox-svn-21617.orig/include/usage.h 2008-04-01 14:47:29.0
-0400
+++ busybox-svn-21617/include/usage.h 2008-04-01 15:20:40.0 -0400
@@ -4114,11 +4114,11 @@
[-T last-check-time] [-U UUID] device
#define tune2fs_full_usage \
Adjust filesystem options on ext[23] filesystems
#define udhcpc_trivial_usage \
- [-Cfbnqtv] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]\n \
+ [-Cfbnqtvo] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]\n \
[-p pidfile] [-r IP] [-s script] [-O dhcp-option]...
USE_FEATURE_UDHCP_PORT( [-P N])
#define udhcpc_full_usage \
USE_GETOPT_LONG( \
-V,--vendorclass=CLASSIDVendor class identifier \
\n -i,--interface=INTERFACEInterface to use (default
eth0) \
@@ -4142,10 +4142,11 @@
\n -P,--client-port N Use port N instead of default 68 \
) \
USE_FEATURE_UDHCPC_ARPING( \
\n -a,--arping Use arping to validate offered address \
) \
+ \n -o,--no-default-options Do not request options by default \
) \
SKIP_GETOPT_LONG( \
-V CLASSID Vendor class identifier \
\n -i INTERFACEInterface to use (default: eth0) \
\n -H,-h HOSTNAME Client hostname \
diff -NarU5 busybox-svn-21617.orig/networking/udhcp/clientpacket.c
busybox-svn-21617/networking/udhcp/clientpacket.c
--- busybox-svn-21617.orig/networking/udhcp/clientpacket.c 2008-04-01
14:47:25.0 -0400
+++ busybox-svn-21617/networking/udhcp/clientpacket.c 2008-04-01
15:04:18.0 -0400
@@ -62,11 +62,11 @@
int end = end_option(packet-options);
int i, len = 0;
packet-options[end + OPT_CODE] = DHCP_PARAM_REQ;
for (i = 0; (c = dhcp_options[i].code) != 0; i++) {
- if
Re: PATCH: udhcpc -- don't request set of options by default
On Wednesday 02 April 2008 00:37, L. Gabriel Somlo wrote: I agree with your no_ifup blurb in principle. However, this is not about ifupdown at all (adding a way to pass no-default-options to udhcpc from ifupdown was an afterthought since I happen to use ifupdown, but totally unrelated to the udhcpc sample script). The real question is, who wins w.r.t. /etc/resolv.conf when multiple dhcp-configured interfaces are up simultaneously ? This is already a fun problem for laptops that connect both on wireless and on wired ethernet, and it's a trainwreck, ifupdown or not... I though I explained it on that page... my DHCP client's script basically just dumps obtained into in a file in this form: /var/run/service/fw/dhcp_if.ipconf == let cfg=cfg+1 if[$cfg]='if' ip[$cfg]='89.102.207.196' ipmask[$cfg]='89.102.207.196/24' gw[$cfg]='89.102.207.1' dns[$cfg]='213.46.172.36 213.46.172.37' net[$cfg]='0/0' and then executes sv u /var/service/fw (sv is a busybox applet, works in concert with runsv). /var/service/fw is a runsv-controlled service with service script which starts as: /var/service/fw/run: === #!/bin/sh # Make ourself one-shot sv o . CRUCIAL ... I will omit the details. Important things are: * /var/service/fw/run is ran _anytime_ network config is changed, and it sees _entire_ config state. For example, it can go through /var/run/service/fw/*.ipconf files and find out ALL INTERFACES' addresses; this does not cover only dhcp, but pppd, openvpn, you name it (and of course static ones). * this script cat decide _globally_ what to write to /etc/resolv.conf [and there is no need to save it], what will be set as default route, how to configure DNS, NTP, firewall, trafic shaping, etc * Execution of /var/service/fw/run is _serialized_ (by nature how sv u + sv o interact). If many dhcpc's, openvpn's, pppd's etc are racing to run it, it can be executed several times, but NEVER IN PARALLEL. (basically, if e.g. openvpn does sv u /var/service/fw while it still runs because of earlier dhcp config, it will rerun again... ...and set itself to one shot, do not rerun until 'sv upped' again mode with that sv o . cmd). Yes, the script can get complex, but it does not need to worry about races, and therefore conceptually it is simple: * Lets take a look at the state of ALL links and decide what to do. * Deconfigure everything: ip a f dev $EVERY_IF ip r f dev $EVERY_IF root 0/0 iptables --flush iptables --delete-chain iptables -t nat--flush iptables -t nat--delete-chain iptables -t mangle --flush iptables -t mangle --delete-chain ... * Configure everything back. You can try and play with if changes are small, dont deconf everything but I don't find it useful - script gets more complex. -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: PATCH: udhcpc -- don't request set of options by default
On Wednesday 02 April 2008 00:37, L. Gabriel Somlo wrote: In my udhcpc.script sample I declare an interface to be the owner of resolv.conf (e.g. PEERDNS_IF=eth0), and only when eth0 goes down does resolv.conf get nuked. Deconfig-ing eth1 doesn't do anything to resolv.conf. This does have its own drawbacks, for sure, but we first need to have a rule about what what happens in this scenario: - eth0 comes up - we request a dhcp lease, and receive back a bunch of stuff (e.g. nameservers) - we populate /etc/resolv.conf with these nameservers - now, while eth0 stays up, eth1 comes up also - we request a dhcp lease for eth1, and receive back a bunch of stuff (including a *different* set of nameservers) - ??? Do we overwrite resolv.conf, or do we add the new nameservers to the list (and if we add them, where, at the front or back of the list ?) If we add them to the front, it's almost like we overwrote resolv.conf (the new nameserver gets queried for *everything* with precendence). If we add to the back, it's like we didn't overwrite resolv.conf at all (eth0's nameserver gets queried for *everything* with precedence). So, what I'm trying to say, this is not really an ifupdown is bad/good/ugly problem, but rather how do we reconcile information received via dhcp on multiple interfaces?; My (yes, possibly flawed) answer was hardcode a winner, but what's the right thing to do ? To completely rewrite /etc/resolv.conf when either of eth0/1/99 changes state, taking in consideration the state of all links. No appending, prependind or parsing of /etc/resolv.conf is necessary. Just regenerate it. It should be possible, because you have all necessary data to decide. How to break ties is an admin task, and it's usually easy: I prefer eth3 or I prefer ppp0. However I can imagine some people will even want to set up multipath routing if many links are up. -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: PATCH: udhcpc -- don't request set of options by default
On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote:
Denys All,
I noticed that udhcpc sends a default list of options in its request
(i.e., all options listed with flag OPTION_REQ in options.c)
That's bad, at least when used with some versions of isc dhcpd, which
will only include the requested options in a reply.
I know about the -O flag that can get udhcpc to request extra options,
but what if I want to see options I didn't think about asking for ?
Including a default option list in the request will always preclude me
from seeing options I didn't know to ask for.
USE_FEATURE_UDHCPC_ARPING( \
\n -a,--arping Use arping to validate offered address \
) \
+ \n -o,--no-default-options Do not request options by default \
) \
SKIP_GETOPT_LONG( \
SKIP_GETOPT_LONG case also needs -o covered.
- O:
+ O:o:
-o does not take a param, should be O:o.
packet-options[end + OPT_CODE] = DHCP_PARAM_REQ;
for (i = 0; (c = dhcp_options[i].code) != 0; i++) {
- if ((dhcp_options[i].flags OPTION_REQ)
+ if (((dhcp_options[i].flags OPTION_REQ)
!client_config.no_default_options) //vda
|| (client_config.opt_mask[c 3] (1 (c 7)))
) {
packet-options[end + OPT_DATA + len] = c;
len++;
}
so, you create empty DHCP_PARAM_REQ. Why not just omitting it
at all like this?
- add_param_req_option(packet);
+ if (!client_config.no_default_options)
+ add_param_req_option(packet);
I've added the '-o' command line flag to udhcpc, which inhibits
inclusion of default options in the request. Options can still be
explicitly requested with -O.
I am thinking - maybe we should just junk the idea of default
options to ask for? We can ask user to always provide explicit
list of -O OPTs to ask. What do you think?
I have also added a mechanism to request '-o' (actually, its long form
--no-default-options) from ifupdown's /etc/network/interfaces:
auto eth0
iface eth0 inet dhcp
nodefaultopts --no-default-options
Please take a look at attached patch - will this work for you?
--
vda
diff -d -urpN busybox.3/include/usage.h busybox.4/include/usage.h
--- busybox.3/include/usage.h 2008-03-31 21:26:17.0 +0200
+++ busybox.4/include/usage.h 2008-04-02 01:36:14.0 +0200
@@ -4116,7 +4116,7 @@
Adjust filesystem options on ext[23] filesystems
#define udhcpc_trivial_usage \
- [-Cfbnqtv] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]\n \
+ [-Cfbnqtvo] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]\n \
[-p pidfile] [-r IP] [-s script] [-O dhcp-option]... USE_FEATURE_UDHCP_PORT( [-P N])
#define udhcpc_full_usage \
USE_GETOPT_LONG( \
@@ -4131,13 +4131,14 @@
\n -t,--retries=N Send up to N request packets \
\n -T,--timeout=N Try to get a lease for N seconds (default 3) \
\n -A,--tryagain=N Wait N seconds (default 20) after failure \
+ \n -O,--request-option=OPT Request DHCP option OPT from server \
+ \n -o,--no-default-options Do not request options by default \
\n -f,--foreground Run in foreground \
\n -b,--background Background if lease is not immediately obtained \
\n -S,--syslog Log to syslog too \
\n -n,--now Exit with failure if lease is not immediately obtained \
\n -q,--quit Quit after obtaining lease \
\n -R,--release Release IP on quit \
- \n -O,--request-option=OPT Request DHCP option OPT from server \
USE_FEATURE_UDHCP_PORT( \
\n -P,--client-port N Use port N instead of default 68 \
) \
@@ -4157,13 +4158,14 @@
\n -t N Send up to N request packets \
\n -T N Try to get a lease for N seconds (default 3) \
\n -A N Wait N seconds (default 20) after failure \
+ \n -O OPT Request DHCP option OPT from server \
+ \n -o Do not request options by default \
\n -f Run in foreground \
\n -b Background if lease is not immediately obtained \
\n -S Log to syslog too \
\n -n Exit with failure if lease is not immediately obtained \
\n -q Quit after obtaining lease \
\n -R Release IP on quit \
- \n -O OPT Request DHCP option OPT from server \
USE_FEATURE_UDHCP_PORT( \
\n -P N Use port N instead of default 68 \
) \
diff -d -urpN busybox.3/networking/ifupdown.c busybox.4/networking/ifupdown.c
--- busybox.3/networking/ifupdown.c 2008-03-31 21:26:06.0 +0200
+++ busybox.4/networking/ifupdown.c 2008-04-02 01:47:14.0 +0200
@@ -476,7 +476,8 @@ static const struct dhcp_client_t ext_dh
pump -i %iface% -k,
},
{ udhcpc,
- udhcpc -R -n -p /var/run/udhcpc.%iface%.pid -i %iface%[[ -H %hostname%]][[ -c %clientid%]][[ -s %script%]][[ -t %retries%]],
+ udhcpc -R -n -p /var/run/udhcpc.%iface%.pid -i %iface%[[ -H %hostname%]][[ -c %clientid%]]
+[[ -s
Re: PATCH: udhcpc -- don't request set of options by default
I am thinking - maybe we should just junk the idea of default
options to ask for? We can ask user to always provide explicit
list of -O OPTs to ask. What do you think?
I agree. Although others might yell at us if we change default
behavior :)
Please take a look at attached patch - will this work for you?
...
+ if (client_config.no_default_options)
+ return;
+
This returns before -O explicit options have a chance to be added,
doesn't it ?
packet-options[end + OPT_CODE] = DHCP_PARAM_REQ;
for (i = 0; (c = dhcp_options[i].code) != 0; i++) {
if ((dhcp_options[i].flags OPTION_REQ)
@@ -107,7 +110,9 @@ int send_discover(uint32_t xid, uint32_t
/* Explicitly saying that we want RFC-compliant packets helps
* some buggy DHCP servers to NOT send bigger packets */
add_simple_option(packet.options, DHCP_MAX_SIZE, htons(576));
Junking default options altogether definitely feels cleaner, no need
to monkey around with all this '-o' stuff... :) Would anyone be truly
horrified to see that happen ?
BTW, I really did like the [[ %udhcpc_opts%]] idea, I'd like that at
least to stay... :)
Thanks,
--Gabriel
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
