Re: Import dhcpcd(8) into FreeBSD base

[Hiroki Sato]

Roy Marples  wrote
  in <4516f415-939e-6374-45ce-df19a2ac6...@marples.name>:

ro> On 07/08/2022 15:23, Hiroki Sato wrote:
ro> >   1) Import dhcpcd and make it invoked via Other Configuration flag
ro> >  in RA for DHCPv6.  This means that the rtsold daemon remains a
ro> >  consumer of RA messages, and the default value of the -O option is
ro> >  set to run dhcpcd.
ro>
ro> I don't think this is a viable option as there is no easy way to
ro> transition from Other to Managed (or the other way around) from the
ro> dhcpcd commandline or signals.

 The rtsold daemon just invokes a corresponding helper script when
 receiving RAs with these flags.  A transition from O to M or vice
 versa is supposed to be handled by them.  I think it is possible to
 stop the running dhcpcd and/or restart it with another configuration
 via the scripts.  Is there a critical problem with it?  I do not
 insist that it is the best way since it is not a graceful transition,
 but I still believe it should work for most DHCPv6-enabled networks.

ro> Also, please consider than dhcpcd supports DNSSL and RDNSS options
ro> from RA messages whereas FreeBSD rtsold/kernel RA do not (please
ro> correct me if I'm wrong).

 The FreeBSD rtsold has supported them for >10 years.  Resolvconf, one
 of your projects, was imported at the same time to solve the problem
 of multiple information source for /etc/resolv.conf.

ro> Sure it works fine for the one interface wired system - which
ro> admitedly is the most popular setup. But when more than one interface
ro> comes into play or you have plugable interfaces it then becomes more
ro> complicated and will consume more resources having many more daemon
ro> runing to allow capsicum and makes dhcpcd just as predictable as
ro> dhclient on a multi-homed system (ie it's not predictable).
ro>
ro> I modified wpa_supplicant upstream to support the -M directive (I
ro> don't know if FreeBSD compiles wpa_supplicant with CONFIG_MATCH_IFACE
ro> defined) to allow plugable interfaces just for this reason.

 I agree that running processes for each interface independently is
 sub-optimal.  However, I think it is a separate topic from whether
 importing a DHCPv6 client into the base system or not.  More
 specifically, the following three are orthogonal:

 1. Use dhcpcd or not as a replacement of dhclient and rtsold.

   This leads to a never-ending discussion.  Some people like the
   existing ones because they have worked well and do not want to
   change.

 2. Adopt a single process managing the multiple interfaces on the
system or use per-interface processes.

   Changing this requires a lot of work and breaks the existing
   configurations.  A side node of the design and behavior of the
   current rc.d/netif is as follows:

   - The current rc.d/netif (and other network-related rc.d scripts
 such as rc.d/wpa_supplicant) are based on the per-interface
 model.  The rc.d/netif script is invoked asynchronously while it
 also runs at boot time sequentially.  This asynchronous
 invocation is specific to FreeBSD, and not seen in other BSDs
 (correct me if I am wrong).

   - The devd(8) daemon is the main process receiving events of the
 interfaces such as arrival/departure/link-state changes, and
 invokes a process upon an event if necessary.

   - The rtsold(8) daemon is the main process receiving RAs in
 userland and invokes a process upon an event if necessary.
 Currently, it handles O/M flags and RDNSS/DNSSL options.

 3. Add an implementation of the DHCPv6 client-side functionality or
not.

   I believe no one objects for adding one because we have no
   implementation in the base system.  Some people like another one,
   such as ISC dhclient or WIDE dhcp6.

 My opinion is: 1) "no need", 2) "keep the current model for a while",
 and 3) "go for it".  I tend to prefer WIDE dhcp6 because I have used
 it for >15 years with accumulated local patchset, but I do not stick
 to it as long as there is a good working implementation supporting
 IA_NA and IA_PD, and someone actively maintains it.  WIDE dhcp6 works
 well, but it has a lot of rough edges (and fixed locally by many
 people, as bz@ pointed out).

 As mentioned in my previous email, avoiding POLA violations is the top
 priority.  Regardless of which implementation we import, I still
 believe keeping the current per-interface model is the least
 intrusive for the existing configurations.

 So we need a consensus about how to get started with the integration.
 An idea in my mind is: 1) import dhcpcd (or whatever supports
 per-interface mode), 2) add a per-interface helper script for it, and
 3) set rtsold_enable="YES" effectively by default for all
 RA-accepting interfaces so that people do not need to manually
 configure it at least on an IPv6 network with M/O bit enabled.  This
 should 

Re: Import dhcpcd(8) into FreeBSD base

[Hiroki Sato]

"Bjoern A. Zeeb"  wrote
  in :

bz> >>   In 1)+2), there is no POLA for users of other DHCPv6 clients such as
bz> >>   dhcp6c or ISC's dhclient -6.  A full-blown dhcpcd configuration,
bz> >>   which replaces dhclient/rtsold, is still possible.  The cons are that
bz> >>   this is a partial integration of dhcpcd, which prevents some useful
bz> >>   feature available in the master mode, and some complexity remains in
bz> >>   the rc.d scripts.  I think these are a trade-off.  I am interested in
bz> >>   whether this integration has a big problem when people use the
bz> >>   imported dhcpcd.
bz> >>
bz> >>   And probably we have to revisit this integration when we want to
bz> >>   support DHCP 4o6 or something that involves IPv4 and IPv6 at the same
bz> >>   time.  The flexibility of the "toolbox" approach would be helpful in
bz> >>   minimizing the impact on the existing configurations when more future
bz> >>   integration change occurs.
bz> >
bz> > Agreed. I noted my concerns above and would favour a full blown dhcpcd 
configuration for new installs and leave the current dhclient/rtsold for 
exising installs. No need to force people to move.
bz>
bz> I think that is a very sensible approach to do it incrementally.
bz>
bz> If people can agree on
bz> (1) importing it and first closing the gap of the missing DHCPv6 client 
making
bz> sure it does all people have accumultaed over the years,
bz> (2) and then solving the "how do I disable dhclient and rtsold and per-IF 
configs
bz> and just run the-one-thing as an alternative in rc" in the 2nd step

 I agree with (1) before 14 and discussing (2) after that, separately.

-- Hiroki


pgpAIw3yZbWyo.pgp
Description: PGP signature

Re: Import dhcpcd(8) into FreeBSD base

[Hiroki Sato]

"Ben Woods"  wrote
  in :

wo> If accepted, I would recommend a phased implementation such as that
wo> suggested below - open to ideas.
wo> 
wo> - 14.0 (and perhaps 13.2) - dhcpcd included but off by default
wo> - (WITH_DHCPCD=on, but rc.conf/network.subr continue to use
wo> - dhclient/rtsold). Release notes list forward plan.

 While I have no objection (or rather agree with) importing a client,
 replacing the existing dhclient and rtsold would be a destructive
 change from the user's perspective.  I would suggest the following:

 1) Import dhcpcd and make it invoked via Other Configuration flag
in RA for DHCPv6.  This means that the rtsold daemon remains a
consumer of RA messages, and the default value of the -O option is
set to run dhcpcd.

 2) Keep the dhclient utility intact and add a knob to choose dhclient
or dhcpcd (or something else) for DHCPv4.  The current rc.d
scripts for DHCPv4 can be adjusted to use another client
supporting a per-interface mode.

 The dhcpcd daemon can handle various protocols of IPv4/IPv6 and watch
 multiple interfaces, so the suggestions above might sound like an
 underestimation of the capability.  I am concerned that changes to
 replacing dhclient/rtsold will break the existing configurations.
 Especially for IPv4, dhclient is mature, and many people have used
 custom dhclient.conf and dhclient-script for years.  I believe we
 will get little gain from such change.

 In 1)+2), there is no POLA for users of other DHCPv6 clients such as
 dhcp6c or ISC's dhclient -6.  A full-blown dhcpcd configuration,
 which replaces dhclient/rtsold, is still possible.  The cons are that
 this is a partial integration of dhcpcd, which prevents some useful
 feature available in the master mode, and some complexity remains in
 the rc.d scripts.  I think these are a trade-off.  I am interested in
 whether this integration has a big problem when people use the
 imported dhcpcd.

 And probably we have to revisit this integration when we want to
 support DHCP 4o6 or something that involves IPv4 and IPv6 at the same
 time.  The flexibility of the "toolbox" approach would be helpful in
 minimizing the impact on the existing configurations when more future
 integration change occurs.

wo> I should point out that I have a ports commit bit - not src. If
wo> accepted, I’d either need a src committer to land it, or approve me
wo> committing (via phabricator).
wo> 
wo> https://reviews.freebsd.org/D22012
wo> https://github.com/NetworkConfiguration/dhcpcd

 I am happy to help in this regard.

-- Hiroki


pgpq_e3lI_OTs.pgp
Description: PGP signature

Re: Ipv6 neighbor limit

[Hiroki Sato]

"Bjoern A. Zeeb"  wrote
  in <3a46b5fe-93e3-40c8-99ea-76f3e03d5...@lists.zabbadoz.net>:

bz> On 3 Sep 2020, at 12:48, Hans Petter Selasky wrote:
bz>
bz> > On 2020-09-03 14:34, Cristian Cardoso wrote:
bz> >> Hi
bz> >> Would anyone know if there is any limit in the FreeBSD kernel for IPv6
bz> >> neighbors? I checked the ndp documentation and found nothing, looking
bz> >> at the return of the sysctl command I also did not find anything
bz> >> explicit.
bz> >>
bz> >
bz> > Hi,
bz> >
bz> > There is something called:
bz> >
bz> > sys/netinet/in.h:#define  IP_MAX_MEMBERSHIPS  4095
bz> > sys/netinet6/in6.h:#defineIPV6_MAX_MEMBERSHIPS4095
bz> >
bz> > Is this what you are looking for?
bz>
bz>
bz> Or more along the lines of  https://reviews.freebsd.org/D24035 ?

 This reminds me D22712 (sorry for not responding...).  I agree that
 we should set limits by default to the number of entries in lists for
 neighbors and prefixes.

-- Hiroki


pgprtcrbqGoIw.pgp
Description: PGP signature

Re: ndp and routers with link-local addresses

[Hiroki Sato]

Niclas Zeising  wrote
  in :

ze> On 2020-07-07 12:57, Hiroki Sato wrote:
ze> > Niclas Zeising  wrote
ze> >in :
ze> > ze> However, if the interface on the router facing the client network
ze> > only
ze> > ze> has a link-local (and no global unicast) address, NDP neighbor
ze> > ze> discovery breaks.
ze> >   This is related to the prefix discovery, not neighbor discovery
ze> >   (L2-L3 address resolution) in NDP.  In the current implementation,
ze> >   just adding an interface route does not mean that the prefix is
ze> >   on-link.  Adding the prefix (i.e. an address) on the interface or
ze> >   receiving an Router Advertisement message with a Prefix Information
ze> >   Option on the interface are the only ways to update the prefix list.
ze>
ze> What is needed to mark a prefix as being on-link?

 On FreeBSD, they are basically either 1) an address configured on an
 interface or 2) receiving RA from a router on the same link with
 prefix information.

ze> What does the relevant RFCs say? (I haven't looked myself, to be
ze> honest).

 RFC 5942 is the most relevant RFC.  Note that the current FreeBSD
 implementation is based on older discussions even before RFC 4861, so
 the on-link assumption is a bit relaxed compared to RFC 5942.

ze> On networks where SLAAC is in use, there is no need for a global
ze> address on the router interface facing the clients, since all
ze> communication with the router is done on the link-local address, and
ze> clients has the router link-local address as their next hop.
ze>
ze> In my case, nothing is preventing me from adding an address in the
ze> correct network on the interface, and getting this to work.  I was
ze> just surprised it didn't work without a global unicast address, since
ze> it works on Linux, and both information I've read about the topic, as
ze> well as people I've talked to, say that it should be possible to only
ze> have a link-local address on the router.

 An IPv6 router works without GUA even on FreeBSD.  However, the final
 hop of the packet forwarding depends on the on-link information on the
 router.  Linux recognizes a routing table entry as source of on-link
 information.  FreeBSD does not.  This is the primary difference.

 RFC 5942 says making a prefix on-link may be done by "explicit manual
 configuration".  FreeBSD defines an address configuration as its
 manual prefix configuration.  Adding a routing table entry might be
 considered as an additional manual configuration, but if doing so,
 communications whose source is fe80::/16 and destination is a GUA
 will happen when it is originated from the router itself.  Strictly
 speaking it is not against the specification, a unicast communication
 between two addresses which have a different scope from each other is
 not desirable, and at least an unexpected behavior in the current
 implementation.  We need to carefully check if it works in our
 network stack before enabling it.

ze> This has more to do with interoperability, and conformance with other
ze> IPv6 implementations (the one in Linux).  I haven't tested other
ze> Routers, such as Cisco or Juniper, though.

 Manual configuration of the prefix list is up to the platform.  It is
 not something determined by communication with another nodes, so I do
 not think this is an interoperability issue of the protocol.

ze> >   Theoretically, a router can always have Subnet-Router anycast address
ze> >   on each interface and it works as an on-link prefix information.  For
ze> >   this reason, KAME implementation does not support properly to use
ze> >   interface route for directly-connected prefixes.
ze>
ze> I'm not sure that I understand this part.  I know what a subnet router
ze> anycast address is, and how to assign it, and I know what anycast
ze> is. But I'm not sure I understand the comment about the KAME
ze> implementation not properly supporting interface routes for directly
ze> connected prefixes.

 On all interfaces of an IPv6 router, Subnet-Router anycast address of
 prefixes on the connected links must be configured, according to RFC
 4291.  An interface with only LLAs does not happen.  This means that
 the prefix list is configured properly by these addresses.

 Most of people do not configure this anycast address in practice,
 however.  So I used the word "theoretically".  Configuring an GUA
 within the prefix also works and more intuitive.

 As explained earlier, it is an odd situation that there is an
 interface route with a prefix and the prefix list does not have the
 prefix as on-link.  The odd behaviors came from it because IPv6
 network stack got confused.

-- Hiroki


pgpjBLF_AhSYX.pgp
Description: PGP signature

Re: Specifying link-local address in rc.conf

[Hiroki Sato]

Niclas Zeising  wrote
  in :

ze> On 2020-07-07 12:02, Hiroki Sato wrote:
ze> > Niclas Zeising  wrote
ze> >in <713e1f3e-4dd9-8dcf-c6d2-15c684bdc...@daemonic.se>:
ze> > ze> Hi!
ze> > ze> Is it possible to specify a link-local address in rc.conf, and get
ze> > ze> only that link-local address?
ze> >   The following is a typical configuration if you want to disable
ze> >   EUI-64 LLA:
ze> >ifconfig_vtnet0="inet "
ze> >ifconfig_vtnet0_ipv6="inet6 -auto_linklocal"
ze> >ifconfig_vtnet0_alias0="inet6 fe80::1/64"
ze> >ifconfig_vtnet0_alias1="inet6 2001:6b8::1/64"
ze> >   Address family keyword is mandatory.  Most of address configurations
ze> >   with no AF keyword are handled as expected, but some are not.
ze>
ze> Hi!
ze> This example does not work, it generates a EUI64 link-local address on
ze> vtnet0, and then adds the other IPv6 addresses.
ze> It looks like anything that has ifconfig_vtnet0="inet ..." or even
ze> just "up" generates the link_local address.

 Hmm, that's odd.  Can you send me a log by the following command-line
 off-list?  I will investigate the cause.

 # env -i rc_debug=YES /bin/sh -x /etc/rc.d/netif restart vtnet0

-- Hiroki


pgplOjbG0gvjn.pgp
Description: PGP signature

Re: ndp and routers with link-local addresses

[Hiroki Sato]

Niclas Zeising  wrote
  in :

ze> However, if the interface on the router facing the client network only
ze> has a link-local (and no global unicast) address, NDP neighbor
ze> discovery breaks.

 This is related to the prefix discovery, not neighbor discovery
 (L2-L3 address resolution) in NDP.  In the current implementation,
 just adding an interface route does not mean that the prefix is
 on-link.  Adding the prefix (i.e. an address) on the interface or
 receiving an Router Advertisement message with a Prefix Information
 Option on the interface are the only ways to update the prefix list.

 Neighbor discovery does not work for communications to an address
 within the prefix not on the prefix list because the prefix is not
 considered as directly-connected.

 This restriction can be relaxed technically by adding the prefix to
 the list when a route for it is installed (also discussed in
 https://reviews.freebsd.org/D23695, and there are experimental
 patches to implement it).  However, adding an address within the
 prefix is the safest option.  Is there any specific reason why using
 the interface route for a directly-connected prefix, instead of
 adding an address on the interface?  I am interested in this use
 case.

 Theoretically, a router can always have Subnet-Router anycast address
 on each interface and it works as an on-link prefix information.  For
 this reason, KAME implementation does not support properly to use
 interface route for directly-connected prefixes.

-- Hiroki


pgpOURevYYsni.pgp
Description: PGP signature

Re: Specifying link-local address in rc.conf

[Hiroki Sato]

Niclas Zeising  wrote
  in <713e1f3e-4dd9-8dcf-c6d2-15c684bdc...@daemonic.se>:

ze> Hi!
ze> Is it possible to specify a link-local address in rc.conf, and get
ze> only that link-local address?

 The following is a typical configuration if you want to disable
 EUI-64 LLA:

  ifconfig_vtnet0="inet "
  ifconfig_vtnet0_ipv6="inet6 -auto_linklocal"
  ifconfig_vtnet0_alias0="inet6 fe80::1/64"
  ifconfig_vtnet0_alias1="inet6 2001:6b8::1/64"

 Address family keyword is mandatory.  Most of address configurations
 with no AF keyword are handled as expected, but some are not.

-- Hiroki


pgp18M0M4m1gy.pgp
Description: PGP signature

Re: routed && route6d removal proposal

[Hiroki Sato]

"Alexander V. Chernikov"  wrote
  in <273191592779...@mail.yandex.ru>:

me> Hey,
me>
me> I would like to propose removal of  sbin/routed and usr.sbin/route6d.

 I am still using both of them in production environments because they
 work well at least for my configurations and most of promising
 alternatives are under GPL, not BSDL.

 Why do we need to rush to remove them?  Discussion about whether we
 should keep or remove such old bits tends to be controversial when
 there is a user like me.  I would agree with the removal if they were
 harmful or impossible to maintain, but would not for the reason that
 they are simply old and probably no one uses it today.  Reason 1 and
 2 look like the latter at least to me.  "too old to be worth keeping"
 is a matter of degree.  Uucp, rlogind, and timed should be removed
 (and were removed) because there are few non-FreeBSD platforms which
 support these protocols.  RIP is still widely supported---just like
 FTP, which nowadays no one prefers to use and major www browsers are
 about to drop the support of---and not be considered an inherently
 vulnerable protocol like telnet.  And keeping these daemons is not
 harmful even for users who want to use third-party routing daemons
 you listed.

me> 1.1. Nowadays the daemon name is simply misleading. Given situation
me> described above, one does expect far wider functionality from the
me> program named "route[6]d" than just RIP implementation.

 I do not think this is a good reason to remove something nor people
 have got confused actually.  If this is true, quagga or bird are much
 worse.

me> 2. Multiple routing stacks supporting all major routing protocol
me> including RIP exists these days: bird, frr, quagga. Many BGP-only
me> designs in are gaining popularity, so do bgp speakers such as exabgp
me> or gobgp.  Nowadays, if one needs dynamic routing on the host, OSPF or
me> BGP speaker is the choice. FreeBSD packages contains well-maintained
me> ports for these. Having RIP[ng] speakers in base offers no advantage.
me>
me> 3. Both routed/route6d are largely unmaintained [4] and presents an
me> additional attack vector. Here is the list of last non-trivial commits
me> to routed/route6d:

 I think this is a separate issue.  What attack vectors which are
 known to be vulnerable do they have?

 The small commit counts are not equal to its unreliability.  Older
 daemons such as ppp(8), dhclient(8), ftpd(8), or bootpd(8) have
 received few substantial changes in recent years because they are
 mature.

 I am not a strong protester and will be happy to keep them as ports
 if everyone wants to remove them and it will happen, but I would like
 consistent criteria on removing software in the base system (they do
 not need to be perfect nor strict, though).  I believe harmfulness is
 more important than the fact that it is old or we have more choices
 in the ports tree.  If we have negative factors on maintaining them,
 removing them would be one of the choices as a result.  If the
 existing routed/route6d makes difficulty on people who want to use
 third-party routing daemons, it should be fixed.  These kind of
 harmfulness look below the threshold to me at this moment though I
 may be biased because I am still using them today...

-- Hiroki


pgp2_lTTCthSB.pgp
Description: PGP signature

Re: net.inet6.ip6.deembed_scopeid removal

[Hiroki Sato]

"Alexander V. Chernikov"  wrote
  in <645741592773...@mail.yandex.ru>:

me> [re-sending email with as non-html]
me>
me> Hey,
me>
me> I would like to deprecate net.inet6.ip6.deembed_scopeid sysctl while
me> leaving the current default behaviour.
me>
me> This sysctl controls whether IPv6 scope is embedded in the IPv6
me> address or not when reading or writing route/interface/ifaddr data via
me> rtsock/sysctl.
me>
me> Embedding scope in the address is a hack, that overwrites some of the
me> bits that can be used otherwise. It was probably implemented that way
me> to simplify route table interactions, as rtable uses this hack to add
me> link-local addresses to the same radix tree.
me>
me> The change to fix the userland api by filling in sin6_scopeid and
me> avoid touching IPv6 address was added in r243187, 7 years ago. It
me> provided the sysctl in question, allowing to preserve compatibility
me> with older applications, by reverting to the old behavior.
me>
me> 7 years looks like enough timeframe for the applications to be
me> adjusted. Unless any major objections arise, I'm going to remove the
me> code and make de-embedded IPv6 addresses the only option on July 5
me> 2020.

 I agree that it is time to remove it and I do not think we need to
 wait more.  This knob was for debugging purpose rather than for
 keeping compatibility.  A concern was that recovering the scopeid
 might have performance penalty.

-- Hiroki


pgpPuJ3XcAFs_.pgp
Description: PGP signature

Re: Question about rtadvd

[Hiroki Sato]

John-Mark Gurney  wrote
  in <20200402211304.gz4...@funkthat.com>:

jm> Fernando Gont wrote this message on Tue, Mar 31, 2020 at 22:18 -0300:
jm> > Folks,
jm> >
jm> > I'm playing with rtadvd, and I'm curious about a debug message I'm
jm> > getting when specifying Route Information options.
jm> >
jm> > My config file is this:
jm> > - cut here 
jm> > em0:\
jm> >  :addr="fc00:1::":prefixlen=64\
jm> >  :rtprefix="fc00:1::":rtplen=64:rtltime=1000
jm> >
jm> > em1:\
jm> >  :addr="fc00:2::":prefixlen=64\
jm> >  :rtprefix="fc00:2::":rtplen=64
jm> >  cut here 
jm> >
jm> > And when running radvd as:
jm> > /usr/sbin/rtadvd -D -f em0 em1
jm> >
jm> >
jm> > I get the following debug messages:
jm> >  cut here 
jm> > []
jm> > rtltime should be specified for interface em0.
jm> > rtadvd[1137]:  enter
jm> > rtadvd[1137]:  em0: join link-local all-routers MC group
jm> > rtadvd[1137]:  RA timer on em0 is set to 16:0
jm> > rtadvd[1137]:  ifname=em0 marked as TRANSITIVE (initial burst).
jm> > rtltime should be specified for interface em1.
jm> > []
jm> >  cut here 
jm> >
jm> > I'm curious why I get "rtltime should be specified for interface em0."
jm> > since the config for em0 does specify rtltime -- unless I'm missing
jm> > something.
jm>
jm> I only see rtltime on em0, and I don't see a closing colon after
jm> rtltime on em0.  Try adding a terminating colon on em0 and see if
jm> the problem goes away.

 An integer must use "#" like "foo#0" (not "foo=0") in the
 configuration file.  So

  :addr="fc00:1::":prefixlen=64\
  :rtprefix="fc00:1::":rtplen=64:rtltime=1000

 should be

  :addr="fc00:1::":prefixlen#64:\
  :rtprefix="fc00:1::":rtplen#64:rtltime#1000:

-- Hiroki


pgpcdBw_pjJK3.pgp
Description: PGP signature

Re: ifconfig prefer_source and IPv6 privacy extensions

[Hiroki Sato]

Jan Behrens  wrote
  in <20200313202833.cbbe8d1679ac0fd7a8078...@magnetkern.de>:

