Re: svn commit: r239356 - head/sbin/dhclient
Hi,
On Thu, 23 Aug 2012 08:41:37 +0400
Andrey Chernov a...@freebsd.org said:
ache On Thu, Aug 23, 2012 at 12:27:46AM +0900, Hajimu UMEMOTO wrote:
A link-local address has a scope; an interface here. You cannot omit
it on FreeBSD by default. To be able to omit it, specify something
like ipv6_default_interface=em0 in your /etc/rc.conf.
ache Please enlighten me a bit.
ache RFC 4007 11.6. Omitting Zone Indices states:
ache The format defined in this document does not intend to invalidate the
acheoriginal format for non-global addresses; that is, the format without
achethe zone index portion. As described in Section 6, in some common
achecases with the notion of the default zone index, there can be no
acheambiguity about scope zones. In such an environment, the
acheimplementation can omit the %zone_id part.
ache Does absolutely trusted IPv6 local net using link-local addresses only
ache falls in that case? If yes, is there a way to make address scope optional
ache for all link-local addresses in FreeBSD?
FreeBSD doesn't have a feature to define a zone manually.
If a node has more than one interfaces, a link-local address without
zone identifer has ambiguity. If you mean `all link-local addresses'
are within one interface, yes, you can omit zone identifer by setting
ipv6_default_interface'
ache Are link-local addresses ever usable for DNS or not due to their
ache %zone_id part? F.e. for the case there is no global IPv6 net assigned
at
ache all but pure isolated IPv6 local network.
In anyway, I don't recommend to use a link-local address for DNS.
ache Is it only due to their scope part or other reasons exists too?
As you saw, dig(1) and host(1) doesn't work well with a link-local
address.
Not only a zone identifier, but also some implementation may handle a
link-local address (fe80:: prefix) as special.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
Hi,
On Wed, 22 Aug 2012 04:06:46 +0400
Andrey Chernov a...@freebsd.org said:
ache BTW, I notice that link-local router address behavior is
ache strange and inconsistant for both 'host -6' and 'dig -6' commands.
ache host -6 example.com fe80::rest of router address
ache dig -6 @fe80::rest of router address example.com
ache both hangs, but in the same time
ache host -6 example.com fe80::rest of router address%iface
ache dig -6 @fe80::rest of router address%iface example.com
ache works!
ache host -6 example.com fe80::rest of router address%1
ache dig -6 #fe80::rest of router address%1 example.com
ache works too. Not understanding addresses without %iface or %1 looks like
ache routing problems, but I don't know where to fix it.
A link-local address has a scope; an interface here. You cannot omit
it on FreeBSD by default. To be able to omit it, specify something
like ipv6_default_interface=em0 in your /etc/rc.conf.
ache So, I try to use
ache nameserver fe80::rest of router address%iface (or with %1 suffix)
ache in my resolv.conf, as result
ache host -6 example.com
ache dig -6 example.com
ache (without NS specified) both hangs despite they working when exact the
same
ache NS address is given in their command lines.
Our stub resolver in libc should work with a link-local address as
nameserver. However, host(1) and dig(1) don't use the stub resolver
in libc, and use its own resolver. I suspect host(1) and dig(1) have
some problem in handling a link-local address.
In anyway, I don't recommend to use a link-local address for DNS.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Thu, Aug 23, 2012 at 12:27:46AM +0900, Hajimu UMEMOTO wrote: A link-local address has a scope; an interface here. You cannot omit it on FreeBSD by default. To be able to omit it, specify something like ipv6_default_interface=em0 in your /etc/rc.conf. Please enlighten me a bit. RFC 4007 11.6. Omitting Zone Indices states: The format defined in this document does not intend to invalidate the original format for non-global addresses; that is, the format without the zone index portion. As described in Section 6, in some common cases with the notion of the default zone index, there can be no ambiguity about scope zones. In such an environment, the implementation can omit the %zone_id part. Does absolutely trusted IPv6 local net using link-local addresses only falls in that case? If yes, is there a way to make address scope optional for all link-local addresses in FreeBSD? Are link-local addresses ever usable for DNS or not due to their %zone_id part? F.e. for the case there is no global IPv6 net assigned at all but pure isolated IPv6 local network. In anyway, I don't recommend to use a link-local address for DNS. Is it only due to their scope part or other reasons exists too? -- http://ache.vniz.net/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
Hi,
On Tue, 21 Aug 2012 08:45:53 +0400
Andrey Chernov a...@freebsd.org said:
ache resolvconf -l output:
ache # resolv.conf from msk0
ache search domain
ache nameserver 192.168.1.1
ache # resolv.conf from msk0:slaac
ache nameserver IPv6 DNS address for the router's IPv6 tunnel
ache (btw, what is slaac?)
It is abbreviation for StateLess Address AutoConfiguration described
in rfc 4862.
This RA option is described in rfc 5006 (IPv6 Router Advertisement
Option for DNS Configuration).
ache And I want to override IPv6 DNS address for the router's IPv6 tunnel
ache with simple link-local IPv6 address of my router, i.e. fe80:...
I think your network admin setup to advertise the address. Why do you
want to use link-local address, instead?
ache Is it possible with resolvconf(8)?
resolvconf(8) doesn't have such rewrite feature. However, rtsol(8)
has -R option to specify your own script to update /etc/resolv.conf.
You may want to write your own script to rewrite nameserver address
then pass it to resolvconf(8).
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Tue, Aug 21, 2012 at 03:16:26PM +0900, Hajimu UMEMOTO wrote: ache And I want to override IPv6 DNS address for the router's IPv6 tunnel ache with simple link-local IPv6 address of my router, i.e. fe80:... I think your network admin setup to advertise the address. Why do you want to use link-local address, instead? I am network admin, but what router advertise is out my easy control (fixing configs in the Linux router's FS or even rebuilding router components is needed, I don't want to touch this hardware). I want override because router runs dnsmasq with caching (on both its IPv4 and IPv6 adresses), and NS it advertise goes through tunnel each time without caching in the router. ache Is it possible with resolvconf(8)? resolvconf(8) doesn't have such rewrite feature. However, rtsol(8) has -R option to specify your own script to update /etc/resolv.conf. You may want to write your own script to rewrite nameserver address then pass it to resolvconf(8). So far I found the way to specify router link-local address using name_servers=fe80::... in the /etc/resolvconf.conf It prepends this name server above all others router advertise. But I still not find the way to _exclude_ what router advertise, perhaps looking into rtsol(8) possibilities you point will help here. -- http://ache.vniz.net/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
Hi,
On Tue, 21 Aug 2012 10:30:27 +0400
Andrey Chernov a...@freebsd.org said:
ache I am network admin, but what router advertise is out my easy control
ache (fixing configs in the Linux router's FS or even rebuilding router
ache components is needed, I don't want to touch this hardware).
You may want to try -u option of rtsol(8) to determine which router
advertises it. It saves link-local address of the advertising router
in interface name. You can see it by `resolvconf -l'.
ache I want override because router runs dnsmasq with caching (on both its
IPv4
ache and IPv6 adresses), and NS it advertise goes through tunnel each time
ache without caching in the router.
Okay, thanks.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Tue, Aug 21, 2012 at 03:58:12PM +0900, Hajimu UMEMOTO wrote: ache I am network admin, but what router advertise is out my easy control ache (fixing configs in the Linux router's FS or even rebuilding router ache components is needed, I don't want to touch this hardware). You may want to try -u option of rtsol(8) to determine which router advertises it. It saves link-local address of the advertising router in interface name. You can see it by `resolvconf -l'. I have only one router, so I know who does it :) But router runs Linix and what it advertise to client is not configurable via its web interface, so require Linux configs or/and demons patching I don't want to. ache I want override because router runs dnsmasq with caching (on both its IPv4 ache and IPv6 adresses), and NS it advertise goes through tunnel each time ache without caching in the router. -- http://ache.vniz.net/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Tue, Aug 21, 2012 at 03:58:12PM +0900, Hajimu UMEMOTO wrote: Okay, thanks. I solve this riddle, thanks to your helpful tips. Relevant part of my setup are at the end of this messae for anybody who may have the same problem. BTW, I notice that link-local router address behavior is strange and inconsistant for both 'host -6' and 'dig -6' commands. host -6 example.com fe80::rest of router address dig -6 @fe80::rest of router address example.com both hangs, but in the same time host -6 example.com fe80::rest of router address%iface dig -6 @fe80::rest of router address%iface example.com works! host -6 example.com fe80::rest of router address%1 dig -6 #fe80::rest of router address%1 example.com works too. Not understanding addresses without %iface or %1 looks like routing problems, but I don't know where to fix it. So, I try to use nameserver fe80::rest of router address%iface (or with %1 suffix) in my resolv.conf, as result host -6 example.com dig -6 example.com (without NS specified) both hangs despite they working when exact the same NS address is given in their command lines. So, I finally decide to use my router addres from IPv6 /64 subnet (given by my tunnel). It not goes through the whole tunnel, but directly to the router. host -6 example.com dig -6 example.com both works when it exists in /etc/reslov.conf. What I don't understand why all that bad things happens with link-local router address. To be sure I test it under Win7 and it works normally. Finally, what is working: /etc/resolvconf.conf: name_servers_append=IPv6 router address from /64 tunnel's subnet /etc/rc.conf: rtsol_flags=-R /etc/eat.sh /etc/eat.sh: #!/bin/sh /bin/cat /dev/null -- http://ache.vniz.net/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Saturday, August 18, 2012 3:57:24 pm Andrey Chernov wrote: On Fri, Aug 17, 2012 at 03:07:07PM -0400, John Baldwin wrote: On Friday, August 17, 2012 2:25:12 pm Andrey Chernov wrote: On Fri, Aug 17, 2012 at 03:53:43PM +, John Baldwin wrote: Author: jhb Date: Fri Aug 17 15:53:43 2012 New Revision: 239356 URL: http://svn.freebsd.org/changeset/base/239356 Log: Fix dhclient to properly exit and teardown the configured lease when link is lost. devd will start a new dhclient instance when link is restored. Is it any chance to teach dhclient IPv6 addresses in very basic parser level, f.e. to replace nameserver it sniffs from router? Currently dhcp-options(5) understands IPv4 addresses only and produce error on 'supersede' IPv6 address. I think the RFC defines those to be IPv4, yes? Presumably DHCPv6 adds new option types that support IPv6 addresses? RFC 2131 (if you mean it) describes DHCP process itself, it does not define contents of 'supersede' or other override options for dhclient. The supersede handling bits are all based on what the protocol can actually send, which the RFC defines as IPv4. Moreover, current dhclient somewhow able to fetch my IPv6 tunnel DNS address from the roiter (I don't look deeper, maybe it is router bug), but I don't want IPv6 tunnel DNS, I want router fe80:... DNS instead. Eh? DHCP can't return an IPv6 address in the protocol. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Mon, Aug 20, 2012 at 02:09:55PM -0400, John Baldwin wrote: RFC 2131 (if you mean it) describes DHCP process itself, it does not define contents of 'supersede' or other override options for dhclient. The supersede handling bits are all based on what the protocol can actually send, which the RFC defines as IPv4. 'supercede' itself not based on DHCPv4, it simple override anything protocol can actually send and in general case overriding contents can be any IP. But... I agree with you that it looks like quick hack. Having dual-stack machine it seems proper way for me to run both DHCP and DHCPv6 clients (net-mgmt/wide-dhcp? net/dhcp6?). But I fear they both will interact with single /etc/resolv.conf overriding each other there. Moreover, current dhclient somewhow able to fetch my IPv6 tunnel DNS address from the roiter (I don't look deeper, maybe it is router bug), but I don't want IPv6 tunnel DNS, I want router fe80:... DNS instead. Eh? DHCP can't return an IPv6 address in the protocol. As I already mention, perhaps it is router bug combined with the lack of validity checking in dhclient itself. As result I currently have /etc/resolv.conf: nameserver 192.168.1.1 nameserver ipv6 address of the tunnel NS -- http://ache.vniz.net/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
Hi,
On Tue, 21 Aug 2012 05:03:11 +0400
Andrey Chernov a...@freebsd.org said:
ache Having dual-stack machine it seems proper way for me to run both DHCP and
ache DHCPv6 clients (net-mgmt/wide-dhcp? net/dhcp6?). But I fear they both
will
ache interact with single /etc/resolv.conf overriding each other there.
FreeBSD 9 and above already have a feature to handle multiple source
of DNS address,; resolvconf(8). Our dhclient(8) and rtsol(8) uses it
to write /etc/resolv.conf.
ache As I already mention, perhaps it is router bug combined with the lack of
ache validity checking in dhclient itself. As result I currently have
ache /etc/resolv.conf:
ache nameserver 192.168.1.1
ache nameserver ipv6 address of the tunnel NS
Don't you see `# Generated by resolvconf' line in your generated
/etc/resolv.conf?
DHCP cannot carry an IPv6 address.
I suspect your router advertises an IPv6 address of your DNS server.
You can confirm where the DNS server addresss come from by executing
`resolvconf -l'.
The following is the output on my box for example:
ume@yuga:~% resolvconf -l
# resolv.conf from em0:dhcpv6
search mahoroba.org
nameserver 2001:2f0:104:8010::1
nameserver 2001:2f0:104:8010:221:5aff:feeb:183
# resolv.conf from em0:slaac:[fe80::218:71ff:feec:5271]
nameserver 2001:2f0:104:8010::1
search mahoroba.org
# resolv.conf from em0
search mahoroba.org
nameserver 192.168.100.59
nameserver 192.168.100.55
My network announces DHCPv6 and my box is configured to use DHCPv6.
So, there are three sources for a DNS address, here.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Tue, Aug 21, 2012 at 11:57:56AM +0900, Hajimu UMEMOTO wrote: FreeBSD 9 and above already have a feature to handle multiple source of DNS address,; resolvconf(8). Our dhclient(8) and rtsol(8) uses it to write /etc/resolv.conf. Thanks pointing to resolvconf(8) and rtsol(8), I'll try to look there to setup this stuff properly. Don't you see `# Generated by resolvconf' line in your generated /etc/resolv.conf? DHCP cannot carry an IPv6 address. I suspect your router advertises an IPv6 address of your DNS server. Yes. Whole resolv.conf: # Generated by resolvconf search domain nameserver 192.168.1.1 nameserver IPv6 DNS address for the router's IPv6 tunnel You can confirm where the DNS server addresss come from by executing `resolvconf -l'. resolvconf -l output: # resolv.conf from msk0 search domain nameserver 192.168.1.1 # resolv.conf from msk0:slaac nameserver IPv6 DNS address for the router's IPv6 tunnel (btw, what is slaac?) And I want to override IPv6 DNS address for the router's IPv6 tunnel with simple link-local IPv6 address of my router, i.e. fe80:... Is it possible with resolvconf(8)? -- http://ache.vniz.net/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Fri, Aug 17, 2012 at 03:07:07PM -0400, John Baldwin wrote: On Friday, August 17, 2012 2:25:12 pm Andrey Chernov wrote: On Fri, Aug 17, 2012 at 03:53:43PM +, John Baldwin wrote: Author: jhb Date: Fri Aug 17 15:53:43 2012 New Revision: 239356 URL: http://svn.freebsd.org/changeset/base/239356 Log: Fix dhclient to properly exit and teardown the configured lease when link is lost. devd will start a new dhclient instance when link is restored. Is it any chance to teach dhclient IPv6 addresses in very basic parser level, f.e. to replace nameserver it sniffs from router? Currently dhcp-options(5) understands IPv4 addresses only and produce error on 'supersede' IPv6 address. I think the RFC defines those to be IPv4, yes? Presumably DHCPv6 adds new option types that support IPv6 addresses? RFC 2131 (if you mean it) describes DHCP process itself, it does not define contents of 'supersede' or other override options for dhclient. Moreover, current dhclient somewhow able to fetch my IPv6 tunnel DNS address from the roiter (I don't look deeper, maybe it is router bug), but I don't want IPv6 tunnel DNS, I want router fe80:... DNS instead. -- http://ache.vniz.net/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Fri, 2012-08-17 at 15:53 +, John Baldwin wrote:
Author: jhb
Date: Fri Aug 17 15:53:43 2012
New Revision: 239356
URL: http://svn.freebsd.org/changeset/base/239356
Log:
Fix dhclient to properly exit and teardown the configured lease when
link is lost. devd will start a new dhclient instance when link is
restored.
PR: bin/166656
Submitted by: Peter Jeremy (mostly)
Reviewed by:brooks (earlier version from Peter)
MFC after: 1 month
Modified:
head/sbin/dhclient/dhclient.c
Modified: head/sbin/dhclient/dhclient.c
==
--- head/sbin/dhclient/dhclient.c Fri Aug 17 14:22:56 2012
(r239355)
+++ head/sbin/dhclient/dhclient.c Fri Aug 17 15:53:43 2012
(r239356)
@@ -278,6 +278,11 @@ routehandler(struct protocol *p)
ifi-name);
goto die;
}
+ if (!interface_link_status(ifi-name)) {
+ warning(Interface %s is down, dhclient exiting,
+ ifi-name);
+ goto die;
+ }
break;
case RTM_IFANNOUNCE:
ifan = (struct if_announcemsghdr *)rtm;
@@ -316,6 +321,8 @@ routehandler(struct protocol *p)
die:
script_init(FAIL, NULL);
+ if (ifi-client-active)
+ script_write_params(old_, ifi-client-active);
if (ifi-client-alias)
script_write_params(alias_, ifi-client-alias);
script_go();
I think the attached patch should give the same result without needing
to create/destroy a socket to check the link status every time a routing
info message arrives. I've actually had this patch in my head for
several years, I just hadn't gotten around to submitting it yet.
-- Ian
diff -r 6cb112d8486e sbin/dhclient/dhclient.c
--- a/sbin/dhclient/dhclient.c Mon Aug 13 15:06:09 2012 -0600
+++ b/sbin/dhclient/dhclient.c Fri Aug 17 10:48:02 2012 -0600
@@ -273,7 +273,7 @@ routehandler(struct protocol *p)
ifm = (struct if_msghdr *)rtm;
if (ifm-ifm_index != ifi-index)
break;
- if ((rtm-rtm_flags RTF_UP) == 0) {
+ if (ifm-ifm_data.ifi_link_state != LINK_STATE_UP) {
warning(Interface %s is down, dhclient exiting,
ifi-name);
goto die;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Friday, August 17, 2012 1:02:14 pm Ian Lepore wrote:
On Fri, 2012-08-17 at 15:53 +, John Baldwin wrote:
Author: jhb
Date: Fri Aug 17 15:53:43 2012
New Revision: 239356
URL: http://svn.freebsd.org/changeset/base/239356
Log:
Fix dhclient to properly exit and teardown the configured lease when
link is lost. devd will start a new dhclient instance when link is
restored.
PR: bin/166656
Submitted by: Peter Jeremy (mostly)
Reviewed by: brooks (earlier version from Peter)
MFC after:1 month
Modified:
head/sbin/dhclient/dhclient.c
Modified: head/sbin/dhclient/dhclient.c
==
--- head/sbin/dhclient/dhclient.c Fri Aug 17 14:22:56 2012
(r239355)
+++ head/sbin/dhclient/dhclient.c Fri Aug 17 15:53:43 2012
(r239356)
@@ -278,6 +278,11 @@ routehandler(struct protocol *p)
ifi-name);
goto die;
}
+ if (!interface_link_status(ifi-name)) {
+ warning(Interface %s is down, dhclient exiting,
+ ifi-name);
+ goto die;
+ }
break;
case RTM_IFANNOUNCE:
ifan = (struct if_announcemsghdr *)rtm;
@@ -316,6 +321,8 @@ routehandler(struct protocol *p)
die:
script_init(FAIL, NULL);
+ if (ifi-client-active)
+ script_write_params(old_, ifi-client-active);
if (ifi-client-alias)
script_write_params(alias_, ifi-client-alias);
script_go();
I think the attached patch should give the same result without needing
to create/destroy a socket to check the link status every time a routing
info message arrives. I've actually had this patch in my head for
several years, I just hadn't gotten around to submitting it yet.
Hmm, OpenBSD does check that, but they also seem to verify it via SIOCGMEDIA
as well. Do we think this is as reliable? In the kernel we only seem to
honor this if the NIC explicitly supports the capability:
#define RT_LINK_IS_UP(ifp) (!((ifp)-if_capabilities IFCAP_LINKSTATE) \
|| (ifp)-if_link_state == LINK_STATE_UP)
Also, I don't think routing info messages are all that common of an event are
they?
--
John Baldwin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Fri, 2012-08-17 at 13:31 -0400, John Baldwin wrote:
On Friday, August 17, 2012 1:02:14 pm Ian Lepore wrote:
On Fri, 2012-08-17 at 15:53 +, John Baldwin wrote:
Author: jhb
Date: Fri Aug 17 15:53:43 2012
New Revision: 239356
URL: http://svn.freebsd.org/changeset/base/239356
Log:
Fix dhclient to properly exit and teardown the configured lease when
link is lost. devd will start a new dhclient instance when link is
restored.
PR: bin/166656
Submitted by: Peter Jeremy (mostly)
Reviewed by:brooks (earlier version from Peter)
MFC after: 1 month
Modified:
head/sbin/dhclient/dhclient.c
Modified: head/sbin/dhclient/dhclient.c
==
--- head/sbin/dhclient/dhclient.c Fri Aug 17 14:22:56 2012
(r239355)
+++ head/sbin/dhclient/dhclient.c Fri Aug 17 15:53:43 2012
(r239356)
@@ -278,6 +278,11 @@ routehandler(struct protocol *p)
ifi-name);
goto die;
}
+ if (!interface_link_status(ifi-name)) {
+ warning(Interface %s is down, dhclient exiting,
+ ifi-name);
+ goto die;
+ }
break;
case RTM_IFANNOUNCE:
ifan = (struct if_announcemsghdr *)rtm;
@@ -316,6 +321,8 @@ routehandler(struct protocol *p)
die:
script_init(FAIL, NULL);
+ if (ifi-client-active)
+ script_write_params(old_, ifi-client-active);
if (ifi-client-alias)
script_write_params(alias_, ifi-client-alias);
script_go();
I think the attached patch should give the same result without needing
to create/destroy a socket to check the link status every time a routing
info message arrives. I've actually had this patch in my head for
several years, I just hadn't gotten around to submitting it yet.
Hmm, OpenBSD does check that, but they also seem to verify it via SIOCGMEDIA
as well. Do we think this is as reliable? In the kernel we only seem to
honor this if the NIC explicitly supports the capability:
#define RT_LINK_IS_UP(ifp)(!((ifp)-if_capabilities IFCAP_LINKSTATE) \
|| (ifp)-if_link_state == LINK_STATE_UP)
Also, I don't think routing info messages are all that common of an event are
they?
I actually don't know how common routing info messages are; the ways I
use freebsd don't include a lot of heavy network usage.
The IFCAP_LINKSTATE question is interesting. The #define comment for it
says the runtime link state is dynamic. The RT_LINK_IS_UP() macro is
interesting too, in that it appears to assume that the link must be up
if it isn't dynamic. I think that means the more-correct way than I
posted would be a test such as
if (!RT_LINK_IS_UP(ifm-ifm_data))
It looks like IFCAP_LINKSTATE is added to if_capabilities by
miibus_attach() and a few specific NIC drivers (presumably ones that
don't use standard MII attachements to their PHYs).
I would hope all that adds up to the concept that any network driver in
control of links that can come and go will either automatically do the
right thing by using the miibus code, or by using its own equivelent
code when mii isn't appropriate, or the driver is buggy. Hopefully
there aren't any in the last category. :)
-- Ian
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Fri, Aug 17, 2012 at 03:53:43PM +, John Baldwin wrote: Author: jhb Date: Fri Aug 17 15:53:43 2012 New Revision: 239356 URL: http://svn.freebsd.org/changeset/base/239356 Log: Fix dhclient to properly exit and teardown the configured lease when link is lost. devd will start a new dhclient instance when link is restored. Is it any chance to teach dhclient IPv6 addresses in very basic parser level, f.e. to replace nameserver it sniffs from router? Currently dhcp-options(5) understands IPv4 addresses only and produce error on 'supersede' IPv6 address. -- http://ache.vniz.net/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r239356 - head/sbin/dhclient
On Friday, August 17, 2012 2:09:54 pm Ian Lepore wrote:
On Fri, 2012-08-17 at 13:31 -0400, John Baldwin wrote:
On Friday, August 17, 2012 1:02:14 pm Ian Lepore wrote:
On Fri, 2012-08-17 at 15:53 +, John Baldwin wrote:
Author: jhb
Date: Fri Aug 17 15:53:43 2012
New Revision: 239356
URL: http://svn.freebsd.org/changeset/base/239356
Log:
Fix dhclient to properly exit and teardown the configured lease when
link is lost. devd will start a new dhclient instance when link is
restored.
PR: bin/166656
Submitted by: Peter Jeremy (mostly)
Reviewed by: brooks (earlier version from Peter)
MFC after:1 month
Modified:
head/sbin/dhclient/dhclient.c
Modified: head/sbin/dhclient/dhclient.c
==
--- head/sbin/dhclient/dhclient.c Fri Aug 17 14:22:56 2012
(r239355)
+++ head/sbin/dhclient/dhclient.c Fri Aug 17 15:53:43 2012
(r239356)
@@ -278,6 +278,11 @@ routehandler(struct protocol *p)
ifi-name);
goto die;
}
+ if (!interface_link_status(ifi-name)) {
+ warning(Interface %s is down, dhclient
exiting,
+ ifi-name);
+ goto die;
+ }
break;
case RTM_IFANNOUNCE:
ifan = (struct if_announcemsghdr *)rtm;
@@ -316,6 +321,8 @@ routehandler(struct protocol *p)
die:
script_init(FAIL, NULL);
+ if (ifi-client-active)
+ script_write_params(old_, ifi-client-active);
if (ifi-client-alias)
script_write_params(alias_, ifi-client-alias);
script_go();
I think the attached patch should give the same result without needing
to create/destroy a socket to check the link status every time a routing
info message arrives. I've actually had this patch in my head for
several years, I just hadn't gotten around to submitting it yet.
Hmm, OpenBSD does check that, but they also seem to verify it via SIOCGMEDIA
as well. Do we think this is as reliable? In the kernel we only seem to
honor this if the NIC explicitly supports the capability:
#define RT_LINK_IS_UP(ifp) (!((ifp)-if_capabilities IFCAP_LINKSTATE) \
|| (ifp)-if_link_state == LINK_STATE_UP)
Also, I don't think routing info messages are all that common of an event
are they?
I actually don't know how common routing info messages are; the ways I
use freebsd don't include a lot of heavy network usage.
They appear to be rare:
Finding symbol: rt_ifmsg
Database directory: /home/jhb/work/freebsd/svn/head/sys/
---
*** net/route.h:
global[363] void rt_ifmsg(struct ifnet *);
*** dev/usb/usb_pf.c:
usbpf_clone_create[202]rt_ifmsg(ifp);
*** net/if.c:
if_unroute[1841] rt_ifmsg(ifp);
if_route[1863] rt_ifmsg(ifp);
do_link_state_change[1903] rt_ifmsg(ifp);
ifhwioctl[2293]rt_ifmsg(ifp);
if_setflag[2678] rt_ifmsg(ifp);
*** net/rtsock.c:
rt_ifmsg[1256] rt_ifmsg(struct ifnet *ifp)
So, adding or removing routes, link state changes, changing the MTU, and
changing an interface flag (e.g. ifconfig down). These all seem to be
fairly rare to me, and generally require running ifconfig or route, etc.
The IFCAP_LINKSTATE question is interesting. The #define comment for it
says the runtime link state is dynamic. The RT_LINK_IS_UP() macro is
interesting too, in that it appears to assume that the link must be up
if it isn't dynamic. I think that means the more-correct way than I
posted would be a test such as
if (!RT_LINK_IS_UP(ifm-ifm_data))
It looks like IFCAP_LINKSTATE is added to if_capabilities by
miibus_attach() and a few specific NIC drivers (presumably ones that
don't use standard MII attachements to their PHYs).
I would hope all that adds up to the concept that any network driver in
control of links that can come and go will either automatically do the
right thing by using the miibus code, or by using its own equivelent
code when mii isn't appropriate, or the driver is buggy. Hopefully
there aren't any in the last category. :)
I think pseudo-interfaces complicate things somewhat, but many of those
(vlan(4), bridge(4), etc.) appear to do something sane I think. It's not
clear to me that we currently assume that ifi_link_state is definitively
valid.
--
John Baldwin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to
Re: svn commit: r239356 - head/sbin/dhclient
On Friday, August 17, 2012 2:25:12 pm Andrey Chernov wrote: On Fri, Aug 17, 2012 at 03:53:43PM +, John Baldwin wrote: Author: jhb Date: Fri Aug 17 15:53:43 2012 New Revision: 239356 URL: http://svn.freebsd.org/changeset/base/239356 Log: Fix dhclient to properly exit and teardown the configured lease when link is lost. devd will start a new dhclient instance when link is restored. Is it any chance to teach dhclient IPv6 addresses in very basic parser level, f.e. to replace nameserver it sniffs from router? Currently dhcp-options(5) understands IPv4 addresses only and produce error on 'supersede' IPv6 address. I think the RFC defines those to be IPv4, yes? Presumably DHCPv6 adds new option types that support IPv6 addresses? -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
