Re: svn commit: r239356 - head/sbin/dhclient
Hi,
> On Thu, 23 Aug 2012 08:41:37 +0400
> Andrey Chernov 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
ache>original format for non-global addresses; that is, the format without
ache>the zone index portion. As described in Section 6, in some common
ache>cases with the notion of the default zone index, there can be no
ache>ambiguity about scope zones. In such an environment, the
ache>implementation can omit the "%" 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> % 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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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 "%" 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 % 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r239356 - head/sbin/dhclient
Hi,
> On Wed, 22 Aug 2012 04:06:46 +0400
> Andrey Chernov 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::
ache> dig -6 @fe80:: example.com
ache> both hangs, but in the same time
ache> host -6 example.com fe80::%
ache> dig -6 @fe80::% example.com
ache> works!
ache> host -6 example.com fe80::%1
ache> dig -6 #fe80::%1 example.com
ache> works too. Not understanding addresses without % 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::% (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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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:: dig -6 @fe80:: example.com both hangs, but in the same time host -6 example.com fe80::% dig -6 @fe80::% example.com works! host -6 example.com fe80::%1 dig -6 #fe80::%1 example.com works too. Not understanding addresses without % or %1 looks like routing problems, but I don't know where to fix it. So, I try to use nameserver fe80::% (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= /etc/rc.conf: rtsol_flags="-R /etc/eat.sh" /etc/eat.sh: #!/bin/sh /bin/cat > /dev/null -- http://ache.vniz.net/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r239356 - head/sbin/dhclient
Hi,
> On Tue, 21 Aug 2012 10:30:27 +0400
> Andrey Chernov 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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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 > 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r239356 - head/sbin/dhclient
Hi,
> On Tue, 21 Aug 2012 08:45:53 +0400
> Andrey Chernov said:
ache> resolvconf -l output:
ache> # resolv.conf from msk0
ache> search
ache> nameserver 192.168.1.1
ache> # resolv.conf from msk0:slaac
ache> nameserver
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
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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 nameserver 192.168.1.1 nameserver > You can confirm where the DNS server addresss come from by executing > `resolvconf -l'. resolvconf -l output: # resolv.conf from msk0 search nameserver 192.168.1.1 # resolv.conf from msk0:slaac nameserver (btw, what is slaac?) And I want to override with simple link-local IPv6 address of my router, i.e. fe80:... Is it possible with resolvconf(8)? -- http://ache.vniz.net/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r239356 - head/sbin/dhclient
Hi,
> On Tue, 21 Aug 2012 05:03:11 +0400
> Andrey Chernov 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
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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 -- http://ache.vniz.net/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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:
[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
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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r239356 - head/sbin/dhclient
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();
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