jb> Dear all,
jb>
jb> I'm using FreeBSD 12.1 with an ISP that supports IPv6. I have IPv6
jb> privacy extensions enabled (ipv6_privacy="YES" in /etc/rc.conf which
jb> sets net.inet6.ip6.prefer_tempaddr=1).
jb>
jb> Given my router and ISP (who supports IPv6), my machine's FreeBSD
jb> system assigns me 5 addresses through IPv6 autoconfiguration:
jb>
jb> link-local: fe80::%
jb> ULA:fd:
jb> ULA privacy:fd:
jb> Public: 2003::
jb> Public privacy: 2003::
jb>
jb> When I setup a static IPv6 address in the ULA range, such as
jb> (fd::2) and enable the "prefer_source" option (see man
jb> ifconfig), the "prefer_source" option is ignored. It seems that
jb> net.inet6.ip6.prefer_tempaddr=1 takes precedence.
jb>
jb> Calling sysctl net.inet6.ip6.prefer_tempaddr=0 fixes my problem but
jb> disables privacy extensions altogether (which I would like to keep
jb> enabled).
jb>
jb> Is it intended that "net.inet6.ip6.prefer_tempaddr" takes precedence
jb> over "prefer_source"? If yes, why?

 Yes, and the reason is that RFC 6724 specifies that behavior.

 Why do you want to use fd::2 over fd: as the
 default source address?  If prefer_source takes precedence, the
 tempaddr will nerver be used.

-- Hiroki


pgpuIULYQhHJy.pgp
Description: PGP signature

Re: Revisiting FreeBSD-SA-08:10.nd6 (or: avoiding IPv6 pain)

[Hiroki Sato]

Dennis Kögel  wrote
  in <523ba6cf-c2c3-4e55-b81c-cb8816e56...@neveragain.de>:

dk> Hi,
dk> 
dk> I‘ve spent quite some time debugging weird intermittent IPv6
dk> connectivity issues over the last few days.
dk> 
dk> It turned out that net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 fixed those
dk> problems.

 What was the problem more specifically?

-- Hiroki


pgpojrcV9EIjT.pgp
Description: PGP signature

[Differential] D23788: DRAFT: ng_ksocket: IPv6 address parsing and unparsing

[hrs (Hiroki Sato)]

hrs requested changes to this revision.
hrs added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> ng_ksocket.c:319
> +
> + for (i = 0; i < 8; i++) {
> + u_long val;

inet_pton in libkern should be used to parse an IPv6 address.  Also, you should 
consider to support a link-local address with an interface identifier such as 
[fe80::1%em0]:80.

> ng_ksocket.c:410
> +
> + slen += snprintf(cbuf, cbuflen, 
> "inet6/[%u:%u:%u:%u:%u:%u:%u:%u]",
> +   ((const u_int *)>sin6_addr.__u6_addr.__u6_addr16)[0],

Please use inet_ntop().  And sin6->sin6_scope_id must not be ignored.  The 
in-kernel representation of an link-local address has embedded scope zone id 
inside the address itself, so you might want to double-check the scope and 
value of sin6_addr.s6_addr16[1] in both cases of ntop and pton.

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D23788/new/

REVISION DETAIL
  https://reviews.freebsd.org/D23788

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org, hrs
Cc: hrs, imp, lutz_donnerhacke.de, melifaro, #contributor_reviews_base, 
freebsd-net-list, mmacy, kpraveen.lkml_gmail.com, marcnarc_gmail.com, 
simonvella_gmail.com, novice_techie.com, tommi.pernila_iki.fi
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: DHCPv6 client in base

[Hiroki Sato]

Roy Marples  wrote
  in :

ro> On 13/10/2019 20:32, Hiroki Sato wrote:
ro> > Ben Woods  wrote
ro> >in
ro> >:
ro> > wo> On Fri, 11 Oct 2019 at 08:32, Ben Woods 
ro> > wrote:
ro> > wo> As promised, I have completed my initial work to import dhcpcd
ro> > into FreeBSD
ro> > wo> base, and it is ready for review, testing and comment at the link
ro> > below.
ro> > wo> https://reviews.freebsd.org/D22012
ro> > wo>
ro> > wo> As per the comment from brooks@, I have opted to have it installed
ro> > in
ro> > wo> parallel with dhclient (which remains the default).
ro> >   How do you want to proceed the discussion?  I sent my view and made
ro> >   myself clear that importing dhcpcd into the base system as-is is not
ro> >   a good idea.  What is your answer to my concerns?  I also agree with
ro> >   Brooks about a need for sandboxing before the import if it will
ro> >   happen.  Do you have any plan to add changes to the imported dhcpcd?
ro>
ro> Sorry if it was not clear. The discussion involves what is the
ro> required acceptance for Priviledge Seperation because this is quite
ro> new to me.
ro>
ro> My current idea is to open DHCP, IPv6RA and DHCP6 ports, chroot, drop
ro> privs and fork. This concept is pretty standard thus far. These are
ro> listening ports only and will dry-run any received message through
ro> dhcpcd's two commons paths:
ro>   1) extract address and routing information without applying it
ro>   2) environment option generation from the whole message

 A typical separation is three process model which contains
 processes for 1) sending/accepting packets (and parsing them), 2)
 state machine for each protocol handling, and 3) global namespace
 access (file, routing socket, network interface state, etc).  The
 superuser privilege can be dropped in 1) and 2) completely.  1) and
 3) communicate with 2) on demand or event-driven basis.  1) do not
 communicate directly with 3).  Protocol-specific routines are in 1)
 and 2)---the former handles its wire-format, and the latter deals
 with protocol-specific state machines.

 However, this is often an overkill for a small, single-protocol
 network daemon.  A two process model which contains one for 1)+2) and
 another for 3) above is used in sbin/dhclient, for example.  I think
 this separation is the minimum level.  3) performs privileged tasks
 such as ioctls for network interfaces.

 I believe the three process model is appropriate for dhcpcd because
 of the nature of multi-protocol support.  Parsing is one of the
 attack surfaces.  For instances, a dhcp6_findoption() loop in
 dhcp6_recv() should be in process 1 and changes of D6_STATE(ifp)
 should be managed in process 2.  The current dhcp6_bind() directly
 uses dhcp6_findmoption() to extract options from a DHCP message on
 demand and also directly accesses the global namespace by using
 dhcp6_writelease(ifp).  These packet inspection and file access can
 be replaced with IPC requests to process 1 or 3 in the model, and it
 can be realized without a big structural change to the original logic
 in dhcp6.c (though it requires a certain amount of changes to the
 current code).

 In the ideal world everything should work fine and this kind of
 separation just sounds to make the program complex unnecessary, but
 an incomplete separation between the possible attack surfaces and
 access to the global namespace does not provide a good security even
 if the superuser privilege dropped.

 Note that these are just my own view, not a requirement for something
 nor feature request.  I think lack of privsep must be considered if
 dhclient is replaced, but I also think replacing dhclient is beyond
 the discussion of DHCPv6.

 Anyway, You might want to create a new email thread for sandboxing of
 dhcpcd on FreeBSD if you want to continue to discuss it.  Probably
 developers with more expertise in security can make a comment.

-- Hiroki


pgpwyQgQP7bHt.pgp
Description: PGP signature

Re: DHCPv6 client in base

[Hiroki Sato]

Ben Woods  wrote
  in :

wo> On Fri, 11 Oct 2019 at 08:32, Ben Woods  wrote:
wo> As promised, I have completed my initial work to import dhcpcd into FreeBSD
wo> base, and it is ready for review, testing and comment at the link below.
wo> https://reviews.freebsd.org/D22012
wo>
wo> As per the comment from brooks@, I have opted to have it installed in
wo> parallel with dhclient (which remains the default).

 How do you want to proceed the discussion?  I sent my view and made
 myself clear that importing dhcpcd into the base system as-is is not
 a good idea.  What is your answer to my concerns?  I also agree with
 Brooks about a need for sandboxing before the import if it will
 happen.  Do you have any plan to add changes to the imported dhcpcd?

 And, I think there is common mistake about how to invoke dhcpcd in
 D22012.  DHCPv6 client should be invoke upon RA with O-flag received,
 not invoked independently or by devd(8) upon a link-up event.  I do
 not want people to configure ifconfig_IF_ipv6="DHCP".  What people
 should be aware is if they want to allow receving RA.  Whether DHCPv6
 is required or not should be controlled by RA, not configuration on
 the host side. Also, DHCP-PD shuold be handled in rc.d script
 framework in some way.  Doing something similar to IPv4 DHCP client
 is not enough, and having both rtsold and dhcpcd is just confusing.

 I want to continue discussion about what is the best or better
 direction instead of going ahead with D22012.

-- Hiroki


pgpy6vvcLy3RU.pgp
Description: PGP signature

Re: DHCPv6 client in base

[Hiroki Sato]

Roy Marples  wrote
  in :

ro> On 11/10/2019 20:40, Hiroki Sato wrote:
ro> >   I do not have a strong objection on dhcpcd (I am using it on some of
ro> >   my FreeBSD boxes actually) but let me explain the reason why I chose
ro> >   wide-dhcp as the candidate.  That is because it is a small,
ro> >   functional DHCPv6-only implementation.  I am planning to rewrite it
ro> >   to add the missing bits and adjust it for a tighter integration with
ro> >   kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum.  I
ro> >   feel dhcpcd (or others) is too big for that purpose.
ro>
ro> How are you measuring that dhcpcd is too big?
..
ro> I don't consider dhcpcd to be big at all, and would love to know your
ro> rationale for calling it so.

 I did not mean the binary size.  Again, what I need for the base
 system import is source code just for core DHCPv6 procotol for
 further FreeBSD-specific changes.  dhcpcd contains source code for
 the other protocols than DHCPv6 and non-FreeBSD platforms though it
 is possible to compile a part of them, and applying changes to it
 would not be FreeBSD-only thing because you are maintaining it in a
 portable manner actively.  Importing involves those kind of aspects.
 I expressed them as "big" than importing wide-dhcp, which is no
 longer maintained by the original authors.

 Yes, FreeBSD can have a DHCPv6-only version of dhcpcd even at the
 source code level, which will be much smaller.  But if doing so and
 applying FreeBSD-specific changes which cannot be upstreamed to it,
 we need additional steps to adjust a partial set of the dhcpcd source
 code and the contents will be diverged from the origial distribution.
 Although it is still possible, I think it is not good for both
 FreeBSD and dhcpcd.  That is because if one uses dhcpcd, rtsold in
 the base system should not be used and relying solely on dhcpcd for
 handling incoming RAs would be much better.  And probably IPv4 DHCP
 should also be handled by dhcpcd for consistency on the system.
 Thus, the question is: which is worth doing, maintaining a stripped
 version of dhcpcd or a client part of wide-dhcp, both with
 FreeBSD-specific changes applied?  Adding IPC between rtsold,
 ifconfig, and DHCPv6 client is planned for better control and user
 experience, for example.  I simply thought a
 no-longer-actively-maintained one with smaller code base is easier
 for that purpose, assuming there is no big difference in the core
 protocol coverage.  I do not insist that this is based on inferiority
 of dhcpcd in terms of quality or absolute size.  My apologies if my
 previous (and/or this) email sounds offending.  How easier we can
 chop and cook it matters.

 I emphasize again here that people who want to use dhcpcd are still
 able to install net/dhcpcd and override a combination of utilities
 such as rtsold.  Ditto for ISC's IPv6-capable dhclient.  My opinion
 about the import is that if we adopt dhcpcd in the base system, we
 should replace all of the current dhclient for IPv4 and rtsold
 together.  Of course we should consider it will need Capsicum or
 privsep for sandboxing and involve a bigger impact for IPv4 users at
 least.

 If there is no option except for dhcpcd I will go ahead with it
 regarless of my ealier mentioned concerns.  So that is why I would
 like to know if wide-dhcp has a critical issue which cannot be fixed
 easily or missing feature at this moment.

ro> This isn't a question about wide-dhcp specifically, but I feel it's a
ro> good question.
ro>
ro> Do you plan on supporting a multihomed system with hotpluggable
ro> interfaces all auto configured?
ro> I'm looking at the BUGS section for rtsold and these bugs
ro> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138547

 For multiple sources of RDNSS information, FreeBSD currently handles
 them by resolvconf(8) (yes, one of your works has been already
 imported) in the base system.  The default configuration does not
 behave very well, so for a good user experience, one needs to
 configure resolvconf.conf to control ordering and overrides.  The
 dhclient processes do not work collaboratively across multiple
 interfaces because they are just invoked independently, on a
 per-interface basis.  rtsold does not, either.  That is one of the
 reasons why I would like to add IPC between rtsold and DHCPv6 client.
 If they work, it can be implemented in dhclient in a similar way.

ro> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218191

 I could not understand what prevented dhclient from working at the
 first glance of this PR, but the cause may also be the fact that
 multiple dhcients work independently and override the default router,
 RDNSS, and/or etc.

 These scenarios are in my goals because IPv6 multihoming is more
 likey to happen than IPv4 while I am still not sure it will be a
 complete solution.  If IPC between the per-interface daemons is not
 suf

Re: DHCPv6 client in base

[Hiroki Sato]

Ben Woods  wrote
  in :

wo> On Thu, 16 May 2019 at 2:25 am, Hiroki Sato  wrote:
wo>
wo> >  wrote
wo> >   in <001e01d50b49$176104d0$46230e70$@gmail.com>:
wo> >
wo> > dr> Has anyone ever thought or considered integrating an IPv6 DHCP client
wo> > in
wo> > dr> base?
wo> >
wo> >  I have a plan to import wide-dhcp6 into the base system because it is
wo> >  simple enough.
wo> >
wo> > dr> net/dhcp6 isn't really maintained anymore from the KAME days it works
wo> > for
wo> > dr> basic functionality but fails when a more complex config is required.
wo> >
wo> >  More specifics about the complex configuration?
wo> >
wo> > -- Hiroki
wo>
wo>
wo> I would like to discuss whether dhcpcd is a better option to import into
wo> FreeBSD base, rather than wide-dhcp6.
wo>
wo> dhcpcd has the following benefits that I can see:
wo> - Actively maintained [1] (wide-dhcp6 seems to be stale for 11 years?)
wo> - Used in NetBSD and DragonflyBSD (code sharing amongst the BSDs will
wo> facilitate collective progress and lesson sharing). Roy, the upstream
wo> maintainer, has committer on both NetBSD and DragonFlyBSD.
wo> - more feature rich [2]
wo>
wo> [1] https://roy.marples.name/projects/dhcpcd/history
wo> [2] https://roy.marples.name/projects/dhcpcd/features
wo>
wo> hrs - what are your thoughts?

 I do not have a strong objection on dhcpcd (I am using it on some of
 my FreeBSD boxes actually) but let me explain the reason why I chose
 wide-dhcp as the candidate.  That is because it is a small,
 functional DHCPv6-only implementation.  I am planning to rewrite it
 to add the missing bits and adjust it for a tighter integration with
 kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum.  I
 feel dhcpcd (or others) is too big for that purpose.

 IMHO, the directions of further developments of IPv6 functionality on
 FreeBSD, NetBSD (dhcpcd), OpenBSD (slaacd + others), and DragonFly
 BSD (dhcpcd) have already been diverged.  For RFC 7217 I already have
 an in-kernel implementation (not committed yet), and I am also
 working on SeND (RFC 3971, not directly related to DHCPv6 though).
 My goal is to integrate these small implementations into the base
 system and make them possible to work together.  So for DHCPv6, I
 think an implementation of only DHCPv6 is the best.

 If people want a more feature-rich implementation or the same one on
 other systems, they can still use dhcpcd or ISC's dhclient even after
 the import.

 Of course this assumes that wide-dhcp works to some degree.  If it
 does not, importing it to the base system does not make sense.  I
 have used it in various scenarios for a long time such as RA + O flag
 on native IPv6 over Ethernet, DHCPv6-PD over PPPoE/L2TP, and others
 which are complex enough, and understand what works and what is
 missing (poor DUID format support, for example).  The popular way to
 use DHCPv6 is IA_PD, and wide-dhcp works well with it.

 So I have a question.  What is missing feature in wide-dhcp which you
 are concerned about?  I know some, but it has most of the basic
 functionality of DHCPv6 and I think it is enough as a minimal
 implementation for the base system.  My primary reason is that it is
 just for DHCPv6 as mentioned earlier and I believe it is maintainable
 in the base system.  I would like to know other people's opinion if
 there is something critical.

-- Hiroki


pgpU6SHrgg0WX.pgp
Description: PGP signature

Re: DHCPv6 client in base

[Hiroki Sato]

Roy Marples  wrote
  in :

ro> > A dhcp Client is a necessary part of the OS (though a bit less so with
ro> > IPV6) but the serer side can be a port. (as it is).
ro>
ro> How is FreeBSD handling DNSSL + RDNSS over IPv6RA? That's pretty
ro> standard now and I don't see a userland compoenent for it.

 rtsold(8) handles it.  It is also responsible for invoking a DHCPv6
 client when receiving an O-flag RA.

-- Hiroki


pgppejs0SrGoA.pgp
Description: PGP signature

Re: rpc.statd already ipv6 clean?

[Hiroki Sato]

Mihir Luthra  wrote
  in :

lu> >
lu> >
lu> >  I think you should learn TI-RPC API first.  The nettype specifies a
lu> >  class of transport protocol, not address family.
lu> >
lu> > Thanks, I did some more research on TI-RPC today.
lu> In `statd.c` what I see is in `create_service()`/`complete_service()`,
lu> transport info is being fetched through getnetconfig(), which makes it
lu> listen on all transports. I guess its clean in `statd.c` but same can also
lu> be done in `procs.c`/`file.c`. Maybe trying all transports until it finds
lu> one which is connectionless? Apologies if I got something wrong, new to
lu> this topic.

 clnt_create() checks /etc/netconfig and tries all of the transport
 protocols with the specified class which are listed there, and then
 chooses the first usable one.  So if IPv6 is available, "udp6" will
 be used because it is before "udp".

 statd.c handles the bind addresses on the server (service) side while
 file.c and procs.c handle the client calls.  They are different.

lu> Also, while looking at the code, I think it always assumes ipv4 is always
lu> present. Like `127.0.0.1` is added to host list always. On ipv6 only
lu> machine this may fail.

 Yes.  We should fix this kind of hardcoded loopback addresses and
 make userland utilities transport-independent wherever possible.  It
 can be replaced with getaddrinfo() with AF_UNSPEC for all available
 address families.

-- Hiroki


pgphQfOnGgGXL.pgp
Description: PGP signature

Re: rpc.statd already ipv6 clean?

[Hiroki Sato]

Mihir Luthra  wrote
  in :

lu> >  I think the project page has wrong information regarding rpc.statd.
lu> >  Although it is not clean from the viewpoint of transport independent,
lu> >  it works with IPv6.
lu> >
lu> >
lu> I see, in file.c/procs.c , clnt_create() calls are hardcoded to "udp". Code
lu> in `statd.c` is handled correctly for tcp/udp/tcp6/udp6? .Did I get your
lu> point correctly?
lu> Also, going through man page of clnt_create, it states usage for only
lu> tcp/udp and not udp6/tcp6.

 I think you should learn TI-RPC API first.  The nettype specifies a
 class of transport protocol, not address family.

-- Hiroki


pgpjwQgIkWlNq.pgp
Description: PGP signature

Re: rpc.statd already ipv6 clean?

[Hiroki Sato]

Mihir Luthra  wrote
  in :

lu> Hi everyone,
lu>
lu> Just as mentioned in [1], rpc.statd is not ipv6 clean.
lu>
lu> Although I have been through the code, and didn't found any issues until
lu> now. The code conditionally checks for ipv6/ipv4 everywhere and uses ipv6
lu> compatible functions.
lu>
lu> As per one old commit [2], seems rpc.statd was already made to function
lu> correctly with ipv6.
lu>
lu> I searched bugzilla(thinking someone may have reported something similar,
lu> giving rise to the project), but didn't see anything similar for rpc.statd
lu> and ipv6 support.
lu>
lu> I wanted to ask if someone could share the issues they encountered while
lu> using rpc.statd with ipv6?

 I think the project page has wrong information regarding rpc.statd.
 Although it is not clean from the viewpoint of transport independent,
 it works with IPv6.

 There are more userland utilities which do not support IPv6---rwhod,
 yp*, etc.

-- Hiroki


pgpdPhqL5rI56.pgp
Description: PGP signature

Re: Link flap for setting ether/MAC address

[Hiroki Sato]

Anish  wrote
  in :

ak> Hi all,
ak> Got a very basic question, why physical link is flapped when we set the
ak> address
ak>
ak> # dmesg -c
ak> # ifconfig ix1 ether 70:6d:15:1f:12:72
ak> ..wait..
ak> # dmesg
ak> ix1: link state changed to DOWN
ak> ix1: link state changed to UP
ak> #
ak>
ak> is this a bug or expected behavior? We could update our MAC in next ARP
ak> request without link flap or some other system like switch etc expect the
ak> link flap to update ARP. Is this the behavior for other systems?

 I think this depends on the driver.  Some drivers reset the NIC when
 the MAC address is changed mostly because it is an easy way to
 re-configure the multicast filtering rules or the other settings
 which must be updated for the new MAC address.  It causes a link
 flap.  For upper layers above the NIC driver, you are correct.

-- Hiroki


pgpRXF1A1Hdmn.pgp
Description: PGP signature

Re: testing rpc.statd

[Hiroki Sato]

Mihir Luthra  wrote
  in :

lu> Although I saw a test.c [1] file in the directory. I was wondering if this
lu> complete is the test suite for statd? I tried running `make test` but it
lu> said `No such file or dir: test.c`. Am I doing something wrong here?

 No, it was broken.  I fixed test.c in r352570 just now.  I do not
 think it is a complete functionality test but it can check if
 relevant RPC calls work or not.

-- Hiroki


pgpkAqGnXtom_.pgp
Description: PGP signature

Re: Several IPv6 routers and default gateway choice

[Hiroki Sato]

Victor Sudakov  wrote
  in <20190906035608.ga45...@admin.sibptus.ru>:

va> Hiroki Sato wrote:
va> > va> Can any IPv6 unicast or link-local address be configured as an anycast
va> > va> address of a router?
va> >
va> >  Yes.  There is no restriction about address scope.
va> >
va> >  You might want to read RFC 4291, which defines Subnet-Router anycast
va> >  address, and RFC 2526, which defines the other reserved IPv6 subnet
va> >  anycast addresses.  In general, the former one can be used for
va> >  routing purpose.
va>
va> Interestingly, RFC4291 says that "All routers are required to support
va> the Subnet-Router anycast addresses for the subnets to which they have
va> interfaces." In practice, I don't observe this. A FreeBSD router does
va> not configure such an address automatically, for example.

 They will be automatically configured when an ipv6_prefix_IF
 rc.conf(5) variable is used to configure a prefix:

(from rc.conf(5) man page)
 ipv6_prefix_ed0="2001:db8:1:0 2001:db8:2:0"

 is equivalent to the following:

 ifconfig_ed0_alias0="inet6 2001:db8:1:: eui64 prefixlen 64"
 ifconfig_ed0_alias1="inet6 2001:db8:1:: prefixlen 64 anycast"
 ifconfig_ed0_alias2="inet6 2001:db8:2:: eui64 prefixlen 64"
 ifconfig_ed0_alias3="inet6 2001:db8:2:: prefixlen 64 anycast"

 These Subnet-Router anycast addresses will be added only when
 ipv6_gateway_enable is YES.
--

va> RFC2526 is dim, I think it's because of this RFC the last usable address
va> on a subnet ends in ff7f instead of . I wonder if anyone anywhere
va> uses those subnet anycast addresses.

 That is because there are few practical applications of the IPv6
 anycast address other than failover across multiple routers.

-- Hiroki


pgp5KWJ7s0SKe.pgp
Description: PGP signature

Re: Several IPv6 routers and default gateway choice

[Hiroki Sato]

Victor Sudakov  wrote
  in <20190901141047.ga56...@admin.sibptus.ru>:

va> Hiroki Sato wrote:
va> >  Another way to realize failover is to use a common anycast address on
va> >  multiple routers. For example, a router is always able to have
va> >  fe80::/64 as an anycast address like this:
va> >
va> >   router# ifconfig igb0 inet6 fe80::/64 anycast
va> >
va> >  and you can simply configure fe80::/64 as the default router on the
va> >  hosts.  Multiple routers with the same fe80::/64 can coexist on the
va> >  same segment, and hosts will choose one of them with no further
va> >  configuration.  A caveat in this case is that the first router always
va> >  wins and there is no knob to set the preferences across the routers
va> >  with the same anycast address configured.
va>
va> Thank you Hiroki, this was very informative and useful.
va>
va> Can any IPv6 unicast or link-local address be configured as an anycast
va> address of a router?

 Yes.  There is no restriction about address scope.

 You might want to read RFC 4291, which defines Subnet-Router anycast
 address, and RFC 2526, which defines the other reserved IPv6 subnet
 anycast addresses.  In general, the former one can be used for
 routing purpose.

va> address of a router? Is this a replacement for VRRP and carp(4)?

 Mostly yes.  VRRP and CARP use a virtual IP address and active
 heartbeat packets to detect unreachability between the member NICs.
 They support fine-grained configurations such as heartbeat interval,
 password, and preference.  On the other hand, anycast IPv6 default
 router uses built-in unreachability detection of the IPv6 core
 protocol.  No control communication happens between NICs with the
 same anycast address.  The client will pick up one router and use it
 as long as it is reachable.  It is only for IPv6, of course.

 So the anycast address just works if you do not need password or
 control of the master selection.  For master selection, router
 advertisements with different preference values can be used in
 combination with anycast addresses.

-- Hiroki


pgp2UO8dPmqHk.pgp
Description: PGP signature

Re: Several IPv6 routers and default gateway choice

[Hiroki Sato]

Victor Sudakov  wrote
  in <20190830021228.ga66...@admin.sibptus.ru>:

va> Dear Colleagues,
va>
va> If a FreeBSD host receives router advertisements from several IPv6
va> routers, on a LAN segment, which would be chosen as the default gateway?

 One reachable router will be selected based on the default router
 preference value in RA, which is defined in RFC 4191.  If all of the
 routers have the same preference, the first one will win.

va> Can this be used for failover?

 Yes.

 Another way to realize failover is to use a common anycast address on
 multiple routers. For example, a router is always able to have
 fe80::/64 as an anycast address like this:

  router# ifconfig igb0 inet6 fe80::/64 anycast

 and you can simply configure fe80::/64 as the default router on the
 hosts.  Multiple routers with the same fe80::/64 can coexist on the
 same segment, and hosts will choose one of them with no further
 configuration.  A caveat in this case is that the first router always
 wins and there is no knob to set the preferences across the routers
 with the same anycast address configured.

-- Hiroki


pgplQvCuDbhfp.pgp
Description: PGP signature

Re: addrs capability of rtadvd?

[Hiroki Sato]

"Bjoern A. Zeeb"  wrote
  in <7a7874fa-e663-4ec9-b349-c46d32982...@lists.zabbadoz.net>:

bz> On 17 Aug 2019, at 6:03, John-Mark Gurney wrote:
bz>
bz> > I am setting up ipv6, and going through the guide at:
bz> > https://www.freebsd.org/doc/handbook/network-ipv6.html#idp71931000
bz> >
bz> > And noticed the addrs#1 property in the example.  I checked the
bz> > rtadvd.conf man page, and I do not see an entry for addrs.  Should
bz> > this be removed?  I also did a quick check of the rtadvd source code,
bz> > and I don't see a makeentry for addrs either.
bz> >
bz> > If no one objects, I'll remove it.
bz>
bz> Or replace it with a working example?  Would something like this work
bz> to even show multiple prefixes (beyond the handbook example)?
bz>
bz>   :addr=“2001:db8:4242:::”:prefixlen#64:\
bz>   :addr2="2001:db8:4242:1::”:prefixlen2#64:
bz>
bz>
bz> And yes, removing the “:addrs#1” from the handbook should be fine.

 I prefer to drop the rtadvd.conf configuration example in the
 handbook completely.  Adding a GUA on rl0 automatically makes
 rtadvd(8) to advertise the prefix.  It also works with multiple
 prefixes.

-- Hiroki


pgpfgue8bEAxI.pgp
Description: PGP signature

Re: rss tldr

[Hiroki Sato]

Andriy Gapon  wrote
  in <42d8cbd1-ad28-d5a2-ecec-218763e2d...@freebsd.org>:

av> Is there any up-do-date documentation on RSS/FreeBSD ?
av> I am looking -- for a friend :) -- for some simple things like:
av> - is it enabled by default? if not, how to enable?

 FreeBSD supports RSS in device drivers for RSS-aware multiqueue NICs
 and the IPv4/IPv6 network stack while it is not enabled in GENERIC.
 "options RSS" and "options PCBGROUP" are required to enable it.

 IIRC the following URL is the document we currently have:

  https://wiki.freebsd.org/NetworkRSS

av> - how / what to configure if any configuration is needed?

 Basically no configuration is needed if the NIC device driver
 supports RSS while RSS generally has additional configuration knob
 for CPU-to-queue bindings in case that the default configuration does
 not work with the specific traffic pattern from performance
 perspective.

 net.inet.rss sysctl nodes are available for some network stack-level
 RSS information.  RSS-aware NIC device drivers have their own knobs
 (or userland utilities) to enable/disable/change RSS configuration.
 Multiqueue must be enabled in the device driver, of course.

av> - how to observe / verify that it works?

 There is no generic way to verify if it works or not at this moment.
 Probably queue utilization statistics which can be found by using
 "netstat -Q" is useful.  You can also find interrupt distribution and
 CPU utilization can be found by using "vmstat -ai", for example.

av> - how to find out, before purchasing, if a controller and its driver
av> support RSS?

av> My first impression is that answers really depend on the hardware /
av> drivers.  But maybe there are some common things and maybe there are
av> some easy answers for the most common and important controllers (like
av> those from Intel plus virtual/cloud ones like ena/vmx/hn).

 I do not have precise information about which NIC supports RSS and
 how well it works, but Chelsio (cxgb, cxgbe), Intel (em, igb, ixgbe,
 ixl), Solarflare (sfxge), Mellanox (mlx5), QLogic (qlxgb, bxe),
 Cavium (qlnx) should support it according to the device driver source
 files.

-- Hiroki


pgpzXRP5UlEwK.pgp
Description: PGP signature

Re: Preferring internal IPv6 source address over gif tunnel IP?

[Hiroki Sato]

Viktor Dukhovni  wrote
  in <20190731120705.gc24...@straasha.imrryr.org>:

vi>   1. Point to point tunnel /128:
vi>
vi> cloned_interfaces="gif0"
vi> create_args_gif0="tunnel  "
vi> ifconfig_gif0_ipv6="inet6 ::2 ::1 
prefixlen 128"
vi> ipv6_defaultrouter="::1"

 You do not need to use ifconfig_gif0_ipv6 for a point-to-point
 configuration with .  The following configuration
 should do the trick while this is different from suggested one from
 he.net:

  cloned_interfaces="gif0"
  create_args_gif0="tunnel  "
  ifconfig_gif0_ipv6="inet6 auto_linklocal"
  ipv6_defaultrouter="-interface gif0"

 Using this configuration, your source IPv6 address will be that on
 igb1.  And if you have two or more physical interfaces you can define
 ip6addrctl.conf to control which address is used for the source
 address depending on the destination address.

-- Hiroki


pgppC2rpws78v.pgp
Description: PGP signature

Re: Is there an way for a program to know when the list of network interfaces has changed (without rescanning them)?

[Hiroki Sato]

Yuri  wrote
  in :

yu> I am asking because wireshark doesn't sense the interface list
yu> changes, and it just always shows the list from the time it was
yu> launched .

 You can open a routing socket and watch it to see if RTM_IFANNOUNCE
 message is coming.  The following command lines (on two different
 terminals on the same machine) show how this works when a new interface
 arrives:

  termA% route monitor
  (this waits for routing messages)

  termB# ifconfig tap0 create

 An example code to handle routing messages can be found in
 src/sbin/route/route.c.

-- Hiroki


pgpYGqOwuFwCZ.pgp
Description: PGP signature

Re: DHCPv6 client in base

[Hiroki Sato]

 wrote
  in <006001d50b53$72a22e00$57e68a00$@gmail.com>:

dr> >  I have a plan to import wide-dhcp6 into the base system because it is  
simple
dr> > enough.
dr>
dr> Thats nice! Any timeline for this; 13.0 RELEASE?

 Yes, at the latest.  I originally planned it before 12.0 but not
 happened for some non-technical reasons.

dr> >  More specifics about the complex configuration?
dr>
dr> My initial wording wasn't correct; wide-dhcp is in fact featureful although 
buggy when config files get a bit bigger.
dr> Well I'm trying to assign a 64 prefix to two virtual interfaces and one 
physical from a 56 delegation.
dr> For this config it errors out on parsing the config file ... while I'm 99% 
certain there is not a problem in it.
dr>
dr> interface em0 {
dr> send rapid-commit;
dr> send ia-na 1;
dr> send ia-pd 1;
dr> };
dr>
dr> id-assoc na 1 { };
dr>
dr> id-assoc pd 1 {
dr> prefix ::/56 infinity;
dr> prefix-interface igb0 {
dr> sla-id 0;
dr> sla-len 8;
dr> };
dr> prefix-interface lo1 {
dr> sla-id 1;
dr> sla-len 8;
dr> };
dr> prefix-interface tun0 {
dr> sla-id 2;
dr> sla-len 8;
dr> };
dr> };
dr>
dr> May 15 21:20:50 May 15 21:20:50 vados dhcp6c[94383]: failed to parse 
configuration file

 In this configuration dhcp6c does not work because lo1 has no L2
 address to generate an interface ID which will be used with the /64
 prefix.  Is there any specific reason why you want to use a loopback
 interface?

-- Hiroki


pgpqeIx39dhXR.pgp
Description: PGP signature

Re: DHCPv6 client in base

[Hiroki Sato]

 wrote
  in <001e01d50b49$176104d0$46230e70$@gmail.com>:

dr> Has anyone ever thought or considered integrating an IPv6 DHCP client in
dr> base?

 I have a plan to import wide-dhcp6 into the base system because it is
 simple enough.

dr> net/dhcp6 isn't really maintained anymore from the KAME days it works for
dr> basic functionality but fails when a more complex config is required.

 More specifics about the complex configuration?

-- Hiroki


pgpvtNLDmn2m9.pgp
Description: PGP signature

[Differential] D19422: if_vxlan(4) Allow set MTU more than 1500 bytes.

[hrs (Hiroki Sato)]

hrs added a comment.


  Adding jumbo frame support looks good to me.   However, is it better to 
support this in ether_ioctl() instead of a driver-specific ioctl handler?  
Check of (ifr->ifr_mtu > ETHERMTU) in ether_ioctl() can be changed to check if 
the interface has IFCAP_JUMBO_MTU or not.

INLINE COMMENTS

> if_vxlan.c:2273
> + case SIOCSIFMTU:
> + if (ifr->ifr_mtu < ETHERMIN || ifr->ifr_mtu > ETHERMTU_JUMBO) {
> + error = EINVAL;

I think the maximum value should be calculated by considering encap overhead.  
VXLAN adds a header with 50-100 byte long depending on the outer protocol.

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D19422/new/

REVISION DETAIL
  https://reviews.freebsd.org/D19422

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: aleksandr.fedorov_itglobal.com, bryanv, hrs, #network, rgrimes
Cc: evgueni.gavrilov_itglobal.com, olevole_olevole.ru, ae, freebsd-net-list, 
krzysztof.galazka_intel.com
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: use of #ifdef INET and #ifdef INET6 in the kernel sources

[Hiroki Sato]

Rick Macklem  wrote
  in 
:

rm> Rick Macklem wrote:
rm> [stuff snipped]
rm> >The AF_LOCAL code was in head for a short period of time before a vnode 
lock panic()
rm> >issue was reported and I reverted the patch.
rm> >
rm> >Here is the commit log message for that reversion:
rm> >PR#230752 shows a panic where an nfsd thread tries to do soconnect() on
rm> >the AF_LOCAL socket used by the nfsuserd while already holding an
rm> >exclusive lock on it. I am not 100% sure how this happens, but since an
rm> >AF_LOCAL socket is in the file system namespace it is conceivable that it
rm> >could lock it and then attempt an upcall to the nfsuserd.
rm> >However, reverting r320757 stops the nfsuserd from using an AF_LOCAL
rm> >socket, so it should avoid any such panic().
rm> >r320757 did fix a problem with running the nfsuserd when jails were
rm> >enabled, but that can be dealt with less elegantly by allowing the
rm> >use of an alternate address instead of 127.0.0.1.
rm> >The gssd daemon also uses an AF_LOCAL socket, but it will do upcalls
rm> >before the nfsd thread processes the RPC, so I think it should not
rm> >be suseptible to this problem.
rm>
rm> Oops. Duh. I should have read my own commit message more carefully...
rm> It was an nfsd thread, so the file system wasn't an NFS mount, it was a file
rm> system exported to NFS client(s).
rm>
rm> It is possible to test to see if a file system is exported, but that can 
change
rm> at any time, so even if it isn't exported when the nfsuserd daemon is 
started,
rm> it could be exported later.
rm>
rm> So, I don't see any way AF_LOCAL can be safely used here.
rm>
rm> Oh, and the kernel RPC expects to be able to do a soconnect() using a
rm> sockaddr, so socketpair() won't do the trick.

 Thank you for your clarification.  I agree that AF_INET/AF_INET6
 loopback address is much easier to avoid file system dependency.  For
 the original question about whether we should use a hard-coded
 address or not, my suggestion is that we do not need to use the name
 "localhost" or rely on any Internet domain resolver code such as DNS
 as long as the hard-coded addresses cover all of supported address
 families (we have only two in practice).

 However, an option to specify a loopback address to be used might
 mitigate multiple loopback address issues in classical jail w/o VNET
 or multiple supported address families.  Is there any problem with
 using NFSSVC_NFSUSERDPORT to pass a struct sockaddr
 (i.e. udptransp->xp_ltaddr, not only xp_port) directly?  I think
 checking on kernel side if (sa_family == AF_INET or AF_INET6) and the
 address is already bound before the newfs_connect() call in
 nfsrv_nfsuserdport() guarantee that the specified sockaddr is a
 loopback address.

 Anyway, we might want to have AF_LOCAL socket with namespace which
 does not depend on any file system to communicate between kernel and
 userland.  Linux has it for a long time (by putting '\0' at the head
 of an AF_LOCAL address) while I am still not sure if this is the best
 way to implement.  While a new protocol family (PF_KEY is used in
 IPsec for example) also works for this purpose, it is probably a
 sledgehammer to crack a nut.

-- Hiroki


pgpqPpnKIfYSZ.pgp
Description: PGP signature

Re: correct IP# for NFS kernel upcall to userland daemon

[Hiroki Sato]

Rick Macklem  wrote
  in 
:

rm> In this case, I am concerned that the daemon will not be able to start up 
under
rm> conditions where the DNS service isn't yet functional. (This problem can 
mostly
rm> be avoided by specifying "localhost" in /etc/hosts and configuring the 
system to
rm> use that file before DNS, but I still don't like having this dependency on 
DNS for
rm> the daemon starting up.)
rm> Note that the upcall will work for any IP# that refers to the local machine 
and it
rm> does not need to be the one specified for "localhost" in the DNS.
rm>
rm> So, do you think I should do a lookup for "localhost" at daemon startup or 
use
rm> a hardwired "127.0.0.1/::1"?

 I do not think using INADDR_LOOPBACK or IN6ADDR_LOOPBACK_INIT is
 harmful for this purpose.  A properly configured lo0 should be a
 reasonable assumption.

 However, I still think using a loopback address in AF_INET or
 AF_INET6 for local communication is not a good idea when AF_LOCAL
 works.  A properly configured file system is easier than lo0 in many
 cases.  An unnamed pair of connected sockets which can be created by
 socketpair(2) would be ideal for this purpose, but IIRC there is no
 handy way to send one across kernel and userland...

-- Hiroki


pgpcAaAl_UC1B.pgp
Description: PGP signature

Re: use of #ifdef INET and #ifdef INET6 in the kernel sources

[Hiroki Sato]

"Rodney W. Grimes"  wrote
  in <201902280158.x1s1wi7s053...@pdx.rh.cn85.dnsmgr.net>:

fr> >
fr> > I know both of these groups still do exist.
fr> >
fr> > Also every code not compiled in is not an attack surface, where you
fr> > think it?s executed or not.
fr>
fr> This last reason is/was a prevelent one for me for a long time,
fr> diven ipv6 is trying to autoconfigure stuff and interfaces
fr> just get a link local address that is reachable that I would
fr> have to secure.  Its was/is a royal pita to do that for lots of
fr> machines.
fr>
fr> Am I missing something in there is just some way to turn off the
fr> link local ipv6 address?

 There is a way to disable automatic link-local address configuration
 but completely turning it off prevents NDP from working.  Having a
 knob to restrict L3 communication over link-local addresses may be a
 good compromise.  At this moment, a packet filter is required to do
 so.

-- Hiroki


pgptkGnWC1_nm.pgp
Description: PGP signature

Re: IPv6: "xxx::x already configured" in logs... why?

[Hiroki Sato]

Lawrence Stewart <lstew...@freebsd.org> wrote
  in <56d1a947-a0a1-0297-7151-4e36ab53c...@freebsd.org>:

ls> On 29/03/2017 21:49, Rui Paulo wrote:
ls> > On Wed, 2017-03-29 at 21:46 -0500, Lawrence Stewart wrote:
ls> >> [resurrecting an old thread]
ls> >>
ls> >> On 19/06/2014 23:08, Hiroki Sato wrote:
ls> >>> Larry Rosenman <l...@lerctr.org> wrote
ls> >>>   in <20140619140801.ga65...@thebighonker.lerctr.org>:
ls> >>>
ls> >>> le> > le> Ideas? (I may be an idiot, so any criticism welcomed).
ls> >>> le> > le>
ls> >>> le> > le> if you need the 1841's config, I can supply that as
ls> >>> well.  It's using a Hurricane
ls> >>> le> > le> electric Tunnel.
ls> >>> le> >
ls> >>> le> >  How frequent were the log message added into
ls> >>> /var/log/messages?  And
ls> >>> le> >  when did it start to happen after boot.  Just after lagg0 is
ls> >>> le> >  configured?
ls> >>> le> >
ls> >>> le> > -- Hiroki
ls> >>> le> Looks like:
ls> >>> le>
ls> >>> le> Jun 12 07:00:01 thebighonker kernel: in6_ifadd:
ls> >>> 2001:470:1f0f:3ad:223:7dff:fe9e:6e8a is already configured
ls> >>>
ls> >>>  Thank you.  Three more questions:
ls> >>>
ls> >>>  1. output of "ifconfig lagg0", "ifconfig bce0", and "ifconfig
ls> >>> bce1".
ls> >>>
ls> >>>  2. output of "netstat -s -i".
ls> >>>
ls> >>>  3. output of "ndp -p".
ls> >>>
ls> >>>  The cause of the message is that the automatically-configured
ls> >>> address
ls> >>>  is not recognized as "configured" one and FreeBSD IPv6 stack is
ls> >>>  trying to add it every time a Router Advertisement message is
ls> >>>  received.  I am still not sure why it happened, but the above
ls> >>> three
ls> >>>  would help for further investigation.
ls> >>
ls> >> I've recently set up a VPS with v6 and am seeing the same "in6_ifadd:
ls> >>  is already configured" messages in response to periodically
ls> >> received router advertisements every 5-10 mins. The host is a KVM-
ls> >> based
ls> >> virtual machine with vtnet-based NIC. v6 is fully functional with the
ls> >> statically assigned v6 address, but the spam in /var/log/messages is
ls> >> annoying.
ls> >>
ls> >>
ls> >> FreeBSD revision:
ls> >>   FreeBSD lauren 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315059: Sun
ls> >> Mar
ls> >> 12 20:44:50 AEDT 2017
ls> >> root@builder-head-amd64:/usr/obj/lauren/usr/src/sys/GENERIC-
ls> >> NODEBUG  amd64
ls> >>
ls> >>
ls> >> Relevant bits from /etc/rc.conf:
ls> >>   rtsold_enable="YES"
ls> >>   ipv6_activate_all_interfaces="YES"
ls> >>   rtsold_flags="-aF"
ls> >>   ifconfig_vtnet0_ipv6="inet6  prefixlen 64"
ls> >>
ls> >>
ls> >> Interface:
ls> >>   vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
ls> >> mtu 1500
ls> >>
ls> >> options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_H
ls> >> WCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
ls> >> ether 
ls> >> inet  netmask 0xfe00 broadcast 
ls> >> inet6 %vtnet0 prefixlen 64 scopeid 0x1
ls> >> inet6  prefixlen 64
ls> >> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
ls> >> media: Ethernet 10Gbase-T 
ls> >> status: active
ls> >>
ls> >>
ls> >> I would have thought rtsold should be able to play nice with
ls> >> statically
ls> >> assigned v6 addresses... any ideas?
ls> >
ls> > Hmm, why would it?  If you setup an IPv6 address and then there's a
ls> > router solicitation advertising the same address, the log message makes
ls> > sense.
ls> >
ls> > I don't think you should run rtsold if you have a static IPv6 address.
ls>
ls> How would the host learn about router(s) on the network and other
ls> addresses it might want? (In my particular environment, I'm pretty sure
ls> they don't change so could be statically configured, but interested in
ls> understanding if (and why) these are mutually exclusive modes of operation).

 As Rui already pointed out, I guess yo

Re: fe80::1%lo0

[Hiroki Sato]

Anton Yuzhaninov  wrote
  in <94a99b96-808b-8f50-a4a3-eec865973...@citrin.ru>:

ci> Hello,
ci>
ci> Why FreeBSD adds fe80::1%lo0 to the loopback interface?
ci>
ci> I know, that in IPv6 each interface should have a link-local address,
ci> but ::1 can be considered as link-local:
ci> https://tools.ietf.org/html/rfc4291#section-2.5.3

 FreeBSD's IPv6 stack was written before RFC 4291 clarifies whether
 ::1 is a link-local address or not---currently the implementation
 does not recognize ::1 as an address with link-local scope.

ci> I think fe80::1 is unnecessary can be removed. For all practical
ci> purposes ::1 should be enough.

 No.  It may work with no link-local address but an unexpected
 behavior can happen in the kernel even if it is not harmful actually.
 If we really want to remove it, address scope of ::1 needs to be
 changed throughout the kernel in a consistent manner first.

-- Hiroki


pgpAsO1uo2hIJ.pgp
Description: PGP signature

Re: IPv6 works on em0 () but not on em1 () - what's wrong?,IPv6 works on em0 () but not on em1 () - what's wrong?

[Hiroki Sato]

Lev Serebryakov  wrote
  in <58756dde.5000...@freebsd.org>,<58756dde.5000...@freebsd.org>:

le>
le>  I have MoBo (Supermicro X9SCL-F) with two 1G NICs, first one (em0) is
le> based on 82579LM, and second one (em1) is based on 82574L.
le>
le>  When I'm using em0 with simple config:
le>
le> ifconfig_em0="inet 192.168.134.2 netmask 255.255.255.0 mtu 9000"
le> ifconfig_em0_ipv6="inet6 accept_rtadv"
le>
le>  everything works fine - em0 get IPv6 prefix from rtadvd of my router
le> and "tspdump -n -i em0 icmp6" shows some traffic, like router and prefix
le> announcements. So far so good.
le>
le>  I want to use em1 (and don't use em0 at all), because 82579LM has some
le> known bugs according to SuperMicro support and someties hangs whole system.
le>
le>   So, I change config to
le>
le> ifconfig_em1="inet 192.168.134.2 netmask 255.255.255.0 mtu 9000"
le> ifconfig_em1_ipv6="inet6 accept_rtadv"
le>
le>  connect em1 instead of em0 to the switch and reboot. And after that
le> interface (em1) can not get IPv6 prefix, don't get global address (and
le> shows only link-local one)and "tcpdump -n -i em1 icmp6" shows nothing at
le> all! IPv4 works fine, though.
le>
le>  What do I do wrong? Is it known issue of 82574L?
le>
le>  I'm running 10-STABLE r311462.

 What happens by typing the following command?

 % ping6 ff02::1%em1

-- Hiroki


pgpGoE9EXE8Rf.pgp
Description: PGP signature

[Differential] D8904: inet: Fix routing issue by calling if_up()

[hrs (Hiroki Sato)]

hrs added a comment.


  The cause is that the prefix route was removed by in_scrubprefix() in the 
PRC_IFDOWN handler and never reinstalled upon PRC_IFUP because the 
reinstallation  is done only for ifa passed to SIOCAIFADDR.  Just calling 
if_up(ifp) looks too heavy to me because it causes extra pr_ctlinput() calls of 
each protocol, not only inetdomain, in order to recover the routes.  What do 
you think about adding reinstalltion of the prefix routes in the protocol 
specific PRC_IFUP handler instead?

REVISION DETAIL
  https://reviews.freebsd.org/D8904

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, bz, gnn, hiren, glebius, 
rwatson, karels
Cc: hrs, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: How to configure another loopback device?

[Hiroki Sato]

John Dison  wrote
  in <788296467.1718144.1482676705...@mail.yahoo.com>:

jd> Also one more thing which looks strange: if I use
jd> ifconfig_lo1_ipv6="inet6 auto_linklocal", then ipv6 aliases on lo1 are
jd> configured correctly, but there is no link-local address.  If I
jd> exclude this line from rc.conf, then no ipv6 aliases are configured at
jd> all (only ipv4).

 auto_linklocal does not work on the second loopback interface because
 multiple loopback interface support for IPv6 is incomplete at this
 moment.  You need to add fe80::1%lo1 (or similar) manually if you
 want an LLA.

 The ifconfig_IF_ipv6 line determines whether the interface uses IPv6
 or not.  So if you drop it, all of inet6 configuration such as
 ifconfig_IF_aliasN="inet6..." will be ignored.

-- Hiroki


pgpzh8sl08Jr4.pgp
Description: PGP signature

Re: How to configure another loopback device?

[Hiroki Sato]

John Dison  wrote
  in <252311393.1502179.1482604113...@mail.yahoo.com>:

jd> > Does adding ifconfig_lo0="inet 127.0.0.1/8" to /etc/rc.conf work?
jd>
jd> Yes, adding ifconfig_lo0="inet 127.0.0.1/8" helps indeed.
jd>
jd> Interesting is that if I also add ifconfig_lo0_ipv6="inet6 ::1/128"
jd> then ::1/128 will be on lo1.  If I do not add that line, it will be on lo0.
jd>
jd> Looks weird but that workaround work.  Thanks.

 Here are the reasons:

 - 127.0.0.1/8 will be configured on lo0 in rc.d scripts if
   ifconfig_lo0 is missing after processing ifconfig_IF and before
   doing ifconfig_IF_alias*.

 - You cannot manually configure ::1/128 because it is configured by
   the kernel when a loopback interface becomes "up".  If you have an
   ifconfig_lo1 and no ifconfig_lo0, ifconfig_lo1 will be processed
   and make lo1 "up" first.

-- Hiroki


pgpVDwZjpV6ex.pgp
Description: PGP signature

Re: How to configure another loopback device?

[Hiroki Sato]

John Dison via freebsd-net  wrote
  in <1404669989.1370681.1482573468...@mail.yahoo.com>:

fr> > if your first IPs are say 192.168.1.1-2/32 and 2001:550:2:8::1e-f
fr>
fr> > Try without an alias0 for the first set of IPs
fr>
fr> > ifconfig_lo1="inet 192.168.1.1/32"
fr> > ifconfig_lo1_ipv6="inet6 2001:550:2:8::1e prefixlen 126"
fr> > ifconfig_lo1_alias0="inet 192.168.1.2/32"
fr> > ifconfig_lo1_ipv6_alias0="inet6 2001:550:2:8::1f prefixlen 126"
fr>
fr>
fr>
fr> It does not help:  ::1/128 is still on lo1, rather than lo0.

 Does adding ifconfig_lo0="inet 127.0.0.1/8" to /etc/rc.conf work?

-- Hiroki


pgpJHYkMNHrpj.pgp
Description: PGP signature

Re: Trouble with ipv6 routing through interface,Re: Trouble with ipv6 routing through interface

[Hiroki Sato]

"Andrey V. Elsukov"  wrote
  in 
,:

ae> On 16.12.2016 03:24, Anderson Soares Ferreira wrote:
ae> > I have a freebsd 11 box running as my network gateway and I’m having
ae> > some trouble trying to route ipv6 packets through an interface with
ae> > only linklocal address. In short, what I’m doing is:
ae> >
ae> > My freebsd gateway has one global scope address on lo0 interface,
ae> > each other interface has only a link local address fe80::1. Static
ae> > routes for the global scope subnets have been created, Each route was
ae> > created using the command:
ae> >
ae> > # route -6 add -net /64 -interface 
ae> >
ae> > The clients on each subnet have a global scope address and fe80::1 as
ae> > default gateway.
ae> >
ae> > What is happening with this approach is that my gateway can’t reach
ae> > the clients on the subnets. Ping tests from the gateway to the client
ae> > return the error "ping6: sendmsg: No buffer space available”. On the
ae>
ae> Hi,
ae>
ae> this ENOBUFS error is returned from ND6 code. Due to the lack of
ae> prefixes, layer2 doesn't consider that destination address is a
ae> neighbor.
ae>
ae> > other hand, when I try to do a ping from client to gateway, the
ae> > packets from the client are received by the gateway but no response
ae> > is sent. In my tests using a linux gateway with the same approach,
ae> > everything worked fine .
ae>
ae> I'm not sure how this should be fixed.

 A FreeBSD router box must have an IPv6 address on each interface if
 you want to reach the router from a client (and vice versa).
 Currently FreeBSD does not properly support an IPv6 GUA on an
 interface and a route of the GUA's prefix on another interface
 without an GUA at the same time, which is often seen on a dedicated
 router box like Cisco.  This is partly because FreeBSD's NDP and
 routing table assume that an on-link prefix is interface-local, not
 node-local across multiple interfaces.

 A practical workaround is using an LLA (i.e. fe80::1 or something)
 for communication between the router and the clients.

-- Hiroki


pgp8H9B4StVPQ.pgp
Description: PGP signature

Re: And what about ipv6_defaultrouter?

[Hiroki Sato]

Niklaas Baudet von Gersdorff <st...@niklaas.eu> wrote
  in <20160610205025.gg2...@box-hlm-03.niklaas.eu>:

st> Hiroki Sato [2016-06-11 05:37 +0900] :
st>
st> >  Unfortunately there is no documentation other than manual page
st> >  because this is a bit tricky.  rc.conf(5) explains as follows:
st> >
st> > 
st> >ipv6_cpe_wanif
st> >
st> >   (str) If the variable is set to an interface name, the
st> >   ifconfig(8) options ``inet6 -no_radr accept_rtadv'' will be
st> >   added to the specified interface automatically before evalu-
st> >   ating ifconfig__ipv6, and two sysctl(8) variables
st> >   net.inet6.ip6.rfc6204w3 and net.inet6.ip6.no_radr will be set to
st> >   1.
st>
st> So where would I start to look for further explanations on
st> net.inet6.ip6.rfc6204w3 and net.inet6.ip6.no_radr? sysctl.conf(5) and
st> sysctl(8) don't mention anything about them.

 Yes.  "no_radr" can be found in ifconfig(8) manual page since it is
 related to one of the per-IF flags which has the same name.
 "rfc6204w3" is only documented in the result of "sysctl -d
 net.inet6.ip6.rfc6204w3".

-- Hiroki


pgpmWkHxvlkl6.pgp
Description: PGP signature

Re: And what about ipv6_defaultrouter?

[Hiroki Sato]

Niklaas Baudet von Gersdorff <st...@niklaas.eu> wrote
  in <20160610191828.ge2...@box-hlm-03.niklaas.eu>:

st> Hiroki Sato [2016-06-10 22:50 +0900] :
st>
st> >  A router does not accept RAs (more strictly, default route
st> >  information in RA) because it is a sender of RAs.  However, some
st> >  devices such as CPE need to behave like a host for the uplink and a
st> >  router for the LAN.  In that case, an interface on the WAN side has
st> >  to accept RAs and one on the LAN side has to send RAs.
st> >
st> >  On FreeBSD, there is a knob to support it.  Set the following
st> >  variable to rc.conf in addition to your current configuration:
st> >
st> >   ipv6_cpe_wanif="vtnet0"
st>
st> Thanks a lot for pointing that out! I think I read about the variable
st> somewhere but I was not sure what it actually does. Is there some place
st> where I can find more detailed explanation about rc.conf and sysctl
st> settings except man?

 Unfortunately there is no documentation other than manual page
 because this is a bit tricky.  rc.conf(5) explains as follows:


   ipv6_cpe_wanif

  (str) If the variable is set to an interface name, the
  ifconfig(8) options ``inet6 -no_radr accept_rtadv'' will be
  added to the specified interface automatically before evalu-
  ating ifconfig__ipv6, and two sysctl(8) variables
  net.inet6.ip6.rfc6204w3 and net.inet6.ip6.no_radr will be set to
  1.

  This means the specified interface will accept ICMPv6 Router
  Advertisement messages on that link and add the discovered
  routers into the Default Router List.  While the other inter-
  faces can still accept RA messages if the ``inet6 accept_rtadv''
  option is specified, adding routes into the Default Router List
  will be disabled by ``inet6 no_radr'' option by default.  See
  ifconfig(8) for more details.

  Note that ICMPv6 Router Advertisement messages will be accepted
  even when net.inet6.ip6.forwarding is 1 (packet forwarding is
  enabled) when net.inet6.ip6.rfc6204w3 is set to 1.

  Default is ``NO''.


-- Hiroki


pgpQX4eDuK49W.pgp
Description: PGP signature

Re: And what about ipv6_defaultrouter?

[Hiroki Sato]

Niklaas Baudet von Gersdorff  wrote
  in <20160610071254.gc2...@box-hlm-03.niklaas.eu>:

st> Niklaas Baudet von Gersdorff [2016-06-10 08:52 +0200] :
st>
st> > 8<
st> > ifconfig_vtnet0="DHCP"
st> > ifconfig_vtnet0_ipv6="inet6 accept_rtadv"
st> > rtsold_enable="YES"
st> > >8
st> [...]
st> > 8<
st> > ipv6_defaultrouter=""
st> > >8
st>
st> Plus these lines:
st>
st> 8<
st> gateway_enable="YES"
st> ipv6_gateway_enable="YES"
st> >8

 A router does not accept RAs (more strictly, default route
 information in RA) because it is a sender of RAs.  However, some
 devices such as CPE need to behave like a host for the uplink and a
 router for the LAN.  In that case, an interface on the WAN side has
 to accept RAs and one on the LAN side has to send RAs.

 On FreeBSD, there is a knob to support it.  Set the following
 variable to rc.conf in addition to your current configuration:

  ipv6_cpe_wanif="vtnet0"

 This touches some per-IF flags and sysctls.  For more complex
 configurations such as having two or more uplinks you need to set
 them manually, but if you have only one uplink the above variable
 should do the trick.

 And, $rtsold_enable is not required unless you want to get DNS server
 information from RAs.

-- Hiroki


pgpWevMRRiqcu.pgp
Description: PGP signature

Re: DHCPv6 Support in FreeBSD Base

[Hiroki Sato]

David Bright  wrote
  in <6224ec83-3a81-4ce7-83c5-674628f38...@dell.com>:

da> Following up on a conversation I started today at BSDCan
da> 2016/DevSummit.
da> 
da> I’d like to see support for DHCPv6 in the base system. I have made
da> modifications to network.subr and the rc.d init scripts to allow
da> configuring a network interface to use DHCPv6 in a manner very similar
da> to that currently used for DHCPv4. This works assuming that you have a
da> DHCPv6 client. For the purposes of my development I used the ISC
da> client from ports.
da> 
da> These changes were based on 10.0-RELEASE and I am in the process of
da> adapting these changes to 11 so they can be pushed upstream. However,
da> they will be unusable (albeit harmless) in the base system without a
da> client.
da> 
da> * Is there any barrier to updating the dhclient in base to the current
da> * ISC dhclient for both DHCPv4 & DHCPv6?

 dhclient in the base system was diverged from ISC code base long time
 ago.  So "updating it" is not so simple.  I am concerned that by
 replacing it completely we might be going to lose accumulated
 improvements in our code though I do not have a complete list of them
 nor closely look into the current ISC's code.  If no one investigated
 it, it need to be done.

da> * Is there any barrier to replacing the current dhclient-script with
da> * that that accompanies the ISC dhclient?
da> The two scripts are quite different and my DHCPv6 changes currently
da> are based on the ISC dhclient-script.

 Is it difficult for us to think two clients for IPv4 and IPv6
 respectively?  Importing a DHCPv6-only client looks much easier even
 if we use ISC's code.

 And, I personally think a similar way to network.subr for configuring
 DHCPv6 is not enough in practice because DHCPv6 client is typically
 triggered by RA or a combination with IPV6CP in PPP.

 I also like to see a DHCPv6 client in the base system, but I would
 like some more discussion about which implementations we can/want to
 use and typical use cases before it happens.  Probably others have
 their own opinion.

-- Hiroki


pgpg_J6lJVGDW.pgp
Description: PGP signature

[Differential] [Commented On] D1986: Teach lagg(4) to change MTU

[hrs (Hiroki Sato)]

hrs added inline comments.

INLINE COMMENTS
  sys/net/if_lagg.c:753 Please separate a llq loop from a handler for per-port 
configuration. A llq traversal should be required only once in lagg_port_ops() 
if the handlers process a single lagg_llq entry.
  sys/net/if_lagg.c:837 Is this (llq == NULL), not (llq != NULL)?
  sys/net/if_lagg.c:840 Why is cleanup required here?  This removes all of 
tasks not limited to MTU change.
  sys/net/if_lagg.c:861 free(NULL) does nothing.  Checking if NULL or not is 
useless.
  sys/net/if_lagg.c:872 This traversal and freeing an entry after processing it 
should be done in lagg_port_ops().
  sys/net/if_lagg.h:220 Please add "llq_" prefix to the members.
  sys/net/if_lagg.h:221 Is there any reason to have ifr as a pointer?  malloc 
is generally expensive in kernel, and overhead of struct ifreq is acceptable 
for me even if every llq has one.  I feel this complicates the error handling 
at least.

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D1986

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: rpokala, rstone, rpokala-panasas.com
Cc: smh, imp, melifaro, hrs, sbruno, lakshmi.n_msystechnologies.com, emaste, 
ae, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPv6 Address as text (C)

[Hiroki Sato]

Ken Moore  wrote
  in <5668369f.9020...@pcbsd.org>:

ke> Note: Please CC me on replies - I am not subscribed to this list.
ke>
ke> I am having a bit of trouble getting an accurate string representation
ke> of the current IPv6 address for a given device using the C system
ke> libraries and was wondering of somebody with more experience than me
ke> might be able to spot the error...
ke>
ke> Background:
ke> I have been working on a couple simple C/C++/Qt functions to return
ke> printable forms of the current ipv4 and ipv6 addresses assigned to a
ke> particular device, and while the ipv4 function works fine the ipv6
ke> address is consistently wrong and almost always the same string -
ke> making me think it is converting some internal error code to a string
ke> ("::XXe2::ff7f:0" where the "X"s are the only two characters which
ke> ever change).
ke>
ke> The two functions are nearly identical, and I think the error probably
ke> comes from needing to use inet_ntop() for the ipv6 address because
ke> there is no ipv6-compatible version of the inet_ntoa() function.
ke> Do you have any thoughts or ideas about where the error might be
ke> coming from or a better way to read off the ipv6 address as a string?
ke>
ke> Here are the two functions:
ke> Note: "name" is the QString of the device name (wlan0, re0, other...),
ke> and is an internal variable for the overall "NetDevice" class
ke> [code]
ke> //Fetch the IPv4 address and return it as a QString
ke> QString NetDevice::ipAsString(){
ke>struct ifreq ifr;
ke>memset(, 0, sizeof(struct ifreq));
ke>
ke>strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ);
ke>int s = socket(PF_INET, SOCK_DGRAM, 0);
ke>
ke>ioctl(s, SIOCGIFADDR, );
ke>struct in_addr in = ((sockaddr_in *) _addr)->sin_addr;
ke>
ke>return QString( inet_ntoa(in) );
ke> }
ke>
ke> //Fetch the IPv6 address and return it as a QString
ke> QString NetDevice::ipv6AsString(){
ke>struct ifreq ifr;
ke>memset(, 0, sizeof(struct ifreq));
ke>
ke>strncpy(ifr.ifr_name, name.toLocal8Bit(), IFNAMSIZ);
ke>int s = socket(PF_INET6, SOCK_DGRAM, 0);
ke>
ke>ioctl(s, SIOCGIFADDR, );

 Should this be SIOCGIFADDR_IN6 here?  You should check the error
 code.

 Anyway, you should use getnameinfo() for IPv4 and IPv6 instead of
 inet_ntop() and inet_ntoa() for this purpose.  It is an address
 family independent API which accepts struct sockaddr directly like
 this:


  struct sockaddr *sa; /* input */
  char hbuf[NI_MAXHOST];
  int error;

  error = getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), NULL,
  0, NI_NUMERICHOST);
  if (error) {
   errx(1, "getnameinfo: %s", gai_strerror(error));
   /* NOTREACHED */
  }
  printf("host=%s\n", hbuf);


 See getnameinfo(3) for more details.

-- Hiroki


pgph0PDgyQ6n1.pgp
Description: PGP signature

Re: Cannot add an ipv6 route with -interface

[Hiroki Sato]

Alarig Le lay  wrote
  in <20151022230838.ga22...@drscott.swordarmor.fr>:

al> Do you have any idea about this issue? Did I make a mistake or is it a
al> bug?

 Is 2a00:5884::1/64 configured on em1?  An address within
 2a00:5884:8200::/40 is required on em1 in this case.

-- Hiroki


pgplf0mxAUESy.pgp
Description: PGP signature

[Differential] [Commented On] D1986: Teach lagg(4) to change MTU

[hrs (Hiroki Sato)]

hrs added a subscriber: hrs.
hrs added a comment.

It is true that this LOR is driver-specific but calling SIOCSIFMTU after 
acquiring a lock in lagg ioctl is not always safe.  Change of lladdr suffers 
from the same situation and it was solved by using an asynchronous task queue 
to update addresses on each port.  What do you think about piggybacking an MTU 
change to the queue by extending struct lagg_llq to a more generic one which 
makes it possible to handle per-port properties?


REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D1986

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: rpokala-panasas.com, rstone
Cc: hrs, sbruno, lakshmi.n_msystechnologies.com, emaste, ae, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

PF_LOCAL support in getaddrinfo/getnameinfo

[Hiroki Sato]

Hi,

 Is there any problem with adding PF_LOCAL support into getaddrinfo()
 and getnameinfo()?  It was not standardized but can be implemented
 in a straight forward way (attached).

 Some old posts in mailing list archives (not for FreeBSD) said it was
 removed in glibc due to a security issue that getaddrinfo() call with
 PF_UNSPEC could create /tmp/ unintentionally when no
 hostname was resolved.  IIRC KAME's original implementation included
 this functionality, but I am not sure of why it was removed.  Does
 anyone know the reason, or other potential problems?

 In the attached patch PF_LOCAL is not used when getaddrinfo() is
 called with PF_UNSPEC, and only an absolute pathname is accepted.
 This should not have a bad side-effect for the existing programs
 which use them.

-- Hiroki
Index: lib/libc/net/getaddrinfo.c
===
--- lib/libc/net/getaddrinfo.c	(revision 287348)
+++ lib/libc/net/getaddrinfo.c	(working copy)
@@ -137,13 +137,19 @@
 	 offsetof(struct sockaddr_in6, sin6_addr),
 	 in6_addrany, in6_loopback, 1},
 #define	N_INET 1
+#define	N_LOCAL 2
 #else
 #define	N_INET 0
+#define	N_LOCAL 1
 #endif
 	{PF_INET, sizeof(struct in_addr),
 	 sizeof(struct sockaddr_in),
 	 offsetof(struct sockaddr_in, sin_addr),
 	 in_addrany, in_loopback, 0},
+	{PF_LOCAL, sizeof(char[104]),
+	 sizeof(struct sockaddr_un),
+	 offsetof(struct sockaddr_un, sun_path),
+	 NULL, NULL, 0},
 	{0, 0, 0, 0, NULL, NULL, 0},
 };

@@ -158,9 +164,9 @@
 };

 static const struct explore explore[] = {
-#if 0
-	{ PF_LOCAL, ANY, ANY, 0x01 },
-#endif
+	{ PF_LOCAL, SOCK_DGRAM, ANY, 0x04 },
+	{ PF_LOCAL, SOCK_STREAM, ANY, 0x04 },
+	{ PF_LOCAL, SOCK_SEQPACKET, ANY, 0x04 },
 #ifdef INET6
 	{ PF_INET6, SOCK_DGRAM, IPPROTO_UDP, 0x07 },
 	{ PF_INET6, SOCK_STREAM, IPPROTO_TCP, 0x07 },
@@ -408,6 +414,7 @@
 			ERR(EAI_BADFLAGS);
 		switch (hints->ai_family) {
 		case PF_UNSPEC:
+		case PF_LOCAL:
 		case PF_INET:
 #ifdef INET6
 		case PF_INET6:
@@ -1130,6 +1137,9 @@
 	*res = NULL;
 	ai = NULL;

+	if (pai->ai_family == PF_LOCAL)
+		return (0);
+
 	/*
 	 * filter out AFs that are not supported by the kernel
 	 * XXX errno?
@@ -1172,7 +1182,7 @@
 	const struct afd *afd;
 	struct addrinfo *ai;
 	int error;
-	char pton[PTON_MAX];
+	char pton[PTON_MAX], path[PATH_MAX], *p;

 	*res = NULL;
 	ai = NULL;
@@ -1182,6 +1192,15 @@
 		return 0;

 	switch (afd->a_af) {
+	case AF_LOCAL:
+		if (hostname[0] != '/')
+			ERR(EAI_FAIL);
+		if (strlen(hostname) > afd->a_addrlen)
+			ERR(EAI_MEMORY);
+		/* NUL-termination does not need to be guaranteed. */
+		strncpy(path, hostname, afd->a_addrlen);
+		p = [0];
+		break;
 	case AF_INET:
 		/*
 		 * RFC3493 requires getaddrinfo() to accept AF_INET formats
@@ -1192,15 +1211,17 @@
 		 */
 		if (inet_aton(hostname, (struct in_addr *)pton) != 1)
 			return 0;
+		p = pton;
 		break;
 	default:
 		if (inet_pton(afd->a_af, hostname, pton) != 1)
 			return 0;
+		p = pton;
 		break;
 	}

 	if (pai->ai_family == afd->a_af) {
-		GET_AI(ai, afd, pton);
+		GET_AI(ai, afd, p);
 		GET_PORT(ai, servname);
 		if ((pai->ai_flags & AI_CANONNAME)) {
 			/*
@@ -1320,6 +1341,12 @@
 	memset(ai->ai_addr, 0, (size_t)afd->a_socklen);
 	ai->ai_addr->sa_len = afd->a_socklen;
 	ai->ai_addrlen = afd->a_socklen;
+	if (ai->ai_family == PF_LOCAL) {
+		size_t n = strlen(addr);
+
+		ai->ai_addrlen -= afd->a_addrlen - n;
+		ai->ai_addr->sa_len -= afd->a_addrlen - n;
+	}
 	ai->ai_addr->sa_family = ai->ai_family = afd->a_af;
 	p = (char *)(void *)(ai->ai_addr);
 	memcpy(p + afd->a_off, addr, (size_t)afd->a_addrlen);
Index: lib/libc/net/getnameinfo.c
===
--- lib/libc/net/getnameinfo.c	(revision 287404)
+++ lib/libc/net/getnameinfo.c	(working copy)
@@ -49,6 +49,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -72,6 +73,8 @@
 static int	getnameinfo_link(const struct sockaddr *, socklen_t, char *,
 size_t, char *, size_t, int);
 static int	hexname(const u_int8_t *, size_t, char *, size_t);
+static int	getnameinfo_un(const struct sockaddr *, socklen_t, char *,
+size_t, char *, size_t, int);

 int
 getnameinfo(const struct sockaddr *sa, socklen_t salen,
@@ -89,6 +92,9 @@
 	case AF_LINK:
 		return getnameinfo_link(sa, salen, host, hostlen, serv,
 		servlen, flags);
+	case AF_LOCAL:
+		return getnameinfo_un(sa, salen, host, hostlen, serv,
+		servlen, flags);
 	default:
 		return EAI_FAMILY;
 	}
@@ -106,6 +112,8 @@
 #endif
 	{PF_INET, sizeof(struct in_addr), sizeof(struct sockaddr_in),
 		offsetof(struct sockaddr_in, sin_addr)},
+	{PF_LOCAL, sizeof(char[104]), sizeof(struct sockaddr_un),
+		offsetof(struct sockaddr_un, sun_path)},
 	{0, 0, 0},
 };

@@ -469,3 +477,39 @@
 	}
 	return 0;
 }
+
+/*
+ * getnameinfo_un():
+ * Format a pathname of UNIX IPC domain socket.
+ */
+/* ARGSUSED */
+static int
+getnameinfo_un(const struct sockaddr *sa, socklen_t salen,
+char *host, size_t hostlen, char *serv, size_t 

Re: a couple /etc/rc.firewall questions

[Hiroki Sato]

Don Lewis truck...@freebsd.org wrote
  in 201508240052.t7o0qsff002...@gw.catspoiler.org:

tr   A TCP setup packet coming from a host on the internal LAN to the NAPT
tr   router falls into the last deny-all rule because it does not match if
tr   you added out via ${oif} to that rule.  Does the following
tr   additional rule work for you?
tr 
tr   ${fwcmd} add pass tcp from any to any out via ${oif} setup
tr   ${fwcmd} add pass tcp from any to not me in via ${iif} setup
tr
tr That works for now, but won't do the correct thing when I subdivide my
tr internal network because it will allow unrestricted connections between
tr the internal subnets.  What I'd really like is something like:
tr
tr ${fwcmd} add pass tcp from any to not me,${inet} setup
tr
tr but that isn't a valid rule.  I ended up adding a couple of deny
tr rules for me and ${inet} before the wildcard pass allow rule.  I had to
tr make sure that some other more specific rules allowing connections
tr between me and the inside were before the new deny rules.

 Hmmm, I think table would be useful to restrict connections between
 the internal subnets in that case like:

  ## allow TCP setup going to outside network:
  ${fwcmd} add pass tcp from any to any out via ${oif} setup
  ## list of all internal subnets including NAPT router itself:
  ${fwcmd} table 1 flush
  ${fwcmd} table 1 add 192.168.1.1/32   # NAPT router
  ${fwcmd} table 1 add 192.168.3.0/24
  ${fwcmd} table 1 add 192.168.4.0/24
  ...
  ## allow TCP setup from the internal subnets to outside network:
  ${fwcmd} add pass tcp from table(1) to not table(1) in via ${iif} setup
  ##
  ## list of internal subnets which can connect to me:
  ${fwcmd} table 2 flush
  ${fwcmd} table 2 add 192.168.3.0/24
  ...
  ## allow TCP setup from some of the internal subnets to me:
  ${fwcmd} add pass tcp from table(2) to me in via ${iif} setup

-- Hiroki


pgp4oY8s_6E2N.pgp
Description: PGP signature

Re: a couple /etc/rc.firewall questions

[Hiroki Sato]

Don Lewis truck...@freebsd.org wrote
  in 201508222103.t7ml3gax000...@gw.catspoiler.org:

tr The example /etc/rc.firewall has provisions to use either in-kernel NAT
tr or natd for the open and client firewall types, but the simple filewall
tr type only has code for natd.  Is there any reason that in-kernel NAT
tr could not be used with the simple firewall type?

 I think there is no particular reason.  Simple rule was just not updated.

tr After allowing connections to selected TCP ports and then denying all
tr other incoming TCP setup connections from ${oif}, the simple firewall
tr code in /etc/rc.firewall then permits all other TCP setup connections:
tr # Allow setup of any other TCP connection
tr ${fwcmd} add pass tcp from any to any setup
tr This is potentially undesirable since it allows unrestricted TCP
tr connections between me and the inside network.  When I changed this to
tr ${fwcmd} add pass tcp from any to any out via ${oif} setup
tr I was able to open TCP connections from the firewall box to the outside,
tr but NATed connections from inside network to the outside were blocked.
tr If I run ipfw show, it appears that the TCP setup packets are falling
tr through to the final implicit deny all rule, but I don't see any obvious
tr reason.

 A TCP setup packet coming from a host on the internal LAN to the NAPT
 router falls into the last deny-all rule because it does not match if
 you added out via ${oif} to that rule.  Does the following
 additional rule work for you?

 ${fwcmd} add pass tcp from any to any out via ${oif} setup
 ${fwcmd} add pass tcp from any to not me in via ${iif} setup

-- Hiroki


pgpeyZndgsfxW.pgp
Description: PGP signature

Re: IPv6 stacks responds to all node link local multicast NS

[Hiroki Sato]

prabhakar lakhera prabhakar.lakh...@gmail.com wrote
  in CALg+rhVZFc=ve+nzs-hsm+uc54kzwzo6n8qthg9uv+e-e2u...@mail.gmail.com:

pr This probably is more of a compliance issue (or may be not as the NS
pr receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 does
pr not talk about it).
pr
pr The neighbor solicitation message format says this:
pr
pr http://tools.ietf.org/html/rfc4861#page-22
pr
pr
pr   Destination Address
pr  Either the solicited-node multicast address
pr  corresponding to the target address, or the target
pr  address.
pr
pr
pr Is it safe to assume that this is a MUST?
pr If yes, nd6_ns_input right now only checks if the destination is a
pr multicast or not (the check is more strict for DAD NS packets) and
pr therefore allows all node link local multicast address resolution NS
pr packets and process them completely (creates neighbor cache, responds
pr with NA etc).

 What is the problem when accepting NS messages to ff02::1?

-- Hiroki


pgpRaT37EprkC.pgp
Description: PGP signature

Re: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic

[Hiroki Sato]

Hariprasad S haripra...@chelsio.com wrote
  in 26e3f92ec670bd429db5cb319d773c137a8...@nice.asicdesigners.com:

ha HI,
ha
ha Detaching the slave from the lagg interface which has vlan on top of it, 
hits an  panic.
ha Kernel used: FreeBSD HEAD r272051
ha
ha Is anyone aware of this issue?

 Could you try r272547 or later?

-- Hiroki


pgpMkT_l8JOaY.pgp
Description: PGP signature

Re: Configuration for IPv6 over tunnel

[Hiroki Sato]

Dan Langille d...@langille.org wrote
  in 14e3a97c-4fcb-4a2c-b22f-3d0849cec...@langille.org:

da IPv6 Tunnel Endpoints
da Server IPv4 Address:  209.51.x.y
da Server IPv6 Address:  2001:470:xx06:9ea::1/64
da Client IPv4 Address:  96.245.100.201
da Client IPv6 Address:  2001:470:xx06:9ea::2/64
da
da Routed /64:   2001:470:xx07:9ea::/64
da
da My /etc/rc.conf includes
da
da cloned_interfaces=gif0”
da ifconfig_gif0=tunnel 96.245.100.201 209.51.x.y mtu 1480”
da ifconfig_gif0_ipv6=inet6 2001:470:xx06:9ea::2 2001:470:xx06:9ea::1 
prefixlen 128
da ifconfig_em0_ipv6=inet6 2001:470:xx07:9ea:1::1”
da ipv6_defaultrouter=2001:470:xx06:9ea::1
da ipv6_gateway_enable=“YES
da rtadvd_enable=“YES”

 The following line is enough for ifconfig_gif0_ipv6.  A /128
 configuration works but ugly:

  -ifconfig_gif0_ipv6=inet6 2001:470:xx06:9ea::2 2001:470:xx06:9ea::1 
prefixlen 128
  +ifconfig_gif0_ipv6=inet6 2001:470:xx06:9ea::2/64

 Or, you do not need to configure a client side global address in
 subnet of the inter-router link if you use his endpoint as the
 default router.  Reducing the number of global addresses on a box is
 healthy for packet filtering rule management:

  -ifconfig_gif0_ipv6=inet6 2001:470:xx06:9ea::2 2001:470:xx06:9ea::1 
prefixlen 128
  +ifconfig_gif0_ipv6=inet6 auto_linklocal
  -ipv6_defaultrouter=2001:470:xx06:9ea::1
  +ipv6_defaultrouter=-interface gif0

 And if your box works as a router for subnet
 2001:470:xx07:9ea::/64, please add subnet-router anycast address.
 This is mandatory in RFC:

  +ifconfig_em0_ipv6_alias0=inet6 2001:470:xx07:9ea::/64 anycast

 I think HE's endpoint is properly configured.  You can ping6 to
 2001:470:xx06:9ea:: from 2001:470:xx07:9ea:1::1.

-- Hiroki


pgpSRoPOtmS9Z.pgp
Description: PGP signature

Re: Should I be using ipv6_activate_all_interfaces or ip6addrctl_policy=ipv6_prefer

[Hiroki Sato]

John Hay j...@meraka.org.za wrote
  in 20140829101707.ga83...@zibbi.meraka.csir.co.za:

jh On Wed, Aug 27, 2014 at 11:59:25AM +, Bjoern A. Zeeb wrote:
jh 
jh  On 27 Aug 2014, at 06:31 , Jonathan Price free...@jonathanprice.org
jh  wrote:
jh 
jh   On 2014-08-27 01:40, Peter Wemm wrote:
jh   On Tuesday 26 August 2014 10:40:27 free...@jonathanprice.org wrote:
jh   Hello,
jh  
jh   I am configuring a server with IPv4 and IPv6 addresses and have
jh   noticed that
jh   FreeBSD seems to be preferring IPv4, such as when establishing SSH
jh   connections.
jh  
jh   After reading through /etc/defaults/rc.conf, and later
jh   /etc/rc.d/ip6addrctl
jh   I have come to the conclusion that I have two ways to tell FreeBSD to
jh   prefer IPv6:
jh  
jh   1) Add ipv6_activate_all_interfaces to /etc/rc.conf
jh   2) Add ip6addrctl_policy=ipv6_prefer to /etc/rc.conf
jh  
jh ...
jh   However, it does sound like for my purposes it would make more sense
jh   to use ip6addrctl_policy=?ipv6_prefer as that is more explicitly the
jh   feature I want, rather than getting it inadvertently through the other
jh   knob.
jh 
jh  Yes. Definitively.  I am not sure if it has happened but if IPv6
jh  config is configured through rc.conf that setting should be(come)
jh  default.
jh 
jh
jh It does not seem so yet (anymore, it was like that many moons ago). A
jh new

...

jh I think if an IPv6 address is configured on a machine, it should
jh prefer ipv6
jh addresses. That would match what the rest are doing.

 True at this moment.  I have a patch to make it set ipv6_prefer when
 at least one ifconfig_IF_ipv6 is configured.

 Is there any objection to commit this?  I had hesitated to add this
 for a technical reason which was eliminated by adding list_vars().

-- Hiroki
Index: rc.d/ip6addrctl
===
--- rc.d/ip6addrctl	(revision 270577)
+++ rc.d/ip6addrctl	(working copy)
@@ -75,6 +75,8 @@
 		else
 			if checkyesno ipv6_activate_all_interfaces; then
 ip6addrctl_prefer_ipv6
+			elif [ -n $(list_vars ifconfig_\*_ipv6) ]; then
+ip6addrctl_prefer_ipv6
 			else
 ip6addrctl_prefer_ipv4
 			fi


pgpS4NlsKU7Xl.pgp
Description: PGP signature

Re: Routing IPv6 packets towards oneself with routing sockets?

[Hiroki Sato]

Fernando Gont ferna...@gont.com.ar wrote
  in 53e5b71d.2030...@gont.com.ar:

fe   Although your code assumes RTA_GATEWAY eventually returns the
fe   outgoing interface, it is not always true.  RTA_IFP should be used if
fe   you want to look up it instead of looking up gateways until AF_LINK
fe   is obtained.  Certainly RTA_GATEWAY returns AF_LINK and you can check
fe   sdl_index in it, but the index number is not always the same as the
fe   actual outgoing interface (one of the examples is a host route).
fe
fe Just curious: what's the meaning of the AF_LINK I was reading?

 Sorry for the delay.  AF_LINK with (sdl_nlen == sdl_alen == sdl_slen
 == 0) in RTA_GATEWAY was used to create a clone route.  Let's
 consider a situation that there are a IPv4 node (node A) with
 192.168.0.1/24 on its em0 and another node (node B) with
 192.168.0.2/24 on the same link.  If node A is running FreeBSD 8.0 or
 later, an output of netstat -nrf inet on node A will be something
 like this:

  DestinationGatewayFlagsNetif Expire
  192.168.0.0/24 link#2 Uem0
  192.168.0.1link#2 UHS  lo0

 but it was the following on an older FreeBSD (and other
 4.3BSD-derived implementations to which UNPv1 refers):

  DestinationGatewayFlagsRefs  Use  Netif Expire
  192.168.0.0/24 link#2 UC  20  em0
  192.168.0.1xx:xx:xx:xx:xx:xx  UHLW00  lo0
  192.168.0.2yy:yy:yy:yy:yy:yy  UHLW00  em0

 A primary difference is that FreeBSD 8.0 and later do not directly
 have L2 address information in the routing table.  Instead, FreeBSD
 now has L2 address translation table and routing table separately.

 In the old routing table, a host route on the same net
 (e.g. 192.168.0.2) was dynamically created and its MAC address was
 added to the routing table by issuing ARP request.  More
 specifically, when node A attempts to look up a route for
 192.168.0.3, for example, an AF_LINK route with empty L2 address in
 RTA_GATEWAY matches first via the entry 192.168.0.0/24 bacause it is
 the most specific at the moment.  Then the sdl_index in RTA_GATEWAY
 is used for ARP request, and a host route is added eventually.  NDP
 works in the same way for IPv6.

 In the new implementation, a route with empty L2 address means which
 L2 address table (separated in per-interface and per-AF basis) should
 be referred.  A host route is usually used only as loopback route,
 and in its RTA_GATEWAY it just has empty L2 address with if_index
 where the address is configured.

 So, in both cases checking AF_LINK in RTA_GATEWAY is not reliable to
 know the actual outgoing interface.

-- Hiroki


pgplhxSYCsHF3.pgp
Description: PGP signature

Re: Routing IPv6 packets towards oneself with routing sockets?

[Hiroki Sato]

Hi,

Fernando Gont ferna...@gont.com.ar wrote
  in 53e2b586.3080...@gont.com.ar:

fe However, whenever I lookup an entry for fc00:1::1 with routing sockets,
fe the only entry I obtain is fc00:1::/64 (a network route) rather than
fe fc00:1::1/128 (a host route). As a result, I kind of have to figure out
fe that since fc00:1::1 is my own address, I must override whatever I
fe learned via routing sockets, and just send my packets to loopback.
fe
fe I would assume that I must be doing something wrong, since I would
fe expect the host-specific route (i.e. longest-matching route) to be route
fe learned via routing sockets. And that I shouldn't be implementing this
fe is the dst address my own address? hack.
fe
fe Any thoughts?
fe
fe P.S.: I can provide a code snippet if that'd be of any help.

 RTM_GET should return fc00:1::1/128 with ifp == lo0.  Can you show
 the code you are using?

-- Hiroki


pgphwKSJn2xhi.pgp
Description: PGP signature

Re: Routing IPv6 packets towards oneself with routing sockets?

[Hiroki Sato]

Fernando Gont ferna...@gont.com.ar wrote
  in 53e35da7.4020...@gont.com.ar:

fe Yes: https://github.com/fgont/snippets/raw/master/bsd-lookup-simple.c
fe
fe Run it as:
fe bsd-lookup-simple -v IPV6_DEST_ADDR

 Hmm, I tried and it seems it worked as expected.
 ./bsd-lookup-simple -v fc00:1::1 returns RTA_DST with fc00:1::1,
 and -v fc00:1::2 returns RTA_DST with fc00:1::/64 like the following:

 % netstat -nrf inet6 | grep ^fc00
 fc00:1::/64   link#1U   em0
 fc00:1::1 link#1UHS lo0

 % ./bsd-lookup-simple -v fc00:1::1
 DEBUG: 1 SOCKET_RAW query
 DEBUG: Received message
 DEBUG: rtm_type: 4 (4), rtm_pid: 15079 (15079), rtm_seq: 1804289383 
(1804289383)
 DEBUG: RTA_DST was set
 RTA_DST: fc00:1::1
 DEBUG: RTA_GATEWAY was set
 DEBUG: Family: 18, size 54, realsize: 56
 DEBUG: sizeof(AF_LINK): 54, sizeof(AF_INET6): 28
 DEBUG: RTA_GATEWAY: Name: em0, Index: 1
 DEBUG: Quitted loop. onlink_f: 1, queries: 1
 Outgoing interface: em0 (Index: 1)

 % ./bsd-lookup-simple -v fc00:1::2
 DEBUG: 1 SOCKET_RAW query
 DEBUG: Received message
 DEBUG: rtm_type: 4 (4), rtm_pid: 15085 (15085), rtm_seq: 1804289383 
(1804289383)
 DEBUG: RTA_DST was set
 RTA_DST: fc00:1::
 DEBUG: RTA_GATEWAY was set
 DEBUG: Family: 18, size 54, realsize: 56
 DEBUG: sizeof(AF_LINK): 54, sizeof(AF_INET6): 28
 DEBUG: RTA_GATEWAY: Name: em0, Index: 1
 DEBUG: Quitted loop. onlink_f: 1, queries: 1
 Outgoing interface: em0 (Index: 1)

fe However, whenever I lookup an entry for fc00:1::1 with routing sockets,
fe the only entry I obtain is fc00:1::/64 (a network route) rather than
fe fc00:1::1/128 (a host route).

 Does this mean you got RTA_DST with fc00:1::/64 when
 bsd-lookup-simple -v fc00:1::1?  If so, it is very strange.  What
 was returned when you entered route -n get -inet6 fc00:1::1 and route
 -n get -inet6 fc00:1::2 on your box?

 Although your code assumes RTA_GATEWAY eventually returns the
 outgoing interface, it is not always true.  RTA_IFP should be used if
 you want to look up it instead of looking up gateways until AF_LINK
 is obtained.  Certainly RTA_GATEWAY returns AF_LINK and you can check
 sdl_index in it, but the index number is not always the same as the
 actual outgoing interface (one of the examples is a host route).

 A revised source file is attached.  Some nits are also fixed: 1)
 SA_SIZE() on MacOSX is not aligned with sizeof(long) and 2)
 IFACE_LENGTH should be IFNAMSIZ.

-- Hiroki
--- bsd-lookup-simple.c.orig	2014-08-08 04:47:55.0 +0900
+++ bsd-lookup-simple.c	2014-08-08 04:47:55.0 +0900
@@ -38,7 +38,12 @@
 #endif

 #ifndef SA_SIZE
-#if defined (__FreeBSD__) || defined(__NetBSD__) || defined (__OpenBSD__) || defined(__APPLE__)
+#if defined(__APPLE__)
+#define SA_SIZE(sa)\
+(  (!(sa) || ((struct sockaddr *)(sa))-sa_len == 0) ?  \
+   sizeof(long) :   \
+   ((struct sockaddr *)(sa))-sa_len )
+#elif defined (__FreeBSD__) || defined(__NetBSD__) || defined (__OpenBSD__)
 #define SA_SIZE(sa)\
 (  (!(sa) || ((struct sockaddr *)(sa))-sa_len == 0) ?  \
sizeof(long) :   \
@@ -78,7 +83,11 @@
 	#endif
 #endif

+#ifdef IFNAMSIZ
+#define IFACE_LENGTH	IFNAMSIZ
+#else
 #define IFACE_LENGTH	255
+#endif

 unsigned int		print_ipv6_address(char *s, struct in6_addr *);

@@ -104,6 +113,9 @@
 	struct sockaddr_in6	*sin6;
 	struct	sockaddr_dl	*sockpptr;
 	struct sockaddr		*sa;
+	struct sockaddr		*so[RTAX_MAX];
+	char			*cp;
+	int			i;
 	void*end;
 	unsigned char		onlink_f=FALSE, nhaddr_f=FALSE, verbose_f=TRUE, debug_f=FALSE;
 	struct in6_addr		dstaddr, nhaddr;
@@ -139,7 +151,7 @@
 		rtm-rtm_msglen= sizeof(struct rt_msghdr) + sizeof(struct sockaddr_in6);
 		rtm-rtm_version= RTM_VERSION;
 		rtm-rtm_type= RTM_GET;
-		rtm-rtm_addrs= RTA_DST;
+		rtm-rtm_addrs= RTA_DST | RTA_IFP;
 		rtm-rtm_pid= pid= getpid();
 		rtm-rtm_seq= seq= random();

@@ -181,18 +193,27 @@
 		}while( rtm-rtm_type != RTM_GET || rtm-rtm_pid != pid || rtm-rtm_seq != seq);

 		/* The rt_msghdr{} structure is followed by sockaddr structures */
-		sa= (struct sockaddr *) (rtm+1);
+		cp = (char *)(rtm + 1);
+		for (i = 0; i  RTAX_MAX; i++) {
+			if (rtm-rtm_addrs  (1  i)) {
+so[i] = (struct sockaddr *)cp;
+cp += SA_SIZE((struct sockaddr *)cp);
+			} else
+so[i] = NULL;
+		}
+
+		if(so[RTAX_DST] != NULL) {
+			sa = (struct sockaddr *)so[RTAX_DST];

-		if(rtm-rtm_addrs  RTA_DST){
 			if(debug_f){
 puts(DEBUG: RTA_DST was set);
 print_ipv6_address(RTA_DST: , ( ((struct sockaddr_in6 *)sa)-sin6_addr));
 			}
-
-			SA_NEXT(sa);
 		}

-		if(rtm-rtm_addrs  RTA_GATEWAY){
+		if(so[RTAX_GATEWAY] != NULL){
+			sa = (struct sockaddr *)so[RTAX_GATEWAY];
+
 			if(debug_f){
 puts(DEBUG: RTA_GATEWAY was set);
 printf(DEBUG: Family: %d, size %d, realsize: 

Re: IPv6: xxx::x already configured in logs... why?

[Hiroki Sato]

Larry Rosenman l...@lerctr.org wrote
  in 20140612202349.ga65...@thebighonker.lerctr.org:

le I just started using IPv6 behind my (new to me) Cisco 1841.
le
le I see lots of:
le Jun 12 15:16:25 thebighonker kernel: in6_ifadd: 
2001:470:1f0f:3ad:223:7dff:fe9e:6e8a is already configured
le
le in my /var/log/messages.
le
le The rc.conf:
le
le cloned_interfaces=lagg0:sticky 
le create_args_lagg0=laggport bce0 laggport bce1 laggproto loadbalance
le ifconfig_lagg0=192.147.25.65/24
le ifconfig_bce0=up
le ifconfig_bce1=up
le defaultrouter=192.147.25.1
le 
le #IPv6 AutoConf:
le ifconfig_lagg0_ipv6=inet6 accept_rtadv
le rtsold_enable=YES
le 
le hostname=thebighonker.lerctr.org
le ifconfig_lagg0_alias0=inet 192.147.25.45/24
le ifconfig_lagg0_alias1=inet 192.147.25.11/24
le ifconfig_lagg0_alias2=inet 192.147.25.66/24
le sshd_enable=YES
le ntpd_enable=YES
le powerd_enable=YES
le # Set dumpdev to AUTO to enable crash dumps, NO to disable
le dumpdev=AUTO
le zfs_enable=YES
le # 
le
le
le hostid_enable=YES
le
le postgresql_enable=YES
le fah_enable=NO
le fah2_enable=NO
le linux_enable=YES
le smartd_enable=YES
le spamd_enable=YES
le devcpu_enable=YES
le clamav_clamd_enable=YES
le clamav_freshclam_enable=YES
le sendmail_enable=NONE
le exim_enable=YES
le exim_flags=-bd -q5m
le named_enable=YES
le named_program=/usr/local/sbin/named
le bsdstats_enable=YES
le spamd_flags=-c -Q -m 20
le apache22_enable=YES
le syslogd_flags=-n -a 192.147.25.0/24:* -a 209.198.148.248/29:*
le bacula_fd_enable=YES
le sshblock_enable=YES
le dovecot_enable=YES
le monthly_stats_enable=YES
le boinc_client_enable=YES
le microcode_update_enable=YES
le 
le sysctl.conf:
le
le # $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
le #
le #  This file is read when going to multi-user and its contents piped thru
le #  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
le #
le
le # Uncomment this to prevent users from seeing information about processes 
that
le # are being run under another UID.
le #security.bsd.see_other_uids=0
le vm.lowmem_period=0
le vfs.usermount=1
le vfs.zfs.super_owner=1
le kern.elf32.fallback_brand=3
le kern.ipc.shm_allow_removed=1
le net.inet6.ip6.dad_count=0
le
le =
le
le Ideas? (I may be an idiot, so any criticism welcomed).
le
le if you need the 1841's config, I can supply that as well.  It's using a 
Hurricane
le electric Tunnel.

 How frequent were the log message added into /var/log/messages?  And
 when did it start to happen after boot.  Just after lagg0 is
 configured?

-- Hiroki


pgpstc3gU1cwo.pgp
Description: PGP signature

Re: network.subr vlan handling broken

[Hiroki Sato]

John Hay j...@meraka.org.za wrote
  in 20140619103513.ga92...@zibbi.meraka.csir.co.za:

jh Hi Guys,
jh
jh freebsd-rc did not react, so I'm just checking on -net too.
jh
jh I found after upgrading that vlan handling broke. I tried the following:
jh
jh vlans_bce1=6
jh ipv4_addrs_bce1_6=inet 10.239.100.2/24
jh ifconfig_bce1_6_aliases=inet 10.239.100.2/24
jh ifconfig_bce1_6_alias0=inet 10.239.100.2/24
jh
jh I traced it down to ifalias_af_common_handler being called with the
jh mangled interfcace name _if and it then calls ifconfig with it. Here
jh is my fix. Any reason not to commit it? My diff is against 10-stable,
jh but head looks the same.

 Can you try the attached patch?  It seemed broken after list_vars()
 was introduced.  Replacing $_if with $1 also fixes it, but $_if
 should be used for ifname as the other parts do.

jh While looking through the code I saw that ltr is called with different
jh styling. Is there a reason for it? Which is the prefered style?
jh
jh ltr ${_if} ${_punct} '_' _if
jh ltr $_if $_punct _ _if

 I do not think there is a reason.

 I think there is no consensus about the style but I am using {} only
 when boundary between the variable name and the subsequent characters
 can be ambiguous.

-- Hiroki
Index: network.subr
===
--- network.subr	(revision 267636)
+++ network.subr	(working copy)
@@ -1077,7 +1077,7 @@
 ifalias_af_common()
 {
 	local _ret _if _af _action alias ifconfig_args _aliasn _c _tmpargs _iaf
-	local _punct=.-/+
+	local _vif _punct=.-/+

 	_ret=1
 	_aliasn=
@@ -1086,11 +1086,11 @@
 	_action=$3

 	# Normalize $_if before using it in a pattern to list_vars()
-	ltr $_if $_punct _ _if
+	ltr $_if $_punct _ _vif

 	# ifconfig_IF_aliasN which starts with $_af
-	for alias in `list_vars ifconfig_${_if}_alias[0-9]\* |
-		sort_lite -nk1.$((9+${#_if}+7))`
+	for alias in `list_vars ifconfig_${_vif}_alias[0-9]\* |
+		sort_lite -nk1.$((9+${#_vif}+7))`
 	do
 		eval ifconfig_args=\\$$alias\
 		_iaf=
@@ -1118,8 +1118,8 @@
 	# backward compatibility: ipv6_ifconfig_IF_aliasN.
 	case $_af in
 	inet6)
-		for alias in `list_vars ipv6_ifconfig_${_if}_alias[0-9]\* |
-			sort_lite -nk1.$((14+${#_if}+7))`
+		for alias in `list_vars ipv6_ifconfig_${_vif}_alias[0-9]\* |
+			sort_lite -nk1.$((14+${#_vif}+7))`
 		do
 			eval ifconfig_args=\\$$alias\
 			case ${_action}:${ifconfig_args} in
@@ -1129,7 +1129,7 @@
 			alias:*)
 _aliasn=${_aliasn} inet6 ${ifconfig_args}
 warn \$${alias} is obsolete.  \
-Use ifconfig_$1_aliasN instead.
+Use ifconfig_${_vif}_aliasN instead.
 			;;
 			esac
 		done


pgpFShD20w3id.pgp
Description: PGP signature

Re: IPv6: xxx::x already configured in logs... why?

[Hiroki Sato]

Larry Rosenman l...@lerctr.org wrote
  in 20140619140801.ga65...@thebighonker.lerctr.org:

le  le Ideas? (I may be an idiot, so any criticism welcomed).
le  le
le  le if you need the 1841's config, I can supply that as well.  It's using 
a Hurricane
le  le electric Tunnel.
le 
le   How frequent were the log message added into /var/log/messages?  And
le   when did it start to happen after boot.  Just after lagg0 is
le   configured?
le 
le  -- Hiroki
le Looks like:
le
le Jun 12 07:00:01 thebighonker kernel: in6_ifadd: 
2001:470:1f0f:3ad:223:7dff:fe9e:6e8a is already configured

 Thank you.  Three more questions:

 1. output of ifconfig lagg0, ifconfig bce0, and ifconfig bce1.

 2. output of netstat -s -i.

 3. output of ndp -p.

 The cause of the message is that the automatically-configured address
 is not recognized as configured one and FreeBSD IPv6 stack is
 trying to add it every time a Router Advertisement message is
 received.  I am still not sure why it happened, but the above three
 would help for further investigation.

-- Hiroki


pgpZooMa72LJU.pgp
Description: PGP signature

Re: IPv6 Source Address Selection in 9.x

[Hiroki Sato]

Mark Kamichoff p...@prolixium.com wrote
  in 20131014203929.gg25...@prolixium.com:

pr Hi -
pr
pr A colleague of mine recently stumbled upon an IPv6-related quirk in
pr FreeBSD that seems to have appeared in the 9.x series.

...

pr This behavior has been reproduced on 9.2, as well.  It has not been seen
pr on any prior version of FreeBSD that supports IPv6.
pr
pr I took a quick look through /etc/default/rc.conf to see if there were
pr any new variables that might influence source address selection or name
pr resolution, but did not see anything relevant.

 Try ip6addrctl_policy=ipv6_prefer in rc.conf.

-- Hiroki


pgpNHCHCJ1yH4.pgp
Description: PGP signature

Re: IPv6 Source Address Selection in 9.x

[Hiroki Sato]

Mark Kamichoff p...@prolixium.com wrote
  in 20131014205824.gi25...@prolixium.com:

pr On Tue, Oct 15, 2013 at 05:45:15AM +0900, Hiroki Sato wrote:
pr  Try ip6addrctl_policy=ipv6_prefer in rc.conf.
pr
pr Excellent.  Thank you.  I glanced right over that in
pr /etc/default/rc.conf.  I just added the above line to /etc/rc.conf and
pr ran /etc/rc.d/ip6addrctl start prefer_ipv6.  Now, it works as expected:
pr
pr (dax:16:47)% telnet he.net. 80
pr Trying 2001:470:0:76::2...
pr Connected to he.net.
pr Escape character is '^]'.
pr ^]^D
pr telnet Connection closed.
pr
pr It's my understanding that by leaving ip6addrctl_policy as AUTO will
pr only prefer IPv6 if ipv6_enable_all_interfaces is set to YES, which it
pr is in my /etc/rc.conf.  However, it appears that this never resulted in
pr ip6addrctl_prefer_ipv6 being called from /etc/rc.d/ip6addrctl.  Maybe
pr I'm reading this wrong ...

 It is ipv6_activate_all_interfaces, not ipv6_enable_all_interfaces.
 If YES, AUTO (the default value) will set it as ipv6_prefer
 automatically.

-- Hiroki


pgpn5fuqQ9Xoh.pgp
Description: PGP signature

Re: Why default route is not installed last?

[Hiroki Sato]

Xin Li delp...@delphij.net wrote
  in 521ba31c.5000...@delphij.net:

de  That has always been specifically not supported. default route
de  needs to be directly attached. in fact the routing tables only ever
de  deliver the 'next hop'
de
de Well, depends on whether the 'next hop' is an IP or an interface.  For
de instance one can have a valid configuration that they have a static
de route of:
de
de 2607:5300:::ff:ff:ff:ff -prefixlen 128 -interface em0
de
de Then have 2607:5300:::ff:ff:ff:ff as default router.
de
de This configuration is not possible with the current rc.d startup order.

 Ah, I see.  I personally do not like this kind of configurations but
 it should be supported as a dirty workaround.  The patch is correct,
 so please go ahead with it.

-- Hiroki


pgpQHqTmEhW6T.pgp
Description: PGP signature

Re: Why default route is not installed last?

[Hiroki Sato]

Xin Li delp...@delphij.net wrote
  in 521670ff.6080...@delphij.net:

de -BEGIN PGP SIGNED MESSAGE-
de Hash: SHA512
de
de Hi,
de
de I've noticed that we do not install default route last (after other
de static routes).  I think we should probably install it last, since the
de administrator may legitimately configure a static route (e.g. this
de IPv6 address goes to this interface) that is required by the default
de route.

 Do you have an example?  I could imagine some theoretically but
 personally think that the default route which depends on a static
 route is one which should be avoided.

-- Hiroki


pgpocjbFw6a2a.pgp
Description: PGP signature

Re: CFR: FIB handling improvements

[Hiroki Sato]

Will Andrews w...@firepipe.net wrote
  in cadbaqmi6c7v8ojry8uviri9tk18n8_radrp+ujvcmen9guw...@mail.gmail.com:

wi Please review: http://people.freebsd.org/~will/fix-fib-issues.1.diff
wi
wi This patch includes fixes for several issues relating to FIBs:
wi
wi * Use of dhclient with non-zero FIBs.  With this patch, it is possible
wi to use DHCP on a specific interface with a non-zero FIB and have it
wi work correctly with this rc.conf snippet:
wi
wi ifconfig_em1=SYNCDHCP
wi dhclient_fib_em1=1

 I think the target FIB should be handled by dhclient, not in the rc.d
 scripts.  More specifically, dhclient should call SIOCGIFFIB ioctl to
 obtain ifp-if_fib and use it if defined.  It allows the following
 configuration which is much simpler and reliable:

 ifconfig_em1=fib 1 SYNCDHCP

wi * Always add loopback routes for non-zero FIBs, for both IPv4 and
wi IPv6.  Arguably, this could be a policy issue, but it is currently
wi less-than-trivial to specify (in rc.conf) that a route needs to be
wi applied to every FIB.

 I am not sure why this is needed.  Are the loopback host routes
 installed into all of the FIBs automatically when lo0 is initialized?

 Even if it is required, get_fibmod() is not necessary.  The following
 should work:

 # route add -inet 127.0.0.1/8 -iface lo0 -fib all

wi * Having two or more FIBs whose interfaces share the same prefix and
wi netmask.  This involves adding fibnum arguments to ifa_ifwithnet() and
wi ifa_ifwithdstaddr(), and checking it within.
wi
wi * Setting the FIB on a network interface.  rtinit1() looks it up via
wi the current process context, so we must be calling setfib(2) from
wi within ifconfig.
wi
wi * Creating  deleting loopback routes now works correctly for
wi non-default FIBs, by using the interface's FIB instead of always 0.
wi
wi Commits would be made on each of these issues separately, but since
wi they are all related, I thought it would be easier for others to
wi evaluate them with context.

 The other changes look reasonable to me (but not tested yet).

-- Hiroki


pgpEfM3RLMiHJ.pgp
Description: PGP signature

Re: bce(4) panics, 9.2rc1 [redux]

[Hiroki Sato]

[Added yougari@ and davidch@ to the To:/Cc: list]

 I confirmed that my issue reported on -current@ is due to the bxe(4)
 driver (BCM57711).  If it is disabled, shutdown works fine without
 NMI.

 Also, I received several reports about the same box that NMI occurred
 even on bge(4) (BCM5717) driver when probing during power-cycle test.
 The probability was about once per 30 power-cycles.  Once it
 occurred, an AC on/off cycle was required (resetting a system
 reproduced the NMI in the same timing).

Sean Bruno sean_br...@yahoo.com wrote
  in 1375208841.1496.3.camel@localhost:

se
se
se  http://svnweb.freebsd.org/base?view=revisionrevision=236216
se 
se 
se
se
se Ok, confirmed after ~50 reboots.
se
se There is a timing problem in this revision that I don't fully
se understand.  Adding printf's inside bce_reset() will cause the existing
se code to succeed, and sometimes the existing code in this revision will
se work (about 10% of the time).
se
se In the failure mode, the network interface, bce0, will not come up into
se service *without* and network restart, after which it works fine.
se
se I suspect that we are missing a DELAY or UDELAY somewhere in the
se restoral of the emac_status settings that needs to be implemented.
se
se Sean
se
se p.s. sorry for the late report as the commit is well over a year old.


pgpZQYE1ILK56.pgp
Description: PGP signature

Re: bce(4) panics, 9.2rc1 [redux]

[Hiroki Sato]

Yonghyeon PYUN pyu...@gmail.com wrote
  in 20130731074341.gc1...@michelle.cdnetworks.com:

py On Wed, Jul 31, 2013 at 03:54:06PM +0900, Hiroki Sato wrote:
py  [Added yougari@ and davidch@ to the To:/Cc: list]
py 
py   I confirmed that my issue reported on -current@ is due to the bxe(4)
py   driver (BCM57711).  If it is disabled, shutdown works fine without
py   NMI.
py 
py   Also, I received several reports about the same box that NMI occurred
py   even on bge(4) (BCM5717) driver when probing during power-cycle test.
py   The probability was about once per 30 power-cycles.  Once it
py   occurred, an AC on/off cycle was required (resetting a system
py   reproduced the NMI in the same timing).
py 
py
py Hmm, Hiroki, could you add bge_reset()/bge_chipinit() after
py bge_stop() in bge_shutdown() and let me know whether that change
py makes any difference?

 Thank you.  I will give it a try.  The test will probably take some
 time since it occurs only once in 30-50 power-cycles, though.

 On bxe(4) it is 100% reproducible, FYI.

-- Hiroki


pgp0qxbpk6Qs5.pgp
Description: PGP signature

Re: IPv6 NDP, static subnet entries

[Hiroki Sato]

Georg Bege ther...@ninth-art.de wrote
  in 1374226382.2820.1.camel@atwork:

th Hello Hiroki
th
th Well I've got the subnet 2001:41d0:2:83a5::/64 and would like to route a
th portion of this - let's say 2001:41d0:2:83a5:100::/124 via an gif
th interface.
th The ISP is OVH, I heard it's known for broken setups like bridging.
th What kind of other information would you need?

 Routing to a subnet of 2001:41d0:2:83a5::/64 needs to add an routing
 entry to the router which handles incoming packets in
 2001:41d0:2:83a5::/64.  As far as I can tell your router on OVH's
 side uses the address 2001:41d0:2:83ff:ff:ff:ff:ff and this router is
 not under your control---is it true?  If so, it is difficult to
 create a subnet.

-- Hiroki


pgp7vWJW_DD4X.pgp
Description: PGP signature

Re: IPv6 NDP, static subnet entries

[Hiroki Sato]

Georg Bege ther...@ninth-art.de wrote
  in 1374064573.525.2.camel@atwork:

th Hello FreeBSD users
th
th Im in need of proxying an NDP entry,
th due my bad provider using IPv6 bridging.
th My entire subnet is not routed correctly, however I managed to get it
th working with ndp -s IPv6 local ether proxy - sadly this doesnt work
th for an whole subnet but for a single IP.
th
th I need exacly this for an whole subnet, is it possible?

 More specifics about your network and what ISP provided are needed to
 answer to this...

-- Hiroki


pgpPx_BNEcwmx.pgp
Description: PGP signature

Re: Duplicate Address Detection misfire?

[Hiroki Sato]

Zaphod Beeblebrox zbee...@gmail.com wrote
  in CACpH0McSM7HDeJcQ1pLcXuEZ96n=15ymcap4yhezghbbyeg...@mail.gmail.com:

zb I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
zb bridged type of networking with VMWare.  It gets it's IPv4 address from
zb DHCP (successfully) and then fails to initialize IPv6.  The relevant
zb rc.conf is:
zb
zb ipv6_activate_all_interfaces=YES
zb ifconfig_em0_ipv6=inet6 accept_rtadv
zb ip6addrctl_verbose=YES
zb
zb The console output says:
zb
zb em0: DAD detected duplicate IPv6 address fe80:2::20c:29ff:fe0a:3989: NS
zb in/out=2/1, NA in=0
zb em0: DAD complete for fe80:2::20c:29ff:fe0a:3989 - duplicate found
zb em0: manual intervention required
zb em0: possible hardware address duplication deteted, disable IPv6
zb
zb And subsequently, em0's nd6 has IFDISABLED in it.
zb
zb With wireshark, I see two ICMPv6 neighbor solicitations that are identical
zb --- is this the problem?
zb
zb How do I fix this?

 Does your host environment have the same address on the bridged
 interface?

-- Hiroki


pgpZ6CRgYpGOd.pgp
Description: PGP signature

Re: Making net.inet6.ip6.v6only=0 default

[Hiroki Sato]

JINMEI Tatuya / 神明達哉 jin...@isc.org wrote
  in m2ppv5k988.wl%jin...@isc.org:

ji  So I guess the question is: what do we do? It looks like we're in
ji  violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section
ji  2.10.20*.
ji
ji ...aside from what FreeBSD should do for ip6.v6only, I personally
ji believe that realistically this issue should be resolved at the
ji application side, i.e., explicitly set the IPV6_V6ONLY socket option
ji to 1 and use both AF_INET (for IPv4) and AF_INET6 (for IPv6, and only
ji for IPv6) sockets.  As far as I know this is the most portable
ji behavior.  Regarding the rwhois case, I'd first suggest updating the
ji patch with this socket option setting.  Hopefully it can be accepted
ji by the upstream because it's most portable.  If they still reject it
ji because it's against the standard (and even if it's less portable in
ji reality), my next suggestion is to explicitly set the IPV6_V6ONLY
ji socket option to 0.  This setting is redundant in the sense of
ji standard purity, but hopefully less controversial for those preferring
ji the standard compliance as it only requires a small change and will
ji make it still more portable.
ji
ji Going back to the question of what FreeBSD should do for ip6.v6only:
ji Personally, I'd still suggest keeping the same default because I agree
ji this behavior is sufficiently safer (as noted above) *and* there'll
ji be portability issues anyway (OSes using the different default
ji religiously will never change it).  But I also understand the
ji argument that standard compliance is more important than debatable
ji safety.  In either case, it would help if we provide detailed
ji discussion for the description of this sysctl knob.

 Agreed.  Honestly my patch was not intended for upstream because it
 was too aggressive (for them).  Explicitly dropping IPV6_V6ONLY may
 be acceptable.

 I am also for keeping the sysctl knob.  Except for Java, most of
 applications which run on FreeBSD have survived with it.  In addition
 to the points already mentioned, I do not like s/AF_INET/AF_INET6/
 replacement like rwhoisd does, and I believe this kind of network
 programs should be implemented in an AF-independent fashion, not
 depending on AF_INET6, and handle each available AF separately.  It
 prevents issues in corner cases.

-- Hiroki


pgph5926RY4jB.pgp
Description: PGP signature

Re: Looking for a bgp listener that works with RADIX_MPATH / EQMP that's in HEAD

[Hiroki Sato]

Peter Wemm pe...@wemm.org wrote
  in cage5ycptjkoezdckgu6qc_fvmnrbpnp4bizp0fyi5oyxk1d...@mail.gmail.com:

pe I'm looking for pointers to something that can listen to bgp default
pe route announcements from two outbound gateways and set a RADIX_MPATH
pe compatible default route based on whether one or both are alive.
pe
pe openbgpd from ports is extremely incompatible with RADIX_MPATH on 10.
pe You *have* to turn off fib (kernel routing table) updates or it will
pe destroy your machine when it runs out of physical memory for duplicate
pe routes.
pe
pe I know I can do an evil hack and poll the 'bgp show ...' output and
pe manually update the default route but that means updates are delayed
pe to the poll interval.  I'm hoping there is a more elegant solution
pe that already works and is immediately responsive to a change in bgp
pe state.
pe
pe The caveat is it *must* run on 10.x, with RADIX_MPATH enabled.  I'd
pe gladly run openbgpd if it actually worked.  openbgpd has some
pe awareness of mpath so it might be fixable but openbsd's multipath is
pe different to ours.
pe
pe Ideas?

 Unfortunately openbgpd does not work well with RADIX_MPATH yet.  As
 you pointed out, it is due to difference of multiple routes support
 between FreeBSD and OpenBSD.  I think FIB handling can be improved,
 but needs some more investigation for that.

 I think Quagga and BIRD can work with injecting ECMP routes into
 RADIX_MPATH-enabled FIB.

-- Hiroki


pgp6rIakTvoQZ.pgp
Description: PGP signature

RFC: if_bridge(4) ND6_IFF_AUTO_LINKLOCAL

[Hiroki Sato]

Hi,

 I would like your comments about the attached patch.  This allows
 IFT_BRIDGE interfaces to accept ND6_IFF_AUTO_LINKLOCAL and
 autoconfiguration of a link-local address with EUI-64 interface id.

 One thing I am concerned about is the case when the parent interface
 and the member interfaces have own link-local scope zones at the same
 time since it leads to scope violation.  More specifically, It does
 not occur only in the following cases:

 1. bridge0 has an IPv6 address and the members do not.

 2. bridge0 does not have an IPv6 address and only one of the members
does.

 I think we can allow only them and forbid the other cases like both
 bridge0 and the members have IPv6 addresses at the same time.  The
 attached patch implements this restriction by removing overlapped
 link-local scope zones.  I believe the restriction does not matter in
 practical configurations, but please correct me if I am missing
 something.

-- Hiroki
- Allow ND6_IFF_AUTO_LINKLOCAL for IFT_BRIDGE.  An interface with IFT_BRIDGE
  is initialized with !ND6_IFF_AUTO_LINKLOCAL  !ND6_IFF_ACCEPT_RTADV
  regardless of net.inet6.ip6.accept_rtadv and net.inet6.ip6.auto_linklocal.
  To configure an autoconfigured link-local address (RFC 4862), the
  following rc.conf(5) configuration can be used:

  ifconfig_bridge0_ipv6=inet6 auto_linklocal

- if_bridge(4) now removes IPv6 addresses on a member interface to be
  added when the parent interface or one of the existing member
  interfaces has an IPv6 address.  if_bridge(4) merges each link-local
  scope zone which the member interfaces form respectively, so it causes
  address scope violation.  Removal of the IPv6 addresses prevents it.

- if_lagg(4) now removes IPv6 addresses on a member interfaces
  unconditionally.

MFC after:	1 week


Index: sys/netinet6/in6.c
===
--- sys/netinet6/in6.c	(revision 252096)
+++ sys/netinet6/in6.c	(working copy)
@@ -1987,6 +1987,32 @@ in6ifa_ifpwithaddr(struct ifnet *ifp, struct in6_a
 }

 /*
+ * Find a link-local scoped address on ifp and return it if any.
+ */
+struct in6_ifaddr *
+in6ifa_llaonifp(struct ifnet *ifp)
+{
+	struct sockaddr_in6 *sin6;
+	struct ifaddr *ifa;
+
+	if (ND_IFINFO(ifp)-flags  ND6_IFF_IFDISABLED)
+		return (NULL);
+	if_addr_rlock(ifp);
+	TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link) {
+		if (ifa-ifa_addr-sa_family != AF_INET6)
+			continue;
+		sin6 = (struct sockaddr_in6 *)ifa-ifa_addr;
+		if (IN6_IS_SCOPE_LINKLOCAL(sin6-sin6_addr) ||
+		IN6_IS_ADDR_MC_INTFACELOCAL(sin6-sin6_addr) ||
+		IN6_IS_ADDR_MC_NODELOCAL(sin6-sin6_addr))
+			break;
+	}
+	if_addr_runlock(ifp);
+
+	return ((struct in6_ifaddr *)ifa);
+}
+
+/*
  * Convert IP6 address to printable (loggable) representation. Caller
  * has to make sure that ip6buf is at least INET6_ADDRSTRLEN long.
  */
Index: sys/netinet6/in6_var.h
===
--- sys/netinet6/in6_var.h	(revision 252096)
+++ sys/netinet6/in6_var.h	(working copy)
@@ -800,6 +800,7 @@ void	in6_setmaxmtu(void);
 int	in6_if2idlen(struct ifnet *);
 struct in6_ifaddr *in6ifa_ifpforlinklocal(struct ifnet *, int);
 struct in6_ifaddr *in6ifa_ifpwithaddr(struct ifnet *, struct in6_addr *);
+struct in6_ifaddr *in6ifa_llaonifp(struct ifnet *);
 char	*ip6_sprintf(char *, const struct in6_addr *);
 int	in6_addr2zoneid(struct ifnet *, struct in6_addr *, u_int32_t *);
 int	in6_matchlen(struct in6_addr *, struct in6_addr *);
Index: sys/netinet6/in6_ifattach.c
===
--- sys/netinet6/in6_ifattach.c	(revision 252096)
+++ sys/netinet6/in6_ifattach.c	(working copy)
@@ -266,6 +266,7 @@ found:

 	/* get EUI64 */
 	switch (ifp-if_type) {
+	case IFT_BRIDGE:
 	case IFT_ETHER:
 	case IFT_L2VLAN:
 	case IFT_FDDI:
@@ -777,8 +778,7 @@ in6_ifattach(struct ifnet *ifp, struct ifnet *alti
 	/*
 	 * assign a link-local address, if there's none.
 	 */
-	if (ifp-if_type != IFT_BRIDGE 
-	!(ND_IFINFO(ifp)-flags  ND6_IFF_IFDISABLED) 
+	if (!(ND_IFINFO(ifp)-flags  ND6_IFF_IFDISABLED) 
 	ND_IFINFO(ifp)-flags  ND6_IFF_AUTO_LINKLOCAL) {
 		int error;

Index: sys/netinet6/nd6.c
===
--- sys/netinet6/nd6.c	(revision 252096)
+++ sys/netinet6/nd6.c	(working copy)
@@ -176,13 +176,25 @@ nd6_ifattach(struct ifnet *ifp)

 	nd-flags = ND6_IFF_PERFORMNUD;

-	/* A loopback interface always has ND6_IFF_AUTO_LINKLOCAL. */
-	if (V_ip6_auto_linklocal || (ifp-if_flags  IFF_LOOPBACK))
+	/* A loopback interface always has ND6_IFF_AUTO_LINKLOCAL.
+	 * XXXHRS: Clear ND6_IFF_AUTO_LINKLOCAL on an IFT_BRIDGE interface by
+	 * default regardless of the V_ip6_auto_linklocal configuration to
+	 * give a reasonable default behavior.
+	 */
+	if ((V_ip6_auto_linklocal  ifp-if_type != IFT_BRIDGE) ||
+	(ifp-if_flags  IFF_LOOPBACK))
 		nd-flags |= ND6_IFF_AUTO_LINKLOCAL;
-
-	/* A loopback interface does not need to 

Re: [PATCH] stf(4) 6rd implementation

[Hiroki Sato]

Ermal Luçi e...@freebsd.org wrote
  in capbzqg3rn-weh-cka-qxf+-3lyjm9s6nzrskz5cxng5lzty...@mail.gmail.com:

er Hello,
er 
er at location [1] can be found a patch for making stf(4) understand 6rd.
er It supports variable masks for the ipv4 network as well.
er 
er The patch has been tested on pfSense.
er It adds to new option to ifconfig for defining the 6rd border router at ISP.
er 
er ifconfig $stf stfv4net $ipv4network/$mask
er ifconfig $stf stfv4br $6rdv4gwip
er 
er 
er Any reasons for not pushing this change into FreeBSD?

 I am feeling guilty about not committing the original patch and RFC
 5969 part for a long time.  I still have uncommitted code for them
 (similar but some reported security and performance issues and corner
 cases addressed), I hope if you do not mind my working on it.  I will
 finish it this month.

-- Hiroki


pgpBncizU4epm.pgp
Description: PGP signature

Re: gre and MONITOR

[Hiroki Sato]

Chip Marshall c...@2bithacker.net wrote
  in 20130508155446.gb95...@2bithacker.net:

ch It appears the MONITOR flag doesn't work on gre interfaces.
ch
ch I have a GRE tunnel set up between a FreeBSD 8.2-RELEASE box and a
ch Juniper router.
ch
ch Config on the FreeBSD end:
ch
ch gre0: flags=4b051UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST,MONITOR 
metric 0 mtu 1476
ch tunnel inet 10.162.163.133 -- 10.162.163.131
ch inet6 fe80::20c:29ff:fe9f:de64%gre0 prefixlen 64 scopeid 0x6
ch inet 10.200.0.2 -- 10.200.0.1 netmask 0xfffc
ch nd6 options=3PERFORMNUD,ACCEPT_RTADV
ch
ch Config on the Juniper end:
ch
ch tunnel {
ch source 10.162.163.131;
ch destination 10.162.163.133;
ch }
ch family inet {
ch address 10.200.0.1/30;
ch }
ch
ch And from the Juniper, I am able to ping the 10.200.0.2 IP on the
ch FreeBSD end of the GRE tunnel. As I understand it, this shouldn't
ch happen with the MONITOR flag there, right?

 The attached patch should fix this.  Can you try it?

-- Hiroki
Index: sys/net/if_gre.c
===
--- sys/net/if_gre.c	(revision 250243)
+++ sys/net/if_gre.c	(working copy)
@@ -341,6 +341,12 @@
 	if (bpf_peers_present(ifp-if_bpf))
 		bpf_mtap2(ifp-if_bpf, af, sizeof(af), m);

+	if ((ifp-if_flags  IFF_MONITOR) != 0) {
+		m_freem(m);
+		error = ENETDOWN;
+		goto end;
+	}
+
 	m-m_flags = ~(M_BCAST|M_MCAST);

 	if (sc-g_proto == IPPROTO_MOBILE) {
Index: sys/netinet/ip_gre.c
===
--- sys/netinet/ip_gre.c	(revision 250243)
+++ sys/netinet/ip_gre.c	(working copy)
@@ -205,6 +205,11 @@
 		bpf_mtap2(GRE2IFP(sc)-if_bpf, af, sizeof(af), m);
 	}

+	if ((GRE2IFP(sc)-if_flags  IFF_MONITOR) != 0) {
+		m_freem(m);
+		return(NULL);
+	}
+
 	m-m_pkthdr.rcvif = GRE2IFP(sc);

 	netisr_queue(isr, m);
@@ -287,6 +292,11 @@
 		bpf_mtap2(GRE2IFP(sc)-if_bpf, af, sizeof(af), m);
 	}

+	if ((GRE2IFP(sc)-if_flags  IFF_MONITOR) != 0) {
+		m_freem(m);
+		return;
+	}
+
 	m-m_pkthdr.rcvif = GRE2IFP(sc);

 	netisr_queue(NETISR_IP, m);


pgpS5aZdWhiT5.pgp
Description: PGP signature

Re: IPv6 configuration missunderstanding

[Hiroki Sato]

Florent Peterschmitt flor...@peterschmitt.fr wrote
  in 518a6d5c.3030...@peterschmitt.fr:

fl Hi,
fl
fl I want to configure IPv6 in FreeBSD 9.1-RELEASE like this :
fl
fl ipv6_enable=yes
fl ipv6_activate_all_interfaces=yes
fl ifconfig_em0_ipv6=inet6 2001:41D0:8:B81f:: prefixlen 64
fl -interface em0
fl ipv6_defaultrouter=2001:41D0:8:B8ff:ff:ff:ff:ff

 Why the default router is not in 2001:41d0:8:b81f::/64?

fl But at boot I have :
fl
fl defaultfe80::264:40ff:fe3a:fac0%em0  UG  em0

 I guess this is provided by the router via Router Advertisement
 messages.

fl And if ipv6_enable=yes is not here (although it's depreciated), no IPv6
fl at all.

 Please remove ipv6_enable=yes and ipv6_activate_all_interfaces=yes
 unless you understand you really need them.

 I think only the following line is sufficient for your environment:

 ifconfig_em0_ipv6=inet6 2001:41d0:8:b81f::1 prefixlen 64 accept_rtadv

-- Hiroki


pgp4cpX9jc1Qp.pgp
Description: PGP signature

Re: IPv6 configuration missunderstanding

[Hiroki Sato]

Florent Peterschmitt flor...@peterschmitt.fr wrote
  in 518bfbf6.4040...@peterschmitt.fr:

fl Le 09/05/2013 21:19, Hiroki Sato a écrit :
fl  Florent Peterschmitt flor...@peterschmitt.fr wrote
flin 518a6d5c.3030...@peterschmitt.fr:
fl  
fl  fl Hi,
fl  fl
fl  fl I want to configure IPv6 in FreeBSD 9.1-RELEASE like this :
fl  fl
fl  fl ipv6_enable=yes
fl  fl ipv6_activate_all_interfaces=yes
fl  fl ifconfig_em0_ipv6=inet6 2001:41D0:8:B81f:: prefixlen 64
fl  fl -interface em0
fl  fl ipv6_defaultrouter=2001:41D0:8:B8ff:ff:ff:ff:ff
fl  
fl   Why the default router is not in 2001:41d0:8:b81f::/64?
fl  
fl  fl But at boot I have :
fl  fl
fl  fl defaultfe80::264:40ff:fe3a:fac0%em0  UG  em0
fl  
fl   I guess this is provided by the router via Router Advertisement
fl   messages.
fl  
fl  fl And if ipv6_enable=yes is not here (although it's depreciated), no 
IPv6
fl  fl at all.
fl  
fl   Please remove ipv6_enable=yes and ipv6_activate_all_interfaces=yes
fl   unless you understand you really need them.
fl  
fl   I think only the following line is sufficient for your environment:
fl  
fl   ifconfig_em0_ipv6=inet6 2001:41d0:8:b81f::1 prefixlen 64 accept_rtadv
fl  
fl  -- Hiroki
fl  
fl I found how to configure it:
fl 
fl ip6addrctl_policy=ipv6_prefer
fl ipv6_activate_all_interfaces=yes
fl ifconfig_em0_ipv6=inet6 2001:41d0:8:b81f::1 prefixlen 64
fl ipv6_defaultrouter=2001:41d0:8:b8ff:ff:ff:ff:ff
fl 
fl Router advertisement is disabled at OVH and the gateway is the given
fl one. Well, everything is good now ;)

 So, why do you need ipv6_activate_all_interfaces=yes?

 And, using an address on the different subnet as the default router
 is wrong even if it looks working.

-- Hiroki


pgpik_BRkswCu.pgp
Description: PGP signature

Re: LOR in rtsock/ifnet

[Hiroki Sato]

Mateusz Guzik mjgu...@gmail.com wrote
  in 20121201133609.ga5...@dft-labs.eu:

mj On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote:
mj  Mateusz: are you sure it's that commit?
mj 
mj
mj Yes, I double-checked right now.
mj
mj  I still get this in -HEAD:
mj 
mj
mj Maybe I expressed myself incorrectly, I meant to say that LOR started
mj showing up since r243187.
mj
mj The code is still in head and no fixes were comitted (that I know of at
mj least), so I guess that you seeing this LOR on head is expected. :)

 Thanks for the info.  I am investigating this now.

-- Hiroki


pgpbf7tsScuDU.pgp
Description: PGP signature

Re: LOR in rtsock/ifnet

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20121201.225004.2232262673795057435@allbsd.org:

hr Mateusz Guzik mjgu...@gmail.com wrote
hr   in 20121201133609.ga5...@dft-labs.eu:
hr
hr mj On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote:
hr mj  Mateusz: are you sure it's that commit?
hr mj 
hr mj
hr mj Yes, I double-checked right now.
hr mj
hr mj  I still get this in -HEAD:
hr mj 
hr mj
hr mj Maybe I expressed myself incorrectly, I meant to say that LOR started
hr mj showing up since r243187.
hr mj
hr mj The code is still in head and no fixes were comitted (that I know of at
hr mj least), so I guess that you seeing this LOR on head is expected. :)
hr
hr  Thanks for the info.  I am investigating this now.

 Can anyone test the attached patch and let me know if the LOR
 persists or not?

-- Hiroki
Index: sys/net/rtsock.c
===
--- sys/net/rtsock.c	(revision 243465)
+++ sys/net/rtsock.c	(working copy)
@@ -175,14 +175,6 @@
 #define	RTSOCK_LOCK_ASSERT()	mtx_assert(rtsock_mtx, MA_OWNED)

 static SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, );
-#ifdef INET6
-static VNET_DEFINE(int, deembed_scopeid) = 1;
-#define	V_deembed_scopeid	VNET(deembed_scopeid)
-SYSCTL_DECL(_net_inet6_ip6);
-SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, deembed_scopeid, CTLFLAG_RW,
-VNET_NAME(deembed_scopeid), 0,
-Extract embedded zone ID and set it to sin6_scope_id in sockaddr_in6.);
-#endif

 struct walkarg {
 	int	w_tmemsize;
@@ -804,28 +796,31 @@
 			}
 			info.rti_info[RTAX_DST] = rt_key(rt);
 #ifdef INET6
-			switch (rt_key(rt)-sa_family) {
-			case AF_INET6:
-if (V_deembed_scopeid == 0)
+			if (V_deembed_scopeid) {
+switch (rt_key(rt)-sa_family) {
+case AF_INET6:
+	sin6 = (struct sockaddr_in6 *)ss_dst;
+	bcopy(rt_key(rt), sin6, sizeof(*sin6));
+	if (sa6_recoverscope(sin6) == 0)
+		info.rti_info[RTAX_DST] =
+		(struct sockaddr *)sin6;
 	break;
-sin6 = (struct sockaddr_in6 *)ss_dst;
-bcopy(rt_key(rt), sin6, sizeof(*sin6));
-if (sa6_recoverscope(sin6) == 0)
-	info.rti_info[RTAX_DST] =
-	(struct sockaddr *)sin6;
-break;
+}
 			}
 #endif
 			info.rti_info[RTAX_GATEWAY] = rt-rt_gateway;
 #ifdef INET6
-			switch (rt-rt_gateway-sa_family) {
-			case AF_INET6:
-sin6 = (struct sockaddr_in6 *)ss_gw;
-bcopy(rt-rt_gateway, sin6, sizeof(*sin6));
-if (sa6_recoverscope(sin6) == 0)
-	info.rti_info[RTAX_GATEWAY] =
-	(struct sockaddr *)sin6;
-break;
+			if (V_deembed_scopeid) {
+switch (rt-rt_gateway-sa_family) {
+case AF_INET6:
+	sin6 = (struct sockaddr_in6 *)ss_gw;
+	bcopy(rt-rt_gateway, sin6,
+	sizeof(*sin6));
+	if (sa6_recoverscope(sin6) == 0)
+		info.rti_info[RTAX_GATEWAY] =
+		(struct sockaddr *)sin6;
+	break;
+}
 			}
 #endif
 			info.rti_info[RTAX_NETMASK] = rt_mask(rt);
@@ -1130,15 +1125,15 @@
 		rtinfo-rti_addrs |= (1  i);
 		dlen = SA_SIZE(sa);
 #ifdef INET6
-		switch (sa-sa_family) {
-		case AF_INET6:
-			if (V_deembed_scopeid == 0)
+		if (V_deembed_scopeid) {
+			switch (sa-sa_family) {
+			case AF_INET6:
+sin6 = (struct sockaddr_in6 *)ss;
+bcopy(sa, sin6, sizeof(*sin6));
+if (sa6_recoverscope(sin6) == 0)
+	sa = (struct sockaddr *)sin6;
 break;
-			sin6 = (struct sockaddr_in6 *)ss;
-			bcopy(sa, sin6, sizeof(*sin6));
-			if (sa6_recoverscope(sin6) == 0)
-sa = (struct sockaddr *)sin6;
-			break;
+			}
 		}
 #endif
 		m_copyback(m, len, dlen, (caddr_t)sa);
@@ -1219,15 +1214,15 @@
 		rtinfo-rti_addrs |= (1  i);
 		dlen = SA_SIZE(sa);
 #ifdef INET6
-		switch (sa-sa_family) {
-		case AF_INET6:
-			if (V_deembed_scopeid == 0)
+		if (V_deembed_scopeid) {
+			switch (sa-sa_family) {
+			case AF_INET6:
+sin6 = (struct sockaddr_in6 *)ss;
+bcopy(sa, sin6, sizeof(*sin6));
+if (sa6_recoverscope(sin6) == 0)
+	sa = (struct sockaddr *)sin6;
 break;
-			sin6 = (struct sockaddr_in6 *)ss;
-			bcopy(sa, sin6, sizeof(*sin6));
-			if (sa6_recoverscope(sin6) == 0)
-sa = (struct sockaddr *)sin6;
-			break;
+			}
 		}
 #endif
 		if (cp) {
@@ -1594,18 +1589,19 @@
 			info.rti_info[RTAX_BRD] = rt-rt_ifa-ifa_dstaddr;
 	}
 #ifdef INET6
-	for (i = 0; i  RTAX_MAX; i++) {
-		if (info.rti_info[i] == NULL)
-			continue;
-		switch (info.rti_info[i]-sa_family) {
-		case AF_INET6:
-			if (V_deembed_scopeid == 0)
+	if (V_deembed_scopeid) {
+		for (i = 0; i  RTAX_MAX; i++) {
+			if (info.rti_info[i] == NULL)
+continue;
+			switch (info.rti_info[i]-sa_family) {
+			case AF_INET6:
+sin6 = (struct sockaddr_in6 *)ss[i];
+bcopy(info.rti_info[i], sin6, sizeof(*sin6));
+if (sa6_recoverscope(sin6) == 0)
+	info.rti_info[i] =
+	(struct sockaddr *)sin6;
 break;
-			sin6 = (struct sockaddr_in6 *)ss[i];
-			bcopy(info.rti_info[i], sin6, sizeof(*sin6));
-			if (sa6_recoverscope(sin6) == 0)
-info.rti_info[i] = (struct sockaddr *)sin6;
-			break;
+			}
 		}
 	}
 #endif
@@ -1811,7

Re: LOR in rtsock/ifnet

[Hiroki Sato]

Mateusz Guzik mjgu...@gmail.com wrote
  in 20121201223049.ga12...@dft-labs.eu:

mj On Sun, Dec 02, 2012 at 06:54:36AM +0900, Hiroki Sato wrote:
mj  Hiroki Sato h...@freebsd.org wrote
mjin 20121201.225004.2232262673795057435@allbsd.org:
mj 
mj  hr Mateusz Guzik mjgu...@gmail.com wrote
mj  hr   in 20121201133609.ga5...@dft-labs.eu:
mj  hr
mj  hr mj On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote:
mj  hr mj  Mateusz: are you sure it's that commit?
mj  hr mj 
mj  hr mj
mj  hr mj Yes, I double-checked right now.
mj  hr mj
mj  hr mj  I still get this in -HEAD:
mj  hr mj 
mj  hr mj
mj  hr mj Maybe I expressed myself incorrectly, I meant to say that LOR 
started
mj  hr mj showing up since r243187.
mj  hr mj
mj  hr mj The code is still in head and no fixes were comitted (that I know 
of at
mj  hr mj least), so I guess that you seeing this LOR on head is expected. 
:)
mj  hr
mj  hr  Thanks for the info.  I am investigating this now.
mj 
mj   Can anyone test the attached patch and let me know if the LOR
mj   persists or not?
mj 
mj
mj I got the following build failure:
mj /srv/repos/freebsd/sys/netinet6/in6_cksum.c:69:22: error: sys/vnet.h: No
mj such file or directory
mj In file included from /srv/repos/freebsd/sys/netinet6/in6_cksum.c:72:
mj /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: error: expected
mj declaration specifiers or '...' before 'deembed_scopeid'
mj cc1: warnings being treated as errors
mj /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: warning: data
mj definition has no type or storage class
mj /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: warning: type defaults
mj to 'int' in declaration of 'VNET_DECLARE'

 Oops, sorry.  The attached one should work.  The difference is only
 s|sys/vnet.h|net/vnet| as you also pointed out.

mj However after changing sys/vnet.h to net/vnet.h the kernel compiled fine
mj and LOR is gone.

 Thank you!  I am double-checking if there is some negative impact by
 this change.

-- Hiroki
Index: sys/net/rtsock.c
===
--- sys/net/rtsock.c	(revision 243465)
+++ sys/net/rtsock.c	(working copy)
@@ -175,14 +175,6 @@
 #define	RTSOCK_LOCK_ASSERT()	mtx_assert(rtsock_mtx, MA_OWNED)

 static SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, );
-#ifdef INET6
-static VNET_DEFINE(int, deembed_scopeid) = 1;
-#define	V_deembed_scopeid	VNET(deembed_scopeid)
-SYSCTL_DECL(_net_inet6_ip6);
-SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, deembed_scopeid, CTLFLAG_RW,
-VNET_NAME(deembed_scopeid), 0,
-Extract embedded zone ID and set it to sin6_scope_id in sockaddr_in6.);
-#endif

 struct walkarg {
 	int	w_tmemsize;
@@ -804,28 +796,31 @@
 			}
 			info.rti_info[RTAX_DST] = rt_key(rt);
 #ifdef INET6
-			switch (rt_key(rt)-sa_family) {
-			case AF_INET6:
-if (V_deembed_scopeid == 0)
+			if (V_deembed_scopeid) {
+switch (rt_key(rt)-sa_family) {
+case AF_INET6:
+	sin6 = (struct sockaddr_in6 *)ss_dst;
+	bcopy(rt_key(rt), sin6, sizeof(*sin6));
+	if (sa6_recoverscope(sin6) == 0)
+		info.rti_info[RTAX_DST] =
+		(struct sockaddr *)sin6;
 	break;
-sin6 = (struct sockaddr_in6 *)ss_dst;
-bcopy(rt_key(rt), sin6, sizeof(*sin6));
-if (sa6_recoverscope(sin6) == 0)
-	info.rti_info[RTAX_DST] =
-	(struct sockaddr *)sin6;
-break;
+}
 			}
 #endif
 			info.rti_info[RTAX_GATEWAY] = rt-rt_gateway;
 #ifdef INET6
-			switch (rt-rt_gateway-sa_family) {
-			case AF_INET6:
-sin6 = (struct sockaddr_in6 *)ss_gw;
-bcopy(rt-rt_gateway, sin6, sizeof(*sin6));
-if (sa6_recoverscope(sin6) == 0)
-	info.rti_info[RTAX_GATEWAY] =
-	(struct sockaddr *)sin6;
-break;
+			if (V_deembed_scopeid) {
+switch (rt-rt_gateway-sa_family) {
+case AF_INET6:
+	sin6 = (struct sockaddr_in6 *)ss_gw;
+	bcopy(rt-rt_gateway, sin6,
+	sizeof(*sin6));
+	if (sa6_recoverscope(sin6) == 0)
+		info.rti_info[RTAX_GATEWAY] =
+		(struct sockaddr *)sin6;
+	break;
+}
 			}
 #endif
 			info.rti_info[RTAX_NETMASK] = rt_mask(rt);
@@ -1130,15 +1125,15 @@
 		rtinfo-rti_addrs |= (1  i);
 		dlen = SA_SIZE(sa);
 #ifdef INET6
-		switch (sa-sa_family) {
-		case AF_INET6:
-			if (V_deembed_scopeid == 0)
+		if (V_deembed_scopeid) {
+			switch (sa-sa_family) {
+			case AF_INET6:
+sin6 = (struct sockaddr_in6 *)ss;
+bcopy(sa, sin6, sizeof(*sin6));
+if (sa6_recoverscope(sin6) == 0)
+	sa = (struct sockaddr *)sin6;
 break;
-			sin6 = (struct sockaddr_in6 *)ss;
-			bcopy(sa, sin6, sizeof(*sin6));
-			if (sa6_recoverscope(sin6) == 0)
-sa = (struct sockaddr *)sin6;
-			break;
+			}
 		}
 #endif
 		m_copyback(m, len, dlen, (caddr_t)sa);
@@ -1219,15 +1214,15 @@
 		rtinfo-rti_addrs |= (1  i);
 		dlen = SA_SIZE(sa);
 #ifdef INET6
-		switch (sa-sa_family) {
-		case AF_INET6:
-			if (V_deembed_scopeid == 0)
+		if (V_deembed_scopeid) {
+			switch (sa-sa_family) {
+			case AF_INET6:
+sin6 = (struct sockaddr_in6 *)ss;
+bcopy(sa

Re: net.inet6.icmp6.nd6_useloopback - what is it supposed to do?

[Hiroki Sato]

Garrett Cooper yaneg...@gmail.com wrote
  in CAGH67wQWu2PZGcORsiSz3_r+mjsDv=fx9-ijbejqv8jbt7a...@mail.gmail.com:

ya Hi,
ya I've been TAHI testing FreeBSD 7.x sources for the past couple
ya months and over the course of my testing via the TAHI IPv6 conformance
ya test, I changed the knob value from net.inet6.icmp6.nd6_useloopback=1
ya - net.inet6.icmp6.nd6_useloopback=0 and ran into a slew of errors
ya with the addr.p2 phase-1 TAHI tests.
ya I was wondering if someone could describe what the beforementioned
ya sysctl is supposed to do from a functional perspective, how it might
ya tie into other IPv6 RFCs (if applicable), and if disabled how it would
ya affect a system with IPv6 enabled.

 It is for whether a loopback address (::1) is used as the destination
 for traffic toward one of the locally-configured IPv6 addresses.  In
 the original implementation it is in rtrequest(), but the current
 FreeBSD's one it just means if a loopback route will be installed or
 not upon the lo0 interface initialization, not in RTM_RESOLVE.  So,
 if setting nd6_useloopback to 0, no loopback route will be installed
 and some THAI test will fail, I think.

-- Hiroki


pgpgyi4VdowHF.pgp
Description: PGP signature

Re: LOR in rtsock/ifnet

[Hiroki Sato]

Rui Paulo rpa...@freebsd.org wrote
  in 63c19ad8-ea8d-49a8-9e98-4235c4745...@freebsd.org:

rp On 25 Nov 2012, at 23:35, Adrian Chadd adr...@freebsd.org wrote:
rp
rp  DO we know which commit triggered this?
rp
rp
rp I haven't bisected.

 I do not think my commit triggered it because it occurred in
 rt_msg2().  Andrey, can you take a look at this?

-- Hiroki


pgp4Ar9nzPqy3.pgp
Description: PGP signature

Re: [head tinderbox] failure on mips64/mips

[Hiroki Sato]

Adrian Chadd adr...@freebsd.org wrote
  in CAJ-VmomeeoCtj=fjozceiacmytzwvzc8rtdpb8f29ttunkf...@mail.gmail.com:

ad On 17 November 2012 21:45, Hiroki Sato h...@freebsd.org wrote:
ad
ad  ad Fixed. Damn those pesky non-IPV6 belivers.
ad 
ad   Sorry, I was careless about this part.
ad
ad It's fine. :-) God, I so can't grill anyone for breaking the build,
ad given my  track record!
ad
ad I hope you didn't mind me quickly fixing that up?

 I did not mind at all.  Thank you for fixing it!

-- Hiroki


pgpjjk9r8Q9cR.pgp
Description: PGP signature

Re: [head tinderbox] failure on mips64/mips

[Hiroki Sato]

Adrian Chadd adr...@freebsd.org wrote
  in CAJ-VmonbG+6vhR=hzg7gnxvgco+1bmh8sk8dye5x0cs7ep2...@mail.gmail.com:

ad On 17 November 2012 18:35, FreeBSD Tinderbox tinder...@freebsd.org wrote:
ad
ad  cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option   -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 
--param large-function-growth=10 --param max-inline-insns-single=1  
-fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80001000 -mabi=64 
-march=mips64 -msoft-float -ffreestanding -Werror  /src/sys/net/rtsock.c
ad  cc1: warnings being treated as errors
ad  /src/sys/net/rtsock.c: In function 'sysctl_dumpentry':
ad  /src/sys/net/rtsock.c:1577: warning: unused variable 'i' 
[-Wunused-variable]
ad  *** [rtsock.o] Error code 1
ad
ad Fixed. Damn those pesky non-IPV6 belivers.

 Sorry, I was careless about this part.

-- Hiroki


pgp9XaPNuGRYo.pgp
Description: PGP signature

Re: [PATCH] IPv6 and ICMP6 redirects - routing performance

[Hiroki Sato]

Alexander V. Chernikov melif...@freebsd.org wrote
  in 5076c0e3.9050...@freebsd.org:

me Hello list!
me
me Currently there are some unnecessary code residing in
me netinet6/in6_rmx.c causing performance degradation for IPv6
me forwarding.
me
me Initially it was merged from netinet/in_rmx.c but it seems it is
me totally unused now due to different approach used in IPv6 redirects.
me
me Code calls mtx_lock() on rte per each routing lookup in
me in6_matroute().
me Initially I plan to make someting like r241406 for IPv6, but after
me some investigation I found that no one is currently setting
me RTF_DYNAMIC flag for IPv6 routes.
me
me the question is: can we remove this entirely (patch attached) or we
me still needs some parts of this due to incomplete RFC 4861
me implementation?

 I think there is no problem with the removal because route handling
 by rtqkill() is not needed for routes injected by ND and removal of
 in6_clsroute() has already made the in6_rtqtimo() no-op.

-- Hiroki


pgpg9iZf9PLE0.pgp
Description: PGP signature

Re: svn commit: r238277 - in head: etc/defaults etc/rc.d sbin/ipfw share/man/man5 sys/netinet/ipfw

[Hiroki Sato]

Alexander V. Chernikov melif...@freebsd.org wrote
  in 4ffa9723.5000...@freebsd.org:

me On 09.07.2012 12:08, Hiroki Sato wrote:
me  Alexander V. Chernikovmelif...@freebsd.org  wrote
me in4ffa894d.9050...@freebsd.org:
me 
meI meant there was no strong objection.  I am sorry for not commenting
meyour implementation, but at least for ipfw0 it is difficult to
medecouple ifnet and bpf because the primary consumer is tcpdump(8),
mewhich depends on NET_RT_IFLIST to find the target.  Probably your
me tcpdump -i still works with interface name supplied.
mesolution can be used for usbdump(8).  The reason why I committed the
mepatch now is there are reports that these pseudo interfaces made some
meapplications confused and/or caused some performance degradation on
me9.0R, and wanted to fix it in some way.
me Do you plan to take this to 9.1 ?

 Originally I thought of it but I think it was too late.  It should be
 polished in -CURRENT for a while also in terms of how to hide the
 interfaces.

meI am still open for more sophisticated implementation and have no
meobjection to replace mine with it.  Do you have an idea about
meconverting it with a loadable module?
me Personally I think that the right way is to add userkernel interface
me for requesting interface list since this is the most major stopper for
me doing BPF-only providers. However this should be discussed with
me rpaulo@ and delphij@ (so most probably this skips 9.1).

 Adding a sysctl to list all of the struct bpf_if including ones with
 a fake ifp?

 Hm, my goal was just to hide usbusN and ipfw0 *by default* but there
 was no problem with having ipfw0 with an ifnet.  I thought having
 ifnet was tolerable if its consumer was tcpdump-like one because
 there are a lot of packet dump utilities which obtain interface names
 from the system's network interface list.  Hiding the interface is
 rather confusing from user's perspective.

 I do not stick to the committed code and have no objection about
 adding a new API if it is useful.  Well, please let me check if I
 understand your idea correctly.  Given that we add a new API to
 enumerate the interfaces including bpf-only providers with fake
 ifnets, which providers/utilities should be converted to use it?  IMO
 usbusN would be a reasonable target but others still need a real
 ifnet.  In my understanding, the advantage of using a fake ifnet is
 just to prevent it from appearing as an interface.  Is it correct?

me And, as fallback solution we can probably add separate ipfwlog module
me which is quite easy but much less clean.

 I think whether having it as a kernel module or not is orthogonal to
 hiding the interface.  If we support multiple instances of the pseudo
 interface (typical in a system with vnet), cloning capability is
 needed in any way.

-- Hiroki


pgpXYRruftkxV.pgp
Description: PGP signature

Re: Hetzner.de IPv6 and FreeBSD -- default gateway is on other prefix, need to add static route before default -- how?

[Hiroki Sato]

Lev Serebryakov l...@freebsd.org wrote
  in 1606941405.20120429170...@serebryakov.spb.ru:

le Hello, Freebsd-net.
le
le  Famous dedicated server provider Hetzner provides native IPv6 for
le servers, but with rather strange routing configuration: you need to
le configure static interface route and make this route default.
le
le  If I add such lines in /etc/rc.conf:
le
le ifconfig_re0_ipv6=inet6 2a01:4f8:131:60a2::2 prefixlen 64 auto_linklocal 
accept_rtadv
le ipv6_static_routes=ipv6defgw
le ipv6_route_ipv6defgw=2a01:4f8:131:60a0:: -prefixlen 59 -iface re0
le ipv6_defaultrouter=2a01:4f8:131:60a0::1
le ipv6_default_interface=re0
le
le   It doesn't work, because default route added first and it fails to
le be added, as route to 2a01:4f8:131:60a0::1 is not known yet.

 Why do you need to configure the default route manually?  If
 accepting RA on re0 it should be configured automatically.

-- Hiroki


pgpVGf5A1MmrG.pgp
Description: PGP signature

Re: IPv6 and CARP

[Hiroki Sato]

Damien Fleuriot m...@my.gd wrote
  in 4f55e8b0.8010...@my.gd:

ml Hello guys,
ml
ml
ml Are there any news on the topic ?
ml
ml Trying to push IP6 at work for our firewalls and struggling with CARP
ml interfaces with inet6 addresses at boot like OP.
ml
ml I could probably just set the address with a script in
ml /usr/local/etc/rc.d/ but I'd rather get it working out of the box,
ml that'll increase the credibility.

 I am investigating it.  Please give me some more time.

-- Hiroki


pgpYSsRqRMtxg.pgp
Description: PGP signature

Re: Issue with multiple configured IPv6 prefixes in rtadvd.conf

[Hiroki Sato]

Archimedes Gaviola agavi...@infoweapons.com wrote
  in 4f4aedbf.3000...@infoweapons.com:

ag Now, my observation is that there seems to be a problem with
ag advertising two or perhaps more prefixes in the RA message. This has
ag been tested in 7.x and the issues were the same. FreeBSD 4.11 behave
ag the same as well.
ag
ag Is this a bug or limitation of the rtadvd design implementation?

 I am wondering where you got the notation :addrs#1: from.  Please
 try the following:

em2:\
 :mtu#1400:\
 :addr0=3ffe:501::100:::prefixlen0#64:vltime0#12345:pltime0#12345:\
 :addr1=3ffe:501::101:::prefixlen1#64:vltime1#12345:pltime1#12345:

-- Hiroki


pgpAxtEGUFs8F.pgp
Description: PGP signature

Re: ipv6 host inaccessible via route -inteface without ndp pairs

[Hiroki Sato]

Mr Dandy sub...@gmail.com wrote
  in 201202252213.50760.sub...@gmail.com:

su Hi
su
su I play with IPv6 on the Hezner hosting. According to
su http://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en information my
su rc.conf have (FreeBSD 9.0-RELEASE/amd64):
su ---
su ipv6_activate_all_interfaces=YES
su ipv6_static_routes=hetzner
su ipv6_route_hetzner=2a01:4f8:61:50c0::/59 -iface re0
su ifconfig_re0_ipv6=inet6 2a01:4f8:61:50c2::13/64
su ipv6_defaultrouter=2a01:4f8:61:50c0::1
su ipv6_gateway_enable=YES
su --

 Maybe I do not fully understand your network, but is there any reason
 that the following simple configuration does not work?

 ifconfig_re0_ipv6=inet6 2a01:4f8:61:50c2::13/59
 ipv6_defaultrouter=2a01:4f8:61:50c0::1

-- Hiroki


pgpxGtaKgaG98.pgp
Description: PGP signature

[CFT] multiple FIB support in route(8)

[Hiroki Sato]

Hello,

 Can anyone review/test the attached patch to add -fib number option
 to route(8)?  This should simplify static route configuration across
 multiple FIBs in rc.conf.  Just adding an -fib option like the
 following will do the trick without changing rc.d/routing:

  static_routes=foo bar
  route_foo=10.1.1.1/24 192.168.2.1 -fib 2
  route_bar=10.1.1.1/24 192.168.2.1 -fib 3

 The -fib option is supported in all subcommands but monitor.

-- Hiroki
Index: sbin/route/route.c
===
--- sbin/route/route.c	(revision 230991)
+++ sbin/route/route.c	(working copy)
@@ -99,6 +99,8 @@
 struct	rt_metrics rt_metrics;
 u_long  rtm_inits;
 uid_t	uid;
+int	fib;
+int	numfibs;

 static int	atalk_aton(const char *, struct at_addr *);
 static char	*atalk_ntoa(struct at_addr);
@@ -123,6 +125,8 @@
 static const char	*routename(struct sockaddr *);
 static int	rtmsg(int, int);
 static void	set_metric(char *, int);
+static void	set_sofib(int);
+static void	set_procfib(int);
 static void	sockaddr(char *, struct sockaddr *);
 static void	sodump(sup, const char *);
 extern	char *iso_ntoa(void);
@@ -144,6 +148,7 @@
 main(int argc, char **argv)
 {
 	int ch;
+	size_t len;

 	if (argc  2)
 		usage(NULL);
@@ -180,6 +185,16 @@
 		s = socket(PF_ROUTE, SOCK_RAW, 0);
 	if (s  0)
 		err(EX_OSERR, socket);
+
+	len = sizeof(numfibs);
+	if (sysctlbyname(net.fibs, (void *)numfibs, len, NULL, 0) == -1)
+		numfibs = -1;
+
+	len = sizeof(fib);
+	if (numfibs != -1 
+	sysctlbyname(net.my_fibnum, (void *)fib, len, NULL, 0) == -1)
+		fib = -1;
+
 	if (*argv != NULL)
 		switch (keyword(*argv)) {
 		case K_GET:
@@ -207,6 +222,31 @@
 	/* NOTREACHED */
 }

+static void
+set_sofib(int f)
+{
+	int error;
+
+	if (f  0) {
+		error = setsockopt(s, SOL_SOCKET, SO_SETFIB, (void *)f,
+		sizeof(f));
+		if (error)
+			errx(EX_OSERR, setsockopt(SO_SETFIB, %d) failed, f);
+	}
+}
+
+static void
+set_procfib(int f)
+{
+	int error;
+
+	if (f  0) {
+		error = setfib(f);
+		if (error)
+			errx(EX_OSERR, setfib(%d) failed, f);
+	}
+}
+
 /*
  * Purge all entries in the routing tables not
  * associated with network interfaces.
@@ -223,29 +263,39 @@
 		errx(EX_NOPERM, must be root to alter routing table);
 	}
 	shutdown(s, SHUT_RD); /* Don't want to read back our messages */
-	if (argc  1) {
+	while (argc  1) {
+		argc--;
 		argv++;
-		if (argc == 2  **argv == '-')
-		switch (keyword(*argv + 1)) {
-			case K_INET:
-af = AF_INET;
-break;
+		if (**argv != '-')
+			usage(*argv);
+		switch (keyword(*argv + 1)) {
+		case K_INET:
+			af = AF_INET;
+			break;
 #ifdef INET6
-			case K_INET6:
-af = AF_INET6;
-break;
+		case K_INET6:
+			af = AF_INET6;
+			break;
 #endif
-			case K_ATALK:
-af = AF_APPLETALK;
-break;
-			case K_LINK:
-af = AF_LINK;
-break;
-			default:
-goto bad;
-		} else
-bad:			usage(*argv);
+		case K_ATALK:
+			af = AF_APPLETALK;
+			break;
+		case K_LINK:
+			af = AF_LINK;
+			break;
+		case K_FIB:
+			if (!--argc)
+usage(*argv);
+			fib = strtol(*++argv, NULL, 0);
+			if (fib == 0  errno == EINVAL)
+usage(*argv);
+			break;
+		default:
+			usage(*argv);
+		}
 	}
+	set_sofib(fib);
+	set_procfib(fib);
 retry:
 	mib[0] = CTL_NET;
 	mib[1] = PF_ROUTE;
@@ -657,6 +707,13 @@
 			case K_NOSTICK:
 flags = ~RTF_STICKY;
 break;
+			case K_FIB:
+if (!--argc)
+	usage(NULL);
+fib = strtol(*++argv, NULL, 0);
+if (fib == 0  errno == EINVAL)
+	usage(NULL);
+break;
 			case K_IFA:
 if (!--argc)
 	usage(NULL);
@@ -751,6 +808,7 @@
 		so_dst.sinarp.sin_other = SIN_PROXY;
 		flags |= RTF_ANNOUNCE;
 	}
+	set_sofib(fib);
 	for (attempts = 1; ; attempts++) {
 		errno = 0;
 		if ((ret = rtmsg(*cmd, flags)) == 0)
@@ -777,6 +835,9 @@
 			(void) printf( (%s),
 inet_ntoa(((struct sockaddr_in *)route.rt_gateway)-sin_addr));
 		}
+		if (fib  0)
+			printf( fib %u, (unsigned int)fib);
+
 		if (ret == 0) {
 			(void) printf(\n);
 		} else {
@@ -1490,6 +1551,8 @@
 	}
 	if (gate  rtm-rtm_flags  RTF_GATEWAY)
 		(void)printf(gateway: %s\n, routename(gate));
+	if (fib  0)
+		(void)printf(fib: %u\n, (unsigned int)fib);
 	if (ifp)
 		(void)printf(  interface: %.*s\n,
 		ifp-sdl_nlen, ifp-sdl_data);
Index: sbin/route/route.8
===
--- sbin/route/route.8	(revision 230991)
+++ sbin/route/route.8	(working copy)
@@ -28,7 +28,7 @@
 .\ @(#)route.8	8.3 (Berkeley) 3/19/94
 .\ $FreeBSD$
 .\
-.Dd October 2, 2005
+.Dd January 29, 2012
 .Dt ROUTE 8
 .Os
 .Sh NAME
@@ -124,6 +124,7 @@
 .Op Fl n
 .Cm flush
 .Op Ar family
+.Op Fl fib Ar number
 .Ed
 .Pp
 If the
@@ -140,6 +141,10 @@
 .Fl inet
 modifiers, only routes having destinations with addresses in the
 delineated family will be deleted.
+When an
+.Fl fib
+option is specified, the operation will be applied to
+the specified FIB.
 .Pp
 The other commands have the following syntax:
 .Pp
@@ -310,6 +315,21 @@
 .Fl lockrest
 

Re: [CFT] multiple FIB support in route(8)

[Hiroki Sato]

Alexander V. Chernikov melif...@freebsd.org wrote
  in 4f2dc674.4070...@freebsd.org:

me On 04.02.2012 18:35, Hiroki Sato wrote:
me  Hello,
me 
meCan anyone review/test the attached patch to add -fib number option
meto route(8)?  This should simplify static route configuration across
memultiple FIBs in rc.conf.  Just adding an -fib option like the
mefollowing will do the trick without changing rc.d/routing:
me 
me static_routes=foo bar
me route_foo=10.1.1.1/24 192.168.2.1 -fib 2
me route_bar=10.1.1.1/24 192.168.2.1 -fib 3
me 
meThe -fib option is supported in all subcommands but monitor.
me Why should we leave `monitor` as is?
me
me And, even if we really need to do so why route monitor silently
me accepts and ignores -fib X key?

 No specific reason.  The monitor originally supports no flag to
 filter rt messages and silently ignores any flag.

 Is this a suggestion that it should support -fib or just from your
 curiosity?  I do not think we really need to leave it.  The attached
 patch is enough to support it, too.

-- Hiroki
Index: sbin/route/route.c
===
--- sbin/route/route.c	(revision 230991)
+++ sbin/route/route.c	(working copy)
@@ -99,6 +99,8 @@
 struct	rt_metrics rt_metrics;
 u_long  rtm_inits;
 uid_t	uid;
+int	fib;
+int	numfibs;

 static int	atalk_aton(const char *, struct at_addr *);
 static char	*atalk_ntoa(struct at_addr);
@@ -112,7 +114,7 @@
 #endif
 static void	interfaces(void);
 static void	mask_addr(void);
-static void	monitor(void);
+static void	monitor(int, char*[]);
 static const char	*netname(struct sockaddr *);
 static void	newroute(int, char **);
 static void	pmsg_addrs(char *, int, size_t);
@@ -123,6 +125,8 @@
 static const char	*routename(struct sockaddr *);
 static int	rtmsg(int, int);
 static void	set_metric(char *, int);
+static void	set_sofib(int);
+static void	set_procfib(int);
 static void	sockaddr(char *, struct sockaddr *);
 static void	sodump(sup, const char *);
 extern	char *iso_ntoa(void);
@@ -144,6 +148,7 @@
 main(int argc, char **argv)
 {
 	int ch;
+	size_t len;

 	if (argc  2)
 		usage(NULL);
@@ -180,6 +185,16 @@
 		s = socket(PF_ROUTE, SOCK_RAW, 0);
 	if (s  0)
 		err(EX_OSERR, socket);
+
+	len = sizeof(numfibs);
+	if (sysctlbyname(net.fibs, (void *)numfibs, len, NULL, 0) == -1)
+		numfibs = -1;
+
+	len = sizeof(fib);
+	if (numfibs != -1 
+	sysctlbyname(net.my_fibnum, (void *)fib, len, NULL, 0) == -1)
+		fib = -1;
+
 	if (*argv != NULL)
 		switch (keyword(*argv)) {
 		case K_GET:
@@ -195,7 +210,7 @@
 			/* NOTREACHED */

 		case K_MONITOR:
-			monitor();
+			monitor(argc, argv);
 			/* NOTREACHED */

 		case K_FLUSH:
@@ -207,6 +222,31 @@
 	/* NOTREACHED */
 }

+static void
+set_sofib(int f)
+{
+	int error;
+
+	if (f  0) {
+		error = setsockopt(s, SOL_SOCKET, SO_SETFIB, (void *)f,
+		sizeof(f));
+		if (error)
+			errx(EX_OSERR, setsockopt(SO_SETFIB, %d) failed, f);
+	}
+}
+
+static void
+set_procfib(int f)
+{
+	int error;
+
+	if (f  0) {
+		error = setfib(f);
+		if (error)
+			errx(EX_OSERR, setfib(%d) failed, f);
+	}
+}
+
 /*
  * Purge all entries in the routing tables not
  * associated with network interfaces.
@@ -223,29 +263,39 @@
 		errx(EX_NOPERM, must be root to alter routing table);
 	}
 	shutdown(s, SHUT_RD); /* Don't want to read back our messages */
-	if (argc  1) {
+	while (argc  1) {
+		argc--;
 		argv++;
-		if (argc == 2  **argv == '-')
-		switch (keyword(*argv + 1)) {
-			case K_INET:
-af = AF_INET;
-break;
+		if (**argv != '-')
+			usage(*argv);
+		switch (keyword(*argv + 1)) {
+		case K_INET:
+			af = AF_INET;
+			break;
 #ifdef INET6
-			case K_INET6:
-af = AF_INET6;
-break;
+		case K_INET6:
+			af = AF_INET6;
+			break;
 #endif
-			case K_ATALK:
-af = AF_APPLETALK;
-break;
-			case K_LINK:
-af = AF_LINK;
-break;
-			default:
-goto bad;
-		} else
-bad:			usage(*argv);
+		case K_ATALK:
+			af = AF_APPLETALK;
+			break;
+		case K_LINK:
+			af = AF_LINK;
+			break;
+		case K_FIB:
+			if (!--argc)
+usage(*argv);
+			fib = strtol(*++argv, NULL, 0);
+			if (fib == 0  errno == EINVAL)
+usage(*argv);
+			break;
+		default:
+			usage(*argv);
+		}
 	}
+	set_sofib(fib);
+	set_procfib(-1);
 retry:
 	mib[0] = CTL_NET;
 	mib[1] = PF_ROUTE;
@@ -657,6 +707,13 @@
 			case K_NOSTICK:
 flags = ~RTF_STICKY;
 break;
+			case K_FIB:
+if (!--argc)
+	usage(NULL);
+fib = strtol(*++argv, NULL, 0);
+if (fib == 0  errno == EINVAL)
+	usage(NULL);
+break;
 			case K_IFA:
 if (!--argc)
 	usage(NULL);
@@ -751,6 +808,7 @@
 		so_dst.sinarp.sin_other = SIN_PROXY;
 		flags |= RTF_ANNOUNCE;
 	}
+	set_sofib(fib);
 	for (attempts = 1; ; attempts++) {
 		errno = 0;
 		if ((ret = rtmsg(*cmd, flags)) == 0)
@@ -777,6 +835,9 @@
 			(void) printf( (%s),
 inet_ntoa(((struct sockaddr_in *)route.rt_gateway)-sin_addr));
 		}
+		if (fib  0)
+			printf( fib %u, (unsigned int)fib);
+
 		if (ret == 0

Re: Unnecessary sleep in network.subr: ipv6_up()

[Hiroki Sato]

Dennis Kögel d...@neveragain.de wrote
  in 9bbb9ab2-4f60-4dcb-8d25-fdec83f62...@neveragain.de:

dk Am 16.01.2012 um 20:45 schrieb Hiroki Sato:
dk  Can you try the attached patch and let me know if it works fine on
dk  your system?
dk 
dk It does indeed.

 Thank you for your report.  I committed the change into HEAD.  It
 will be merged to 9-STABLE if there is no major problem with it.

-- Hiroki


pgpEKFSYPO8mJ.pgp
Description: PGP signature

Re: Adding setfib support to rc.d/routing

[Hiroki Sato]

Sergey Matveychuk s...@semmy.ru wrote
  in 4f196d64.6020...@semmy.ru:

se 20.01.2012 10:52, Attila Nagy wrote:
se  Hi,
se 
se  Having multiple routing tables is a very nice and (was a) long awaited
se  capability in FreeBSD. Having it since years is even more cool,
se  because
se  we can assume it's stable now.
se  But not having infrastructure support for it sucks, this makes people
se  hacking with rc.local or various scripts in various places.
se 
se  There is a(t least one) PR about it: conf/145440, which proposes a
se  standard method for setting up different FIBs in a seems to be logical
se  way, which is compatible with the current single routing table method
se  of
se  static_routes.
se 
se  Are there any objections about this PR? Is there something we can do
se  to
se  get it committed?
se 
se
se
se JFYI conf/132476

 I'll take a look at these patches and try to merge.

-- Hiroki


pgpPagYsRO1qy.pgp
Description: PGP signature