Re: IPv6: Invalid nd6 entry created for an RA without an lladdr

[神明達哉]

At Wed, 2 Oct 2019 17:04:23 -0400,
Ryan Stone  wrote:
>
> At work, our product is putting through an IPv6 conformance test and
> it's found an issue in our handling of Routing Advertisements (RAs).
> If we receive an RA that does not specify an lladdr, then
> nd6_cache_lladdr() is called with lladdr NULL:
>
>
https://svnweb.freebsd.org/base/head/sys/netinet6/nd6.c?revision=347984=markup#l1961
>
> In this case, the linkhdr cache is never initialized, but we still put
> the entry in the STALE state at line 2032.

If lladdr is NULL shouldn't it reach line 2032?

if (lladdr != NULL) { /* (7) */
nd6_llinfo_setstate(ln, ND6_LLINFO_STALE);
EVENTHANDLER_INVOKE(lle_event, ln,
   LLENTRY_RESOLVED);
}

In any case, if a host receives an RA without a link-layer address
option and no neighbor cache entry exists for the RA sender at that
point, it shouldn't set the state of a newly created cache entry to
STALE.  While RFC4861 is not so explicit about this particular
condition, I believe it's pretty clear from Section 6.3.4 of the RFC
(it may even be questionable just to create an entry in this case, but
that's probably within the scope of acceptable implementation choices
as long as the entry is a mere placeholder).  I also believe FreeBSD
used to not do this (correctly), so if it currently sets it to STALE
it's quite likely to be some regression.

--
JINMEI, Tatuya
___
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: why rtsold ?

[神明達哉]

At Thu, 18 Oct 2018 08:53:14 +0700,
Victor Sudakov  wrote:

> > The router may send a router advertisement whenever it wants.  That's
why
> > your machine seems to work even without rtsold.  However, SLAAC
addresses
> > expire after a certain amount of time.  rtsold will ask the router for a
> > new advertisement before your address expires.
>
> Who actually processes these router advertisements: the rtsold daemon
> or the kernel itself?
>
> Is this passage:
>
> 8.1.1.4. Plug and Play
>
> Most of the IPv6 stateless address autoconfiguration is implemented in
> the kernel. Neighbor Discovery functions are implemented in the kernel
> as a whole. Router Advertisement (RA) input for hosts is implemented
> in the kernel. Router Solicitation (RS) output for endhosts, RS input
> for routers, and RA output for routers are implemented in the
> userland.
>
> still correct?
> (from https://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html)

It's slightly outdated.  "RA input for hosts" was originally limited
to what's described in RFC4862, but it's been extended over time.  The
RFC4862-side (aka SLAAC) is still implemented in the kernel, but DNS
configuration options (RFC8106, although the FreeBSD implementation
may still only conform to RFC6106) are used in the user space.  The
current trend seems to introduce more such high level config
information to RA, so I'd expect these will also be handled in the
user space.

BTW, regarding the original topic of 'why rtsold', my understanding is
that its original motivation is to help hosts moving links.  At least
at the time of development, there was no sophisticated detection
mechanism when a host is connected to a new link, so no one else could
send RS to get new network configuration information.  rtsold monitors
link status and invokes new RS-RA exchanges when it detects a change
of the link status from off to on.  Address lifetime expiration is not
usually an issue since routers are supposed to send RAs periodically
(with sufficiently short intervals to prevent accidental expiration);
and in any case (AFAIK) rtsold doesn't help that situation, as it
doesn't send RSes based on address lifetimes.

Today, we now use DNS config information provided via RA in the user
space, so another role of rtsold is to reflect any changes to it while
the host is still connected to the same link.   Routers are supposed
to advertise RAs with new information, but without rtsold (or
something equivalent) no one in the user space listens to those RAs to
apply the configuration change.

--
JINMEI, Tatuya
___
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: netstat(1) -s -f is broken

[神明達哉]

At Fri, 4 May 2018 13:19:57 +0300,
"Andrey V. Elsukov"  wrote:

> > Doesn't work with -p either.
> > netstat -I lo0 -s -p udp
> > :udp: no per-interface stats routine
> >
> > It would be very useful if this actually worked.

> Only IPv6 and ICMPv6 have per-interface statistics counters. Other
> protocols don't have such support.

That's how I remember why per-interface statistics was originally
provided only for IPv6, but RFC4293 extended the concept to IPv4
(interestingly RFC4293 also seems to effectively deprecate
per-interface ICMPv6 statistics).  So it would make sense to make
'-I  -s -f inet' now works.

The UDP case is totally different - as far as I remember there has
never been per-interface UDP statistics defined in the form of RFC
MIBs, so it's actually reasonable to emit an error against
'-I  -s -p udp'.

--
JINMEI, Tatuya
___
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: Announce IPv6 prefix without being IPv6 gateway?

[神明達哉]

At Sun, 23 Apr 2017 22:48:05 +0300,
Lev Serebryakov  wrote:

> rtadvd[2663]: non-zero lifetime RA but net.inet6.ip6.forwarding=0. Ignored.
>
>  But I don't need IPv6 forwarding! I only want Prefix announcement to avoid
> manual configuration of Windows host and virtual boxes on this host!
>
>  Is it possible to achieve such configuration?

Yes it is.  You'll need to set the router lifetime to 0 in
rtadvd.conf, e.g.

   ef0:\
   :addr="2001:db8::1000::":prefixlen#64:rltime#0:

See also rtadvd.conf(5).

--
JINMEI, Tatuya
___
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: ping6: failed to get receiving hop limit

[神明達哉]

At Tue, 10 May 2016 10:26:59 +0300,
Dmitry Sivachenko  wrote:

> Sometimes ping6 command writes the following warning to stderr:
>
> ping6: failed to get receiving hop limit
>
> I can easily reproduce this with
> for n in `jot - 1 1000` ; do /sbin/ping6 -n -c 5 $HOST > /dev/null ; done
>
> It is very likely that even 100 repetitions is enough to catch this.
>
> Other than this warning IPv6 network seems to work properly.
>
> What does it mean?

That should mean the IPV6_RECVHOPLIMIT socket option somehow didn't
work as expected: the kernel didn't provide the information in the
ancillary data chain.  I have no idea about how this could happen -
it's quite likely to be some kind of kernel bug, but I have no
specific idea.

--
JINMEI, Tatuya
___
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 fragments handling

[神明達哉]

At Sat, 20 Dec 2014 23:40:37 +0100,
Ilya Bakulin i...@bakulin.de wrote:

 But what we do is just silently discarding the overlapping segment, see [2].
 When using PF with fragment reassembly, the behavior changes to what RFC
 says
 and the packet is completely dropped.

 There is no security issue with current behavior, because the already
 received
 part is never overwritten, but following RFC a bit closer would be nice.

 Maybe we should fix the stack to drop such packets?

That would be a nice cleanup (the current implementation you cited
seems to be written way before RFC5722, so it's not surprising it
doesn't follow the latest recommendation).

 [1] https://tools.ietf.org/html/rfc5722#section-4
 [2] https://github.com/freebsd/freebsd/blob/master/sys/netinet6/frag6.c#L443

--
JINMEI, Tatuya
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 link-local addr %interfacename

[神明達哉]

At Fri, 7 Nov 2014 13:33:43 +0100,
Matthias Apitz g...@unixarea.de wrote:

 My question is: What does the %em0 mean in the IPv6 addr and why it is
 not working without it?
[...]
 I consulted the handbook and the RFC:

 https://www.freebsd.org/doc/handbook/network-ipv6.html
 http://www.ietf.org/rfc/rfc3513.txt

 Both do not give any explanation re/ the %interface value.

See this: http://www.ietf.org/rfc/rfc4007.txt

--
JINMEI, Tatuya
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins

[神明達哉]

At Thu, 04 Sep 2014 10:42:59 -0400,
John Baldwin j...@freebsd.org wrote:

  It looks like on Solaris, they support IPv4-mapped multicast addresses for
  IPV6, and things work when they create an IPv6 socket, and then put an
  IPv4-mapped multicast address in it.  For Linux, they have specific
  code paths in that function which seem to force creating an IPv4
  socket.

 From looking at the source, it doesn't look like the Linux workaround (using
 IP_ADD_MEMBERSHIP on an AF_INET6 socket) will work on FreeBSD.  I'm not sure
 how hard it would be to fix in6_mcast.c to support IPv4 groups.  bms@ might
 know.

(In my understanding) in general, BSD variants intentionally limit the
support for the APIs using to that standardized in RFC3493 because of
issues such as those described in
http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01
(where implications with multicast API are also discussed).  So I
suspect it'll be generally difficult to extend the support for
IPv4-mapped IPv6 addresses.

As usual in the case where a deployed application relies on
non-standard, non-portable API, making the decision is difficult.
Personally, I'd first consider dealing it in the JDK so it'll be more
portable.  (Even though there are only two OSes today: FreeBSD and
Linux:-) that will be helpful for other BSD variants, and also for even more
minor systems that don't support the non-standard API.

--
JINMEI, Tatuya
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 nodeinfo default behaviour

[神明達哉]

At Sun, 20 Jul 2014 02:04:10 -0700,
Loganaden Velvindron lo...@elandsys.com wrote:

  Security Considerations

This protocol shares the security issues of ICMPv6 that are
documented in the Security Considerations section of [5].

This protocol has the potential of revealing information useful to a
would-be attacker.  An implementation of this protocol MUST have a
default configuration that refuses to answer queries from global-
scope [3] addresses.

 I suggest that we switch to 0 by default to be more RFC compliant.

Are you referring to the value of '(V_)icmp6_nodeinfo'?

If so, and to be compliant with the above MUST of the RFC, it doesn't
seem to have to be 0; it only has to have the ICMP6_NODEINFO_GLOBALOK
bit cleared:

/*
 * Validate IPv6 source address.
 * The default configuration MUST be to refuse answering queries from
 * global-scope addresses according to RFC4602.
 * Notes:
 *  - it's not very clear what refuse means; this implementation
 *simply drops it.
 *  - it's not very easy to identify global-scope (unicast) addresses
 *since there are many prefixes for them.  It should be safer
 *and in practice sufficient to check all but loopback and
 *link-local (note that site-local unicast was deprecated and
 *ULA is defined as global scope-wise)
 */
if ((V_icmp6_nodeinfo  ICMP6_NODEINFO_GLOBALOK) == 0 
!IN6_IS_ADDR_LOOPBACK(ip6-ip6_src) 
!IN6_IS_ADDR_LINKLOCAL(ip6-ip6_src))
goto bad;

and the default value already seems to meet this condition:

VNET_DEFINE(int, icmp6_nodeinfo) =
(ICMP6_NODEINFO_FQDNOK|ICMP6_NODEINFO_NODEADDROK);

--
JINMEI, Tatuya
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 nodeinfo default behaviour

[神明達哉]

At Tue, 22 Jul 2014 10:01:50 -0700,
Loganaden Velvindron lo...@elandsys.com wrote:

Security Considerations
  
  This protocol has the potential of revealing information useful to a
  would-be attacker.  An implementation of this protocol MUST have a
  default configuration that refuses to answer queries from global-
  scope [3] addresses.
  
   I suggest that we switch to 0 by default to be more RFC compliant.
 
  Are you referring to the value of '(V_)icmp6_nodeinfo'?

 I'm referring to the sysctl:

 net.inet6.icmp6.nodeinfo.

These two are essentially the same in this context: this sysctl is an
interface to (V_)icmp6_nodeinfo.  This variable is set to
ICMP6_NODEINFO_FQDNOK|ICMP6_NODEINFO_NODEADDROK by default,
and since ICMP6_NODEINFO_FQDNOK and ICMP6_NODEINFO_NODEADDROK are 0x1
and 0x2, respectively, the default value of the sysctl variable is 3
by default.

In your original message, you said

   I suggest that we switch to 0 by default to be more RFC compliant.

and I tried to point out that it didn't make sense because to be more
RFC compliant it doesn't have to switch to 0, it just needs to have
the ICMP6_NODEINFO_GLOBALOK flag (0x8) cleared, and the current
default meets the condition already.

Now you're changing the reason:

 I think that it's sensible to turn it to 0 by default, unless you need
 it.

Unlike being RFC compliant, whether something is sensible is
usually subjective, and different people may have different opinions.
Personally, I often find ping6 -w quite useful for debugging
purposes, and I think limiting its use to link-local by default gives
a reasonable level of defense (and, disabling it by default would
reduce the usability pretty much).  So I'd rather prefer keeping the
current default, but, again, other people may have a different
preference.

--
JINMEI, Tatuya
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipv6 neighbor cache question

[神明達哉]

At Thu, 27 Mar 2014 17:23:55 +0100,
Mikal Sande mi...@sande.im wrote:

 Is the IPv6 neighbor cache supposed to not inlcude incomplete entries? When 
 my freebsd box resolves a previously unknown ipv6 address with ndp it does 
 not add anything to the neighbor cache before it gets a reachability 
 confirmation. I have viewed the neighbor cache with ndp -a.

 The ipv6 addresses in question are local, so I am pretty sure that on-link 
 determination is not interfering. The same thing happens with both link-local 
 and global addresses.

 When I ping an unused ipv6 address I do not find any corresponding incomplete 
 entry in the neighbor cache afterwards. But, if I ping an unused ipv4 address 
 i do find an incomplete entry in the arp cache. I am curious as to why this 
 behavior occurs. Is it intentional? Is it by design?

 The reason for my curiosity is that I have not observed this behavior in 
 other OSes such as linux and openbsd.

I suspect that's something specific to recent versions of FreeBSD.
The very original kernel neighbor cache and ndp implementations of the
KAME project should have behaved as you expected above and actually
saw with OpenBSD.  I don't know if the change was intentional or a
kind of defect, though.  Hopefully someone more familiar with recent
updates in FreeBSD can clarify that.

--
JINMEI, Tatuya
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

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

[JINMEI Tatuya / 神明達哉]

At Fri, 28 Jun 2013 17:30:21 -0500,
Mark Felder f...@feld.me wrote:

 Later after a bit more digging and discussion I've come to learn that the  

So, you've gone through the literature on this topic including
http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01
?

 security aspect may simply be unexpected behavior -- the binding to ipv6  
 sockets and endusers not realizing it, thus creating a security hole for  
 environments with only an ipv4 firewall.
 
 We ship a dual stack firewall by default, and now since FreeBSD 9 we have  
 the rc.conf setting ipv6_activate_all_interfaces=YES which seems  
 sufficient to mitigate this; the user would have to know they're enabling  
 ipv6 and what its consequences could be.

I'm afraid it's a bit too optimistic.  We also need to rely on
either application programmers being careful enough to write code like
this:
-  sin6 = (struct sockaddr_in6 *) sa;
-  inet_ntop( AF_INET6, (void *) sin6-sin6_addr.s6_addr, addr, sizeof
- addr );
-  /* If it's an IPv4 mapped address, drop the leading ':::' */
-  if ( IN6_IS_ADDR_V4MAPPED( (sin6-sin6_addr) ) )
-strncpy( wrapper_addr, addr + 7, sizeof wrapper_addr );
-  /* otherwise surround the address with braces to hopefully match 
- what tcp wrapper expects */
-  else sprintf( wrapper_addr, %s, addr );
-}
(taken from the FreeBSD port patch for rwhois)
so a naive user can safely write a rule like
  deny 192.0.2.1
  allow all
or the user is careful enough to write ACLs like:
  deny 192.0.2.1
  deny :::192.0.2.1
  allow all

In theory, people (either or both of programmers and users) can make
it safe.  In practice, I personally think it's sufficiently error
prone.

Admittedly, however, different people may have difference senses on
the severity of this point.  And (in my understanding) that's why
relevant people failed to get a clear consensus at the time they
discussed this API.  In the end the standard default behavior was
documented with leaving lots of controversy.  Unfortunately, this also
left portability problems.  It's not only for FreeBSD; as far as I
know NetBSD still keeps the same default as FreeBSD, and, as far as I
know OpenBSD still even refuses to allow this usage of IPv4-mapped
IPv6 addresses.  And, I suspect some of them do so religiously, and
will never change the behavior no matter what the standard
documentations state.

So...

 So I guess the question is: what do we do? It looks like we're in  
 violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section  
 2.10.20*.

...aside from what FreeBSD should do for ip6.v6only, I personally
believe that realistically this issue should be resolved at the
application side, i.e., explicitly set the IPV6_V6ONLY socket option
to 1 and use both AF_INET (for IPv4) and AF_INET6 (for IPv6, and only
for IPv6) sockets.  As far as I know this is the most portable
behavior.  Regarding the rwhois case, I'd first suggest updating the
patch with this socket option setting.  Hopefully it can be accepted
by the upstream because it's most portable.  If they still reject it
because it's against the standard (and even if it's less portable in
reality), my next suggestion is to explicitly set the IPV6_V6ONLY
socket option to 0.  This setting is redundant in the sense of
standard purity, but hopefully less controversial for those preferring
the standard compliance as it only requires a small change and will
make it still more portable.

Going back to the question of what FreeBSD should do for ip6.v6only:
Personally, I'd still suggest keeping the same default because I agree
this behavior is sufficiently safer (as noted above) *and* there'll
be portability issues anyway (OSes using the different default
religiously will never change it).  But I also understand the
argument that standard compliance is more important than debatable
safety.  In either case, it would help if we provide detailed
discussion for the description of this sysctl knob.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 tunnel MTU of 1480 not effective

[JINMEI Tatuya / 神明達哉]

At Sat, 11 May 2013 22:09:49 -0700,
Kevin Oberman rkober...@gmail.com wrote:

   However I'm only able to send IPv6 packets from my host that fit an MTU
   of 1280 even though I've set the tunnel interface and per-route MTU to
   1480, based on the outer ethernet connection having an MTU of 1500.
   Hurricane Electric supports this and I've set the MTU to 1480 on their
   side as well.
[...]
 I complained about this at least a couple of years ago and was told by the
 developer (I don't recall exactly who any more) that it was right and would
 not be changed. I really would love to see this reconsidered before IPv6
 becomes much more popular as it will simply cause confusion, but I, too,
 fear that it is a lost cause.

What's this (to reconsider)?  That ping6 fragments outgoing packets
at 1280 octets (by default)?  Or, more in general whether any outgoing
IPv6 packet can initially honor the interface MTU?

If it's the former, I personally believe the default behavior makes
more sense because IPv6 doesn't have the concept of don't fragment
bit, so any packet/fragment larger than 1280 octets could be dropped
at an intermediate router.  In theory, we could recover from that
situation if that router sent an ICMPv6 packet too big message and
the kernel performed path MTU discovery (which in my understanding is
not the case for non connected sockets like the one ping6 uses), but
even if PTMU discovery worked, some initial echo requests would still
be lost.  As a user, I wouldn't like to bother to wonder the reason
for the packet loss if my main concern is reachability check (that
would be my primary purpose for using ping6).

The same argument applies to non connected UDP sockets, and, in fact,
DNS server implementations behave exactly like ping6 in that sense
(fragmenting large DNS responses at 1280 octets), and exactly for that
reason.

If it's the latter, I thought at least TCP (if not also for other
connected sockets) honors the best possible MTU, starting from the MTU
of the outgoing interface.  If it doesn't, I agree with you; it should
be fixed, and I don't think it's a lost cause.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Why did KAME need ND6_LLINFO_WAITDELETE?

[JINMEI Tatuya / 神明達哉]

At Thu, 10 Jan 2013 15:50:30 -0800,
prabhakar lakhera prabhakar.lakh...@gmail.com wrote:

 I see that* ND6_LLINFO_WAITDELETE *was done away with long time back.
 I was looking for any historical reasons for why it was needed and what
 triggered its removal.

I'd normally change history in the original KAME repository:

http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.h
http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/nd6.c
(search for ND6_LLINFO_WAITDELETE)

It looks like it was me who made this change but I don't remember
details:-) and I don't have time to look into it closer right now.
If the rationale is still not clear from the logs and specific code
diffs please ask again.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Help: Macro limit in file nd6.h

[JINMEI Tatuya / 神明達哉]

At Tue, 18 Sep 2012 18:11:54 +,
Varadarajan, Sudharshan sudharshan.varadara...@netapp.com wrote:

 When I was going through the file nd6.h, (../sysnetinet6/nd6.h) I find that 
 macro (prefix list size) PRLSTSIZ is defined as 10. Is there any particular 
 reason for having a lower value like this?

I don't remember, but I suspect it was an arbitrary choice.

Maybe you can find the rationale (if any) in old commit logs when the
code was developed by the KAME project at, e.g.,
http://www.kame.net/dev/cvsweb2.cgi/

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: How to set the IPv6 linklocal scope id for an interface?

[JINMEI Tatuya / 神明達哉]

At Thu, 17 May 2012 15:13:08 -0700,
prabhakar lakhera prabhakar.lakh...@gmail.com wrote:

 Removing the hyperlinks (these seem to get appended by gmail:
 
 Hi,
 
 Is there any way for the administrator to set an interface's scope if
 for link local scope?

I don't think it's been merged to *BSDs, but the original KAME
implementation contained a tool called scope6config
http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/scope6config/

If I understand you correctly, that does what (at least superficially)
you asked.  From a quick look the kernel already seems to have the
underlying ioctl, so maybe you can simply fetch the source file of the
tool and compile it.

That said...

 I am trying to avoid the following:
 
 Here's the problem. I have two interfaces A and B on same link. Both
 learn RA for the link. One of these is used to add a default route
 entry in the routing table. Lets say default router entry for A is
 picked, we have the following default route entry:

I'm afraid it's less likely that you can achieve this just by tweaking
the scope zone configuration.  I suspect there are other places in the
kernel where one-to-one mapping between interfaces and links are
assumed, either implicitly or explicitly, and you'll have another
trouble.

But that's a guess.  Maybe you should at least give it a try.  Good
luck:-)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: getifaddrs ipv6 scope

[JINMEI Tatuya / 神明達哉]

At Sat, 14 Apr 2012 16:41:52 +,
Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote:

  The issue you mentioned comes from an implementation decision of the
  KAME IPv6 stack.
  The attached patch should address it.  However, it may break the
  applications which expect that getifaddrs() returns a link-local
  address with KAME's embeded scopeid representation.  I'm not sure
  there are such applications, for now.
 
 There should be none.  If we have some we should fix them.  I wonder if this 
 should actually be done in the kernel to limit the scope of the embedded 
 scopeid to our kernel for now?   Do we have other interfaces (ignoring kvm) 
 that export the embedded scopeid?

I suspect most of routing related implementations (most notably,
route6d and quagga) still rely on the embedded scope (zone) ID for the
data exchanged over a routing socket.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Strong host model in IPv6?

[JINMEI Tatuya / 神明達哉]

At Fri, 9 Mar 2012 23:26:01 +,
Alex Yong annonymouse+free...@gmail.com wrote:

 I've spotted that in IPv4 there is the sysctl net.inet.ip.check_interface
 which defaults to set, but I've been unable to find any guarantees that
 strong host model is enforced in v6 in the comments or internet.  According
 to the IPv6 Core Protocols Implementation book (3.7 Input processing:
 ip6_input() Function) the incoming network packet processing in ip6_input
 should use the routing table to look up whether packets are of relevance
 for an interface - but the code base has diverged significantly since then
 including vnets for jails which makes me wonder if this is a bug.  However

I've not closely followed the most recent version of FreeBSD IPv6
code, but the use of the routing table in ip6_input in the original
KAME implementation had nothing to do with the strong host model.  It
was just for faster determination of whether an incoming packet is
destined to *any* of host's IPv6 addresses (on any interface, which
may or may not be identical to the receiving interface).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipv6, stateful config and non-default prefixlen

[JINMEI Tatuya / 神明達哉]

At Fri, 18 Mar 2011 21:35:16 +0500,
Eugene M. Zheganin eug...@zhegan.in wrote:

  You don't say what prefix length rtadvd is sending or that you're seeing
  in the wireshark log.
 
  Do you have prefixlen#120 in your rtadvd.conf?

Whether using /120 is a good idea might have to be debated, but anyway..

 %ps ax | grep dhc
 25672  ??  Is 0:00,01 /usr/local/sbin/dhclient -6 nfe0

I guess this is ISC DHCP.  It always assumes /64 and (effectively)
installs the given address this way:

# ifconfig nfe0 inet6 fd00::7d2/64 alias

A possible workaround is to rewrite dhclient-script to hardcode
/120.  Another solution is to use a different DHCPv6 client
implementation.  (Although it's not actively maintained/enhanced
recently) I believe WIDE DHCPv6 should work for your purpose:
http://sourceforge.net/projects/wide-dhcpv6/

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipv6 route extension header

[JINMEI Tatuya / 神明達哉]

At Tue, 10 Aug 2010 14:26:09 +0530,
Saurav Dasgupta saurav.dasgu...@aricent.com wrote:

 Why there is no support for route extension header in freebsd v7.2 ?
 From which release we have the code that support route extension header ?

If you mean the type 0 routing header, see RFC5095.

I don't know exactly from which version it's removed, but it should be
around mid 2007.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Processing IPv6 Router Advertisements

[JINMEI Tatuya / 神明達哉]

At Tue, 19 Jan 2010 08:59:56 -0300,
Fernando Gont ferna...@gont.com.ar wrote:

 RA messages seem to be required to have a Source Address in the
 fe80::/32 prefix, rather than in the fe80::/10 prefix. That is, the
 first 32 bits of the IPv6 Source address must be fe80:, or else the
 message is dropped (at least, no changes are made to the destination
 cache or the neighbor cache).
 
 Can anybody confirm this one, or correct me if I am wrong?

Your understanding of what's happening is correct, and it's an
intentional behavior.  The relevant part of the source code is the
following snippet of:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/ip6_input.c?rev=1.81.2.4;content-type=text/plain

/*
 * Disambiguate address scope zones (if there is ambiguity).
 * We first make sure that the original source or destination address
 * is not in our internal form for scoped addresses.  Such addresses
 * are not necessarily invalid spec-wise, but we cannot accept them due
 * to the usage conflict.
 * in6_setscope() then also checks and rejects the cases where src or
 * dst are the loopback address and the receiving interface
 * is not loopback.
 */
if (in6_clearscope(ip6-ip6_src) || in6_clearscope(ip6-ip6_dst)) {
ip6stat.ip6s_badscope++; /* XXX */
goto bad;
}

So you should see the statistics counter named violated scope rules
(or something like that) in netstat -p ip6 -s increase as you send
these packets.

The superficial reason why such packets are dropped is because it
doesn't meet the specified format of link-local addresses as described
in RFC4291:

2.5.6.  Link-Local IPv6 Unicast Addresses

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10 |
   |  bits| 54 bits |  64 bits   |
   +--+-++
   |111010|   0 |   interface ID |
   +--+-++

The real reason is described thoroughly in a book I coauthored.  I
believe you told me you had a copy of it, and assuming I'm correct,
see Section 2.9.3:-)

I admit this behavior is suboptimal for the spirit of be liberal in
what you accept, but, as you probably know, it shouldn't cause any
interoperability trouble in practice.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 fragmentation weirdness

[JINMEI Tatuya / 神明達哉]

At Thu, 14 May 2009 14:42:35 -0700,
Kevin Oberman ober...@es.net wrote:

 I then captured the ICMP and discovered that the kernel was fragmenting
 all of them! Worse, the fragment was sent out before the ICMP! What the
 heck is going on! Thread synchronization?
 
 When I captured the packets (via tcpdump -s0 -w file host ftp.funet.fi), the
 first things captured is an IPv6 fragment of 72 bytes. 3 microseconds
 later, I get the ICMP6 packet of 1294 bytes. This pattern is consistent
 over repeated packets. This was with -s 1234 for a total ICMPv6 size of
 1282.
 
 First, why is the kernel fragmenting this at all as it fits in the
 interface MTU?

Do you mean why ping6 has the kernel fragment echo requests at 1280
bytes by default (i.e., when invoked without -m)?  If so, that's
because if a large echo request triggers path MTU discovery, some
initial requests won't be replied (recall that IPv6 routers never
fragment packets by themselves; they always drop too-large packet with
returning an ICMPv6 error).

 Second, why the heck is the fragment going out first? This should be OK,
 but I suspect many firewalls (which are often not happy with fragments)
 are not likely to pass a fragment which precedes the initial frame.

Do you mean, for example, the kernel sends out a fragment with a non-0
offset before the 0-offset one?  I can't believe this.  If I tried
% ping6 -s 1300 www.isc.org
from a FreeBSD 6.3 host, I saw this:

08:22:04.821171 IP6 2001:200:0:8002:203:47ff:fea5:3085  2001:4f8:0:2::d: frag 
(0|1232) ICMP6, echo request, seq 0, length 1232
08:22:04.821181 IP6 2001:200:0:8002:203:47ff:fea5:3085  2001:4f8:0:2::d: frag 
(1232|76)

(captured on the sending host).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 duplicate address detection

[JINMEI Tatuya / 神明達哉]

At Tue, 05 May 2009 11:40:12 -0700,
Bob Van Zant b...@veznat.com wrote:
 
 I'm working on a piece of software that, among other things, allows an
 administrator to easily configure IPv6 interfaces on a FreeBSD host. I've
 run into a problem where whenever I reconfigure an interface with an IPv6
 address FreeBSD marks the new address as being a duplicate.
 
 The problem is that I'm following RFC 2461 [1] in that I send an unsolicited
 neighbor advertisement to ff02::1 immediately after configuring the
 interface.

I'm afraid we need clarification first...what do you mean by
reconfigure an interface with an IPv6 address?  Do you mean adding a
new IPv6 address to an interface?  If so, I'm not sure why you
referred to the following part of RFC2461 (btw the RFC was updated by
RFC4861):

 [1] RFC 2461 section 7.2.6 paragraph 1:
 
In some cases a node may be able to determine that its link-layer
address has changed (e.g., hot-swap of an interface card) and may
wish to inform its neighbors of the new link-layer address quickly.

this example talks about the case where the link-layer address changes
for an existing address, not where a new address is configured.

Could you elaborate?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 duplicate address detection

[JINMEI Tatuya / 神明達哉]

At Wed, 06 May 2009 15:49:45 -0700,
Bob Van Zant b...@veznat.com wrote:

  I'm afraid we need clarification first...what do you mean by
  reconfigure an interface with an IPv6 address?  Do you mean adding a
  new IPv6 address to an interface?  If so, I'm not sure why you
  referred to the following part of RFC2461 (btw the RFC was updated by
  RFC4861):

 We have a crude form of NIC pairing in our software. We allow someone to
 logically pair two interfaces together. This is implemented by `ifconfig
 down` both interfaces, configure them both the same, then `ifconfig up` the
 primary interface. We then monitor the link state of the primary interface.
 If the state goes to down, we `ifconfig down` the primary NIC and then
 `ifconfig up` the secondary NIC. This has the effect of changing the link
 layer address associated with a given IPv6 address. After we do this we send
 out the unsolicited NA to update whatever switch we're plugged into.

Okay, thanks for the explanation.  But I still don't understand one
thing: why is DAD triggered for the address on the secondary NIC?
Unless someone has changed the code recently, the FreeBSD
(KAME-derived) IPv6 stack shouldn't trigger DAD for an existing
address simply because the interface becomes 'up' (this behavior may
be debatable per se, but that's a different question).  Did you
perhaps make the address tentative by hand after configuring the
address?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 duplicate address detection

[JINMEI Tatuya / 神明達哉]

At Wed, 06 May 2009 17:17:52 -0700,
Bob Van Zant b...@veznat.com wrote:

 I guess that changes my question quite a bit. If you randomly fire off an
 unsolicited NA right after configuring an interface should that cause a DAD
 failure?

Actually, in that case you shouldn't send out the NA in the first
place because you're in the middle of DAD, trying to confirming the
uniqueness of the target address.  If you want to send an unsolicited
NA for an address on which DAD is performed for any reason, you should
wait until DAD is completed.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Request feedback on IPv6 multicast listen on ::

[JINMEI Tatuya / 神明達哉]

At Fri, 01 May 2009 18:33:50 +0100,
Bruce Simpson b...@incunabulum.net wrote:

 During the MLDv2 refactoring, I removed some old KAME code which 
 supports the ability to listen to *all* multicast groups.
 It isn't clear to me whether this code was still in use, and I couldn't 
 find information about it in the normative RFCs (2292, 3542) for IPv6 
 stack implementation.
 
 This call needed super-user privileges to use, and I'm not sure if 
 anything is actually using it. Can anyone out there with possible 
 exposure to it clarify?

I believe you can safely remove it.  The KAME repository version of
that code was already deprecated long time ago.  See the change for
rev.1.433 at:
http://orange.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_output.c

I also noted this strange behavior in a book about the KAME
implementation:

3684:   mreq = mtod(m, struct ipv6_mreq *);
3685:   if (IN6_IS_ADDR_UNSPECIFIED(mreq-ipv6mr_multiaddr)) {
3686:   /*
3687:* We use the unspecified address to specify to 
accept
3688:* all multicast addresses. Only super user is 
allowed
3689:* to do this.
3690:*/
3692:   if (suser(p))
3696:   {
3697:   error = EACCES;
3698:   break;
3699:   }

3684–3699
  ipv6mr_multiaddr field must hold a valid IPv6 multicast
  address. The KAME implementation allows a privileged application to
  specify the IPv6 unspecified address.  While the intention may be to
  allow the socket to accept packets from any multicast address, the
  system does not actually behave that way. First, the
  IN6_LOOKUP_MULTI() macro does not have a special matching rule for the
  unspecified address. Secondly, in order to accept any multicast
  addresses on an interface, it is necessary to specify the promiscuous
  mode for the interface’s multicast filter, which will not actually be
  done in this case. Later versions of the KAME implementation removed
  this code and similar code that exists for IPV6_LEAVE_GROUP.

Hope this helps,

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: FD_SETSIZE (too many open file descriptors) + BIND

[JINMEI Tatuya / 神明達哉]

At Wed, 17 Dec 2008 15:20:02 +0200,
Ott Köstner o...@zzz.ee wrote:

 named[63198]: socket: too many open file descriptors
 last message repeated 26 times
 
 Bind version is: BIND 9.4.2-P2

Please try BIND 9.4.3.  Even with all attempts to mitigate the trouble
and with tweaking parameters, 9.4.2-P2 still has a fundamental
limitation on performance.  It should work for the vast majority of
users, but you really need 9.4.3 if your server is very busy.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: FD_SETSIZE (too many open file descriptors) + BIND

[JINMEI Tatuya / 神明達哉]

At Wed, 17 Dec 2008 21:27:58 +0200,
Artyom Viklenko ar...@aws-net.org.ua wrote:

 BIND 9.5.0-P2 already in ports and seems working well.
 Giv it a try.

In this context 9.5.0-P2 won't help.  All 9.x.y-P[12] versions have
the same problem.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

[JINMEI Tatuya / 神明達哉]

At Tue, 15 Jul 2008 14:13:11 +0200,
Thomas Vogt [EMAIL PROTECTED] wrote:

 Since i updated my FreeBSD 6.3 dns server with the latest bind version 
 in the ports (dns/bind94) my system is flooding my log with too many 
 open file descriptors messages.
 
 Is there something i can do?

How many sockets is named actually using while it makes this log
message?  Try, e.g,
% sockstat | grep named | wc -l

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

[JINMEI Tatuya / 神明達哉]

At Tue, 15 Jul 2008 23:09:30 +0200,
Kris Kennaway [EMAIL PROTECTED] wrote:

  If that's regularly happening, I'm afraid recent P1 versions don't
  handle that well, and recommend you try 9.4.3b2 ore 9.5.1b1.
 
 Or increase the number of file descriptors as a workaround, per my email :)

Does FreeBSD allow an application to increase FD_SETSIZE (at its
compilation time)?  I thought FD_SETSIZE defaults to 1024.  Any
9.x.y-P1 versions can only open FD_SETSIZE sockets, regardless of the
# FDs limit.

Besides, I guess that the P1 versions severely suffer from heavy
overhead of select(2) when it regularly opens more than 1000 sockets.
Even if 'too many open file' messages are gone, many users won't
accept the increased load due to the overhead.  Beta versions use
kqueue, eliminating the fundamental overhead as well as the (too low)
limitation of # of descriptors.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

[JINMEI Tatuya / 神明達哉]

At Tue, 15 Jul 2008 15:12:31 -0700,
Bakul Shah [EMAIL PROTECTED] wrote:

  Besides, I guess that the P1 versions severely suffer from heavy
  overhead of select(2) when it regularly opens more than 1000 sockets.
  Even if 'too many open file' messages are gone, many users won't
  accept the increased load due to the overhead.  Beta versions use
  kqueue, eliminating the fundamental overhead as well as the (too low)
  limitation of # of descriptors.
 
 Or more portably you can use poll(2).

I've not played with poll(2) in BIND9, but as far as I understand it,
it doesn't solve the fundamental overhead issue here.  For example,
the application should examine all possible descriptors even if only a
few of them are readable.

Anyway, since this is a FreeBSD specific list, I believe we can safely
assume the existence of kqueue, unless we are talking about a very old
version:-)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)

[JINMEI Tatuya / 神明達哉]

At Tue, 15 Jul 2008 16:09:17 -0700,
Bakul Shah [EMAIL PROTECTED] wrote:

 IIRC, when poll() returns n, you only look at the first n
 values in the pollfd array so it is a win when you expect a
 very small number of fds to be ready.  In the select case you
 have to test the bit array until you see the last ready fd.

% uname -a 
FreeBSD opt1.jinmei.org 7.0-RC1 FreeBSD 7.0-RC1 #0: Fri Jan 25 15:17:04 PST 
2008 [EMAIL PROTECTED]:/usr/src/sys/amd64/compile/GENERIC_NOSMP  amd64
(please ignore RC1:-)

% cat polltest.c
(omitted here, see below)

% cc -o polltest polltest.c

% ./polltest
poll returned: 1
999th socket is ready (fd=1002)

Perhaps You're probably confused poll(2) with /dev/poll.  The latter
behaves as you described (but is not portable as poll(2)).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

out put of polltest.c
#include sys/types.h
#include sys/socket.h

#include netinet/in.h

#include stdio.h
#include stdlib.h
#include string.h
#include poll.h

main()
{
int i, n;
struct pollfd pfds[1000];
struct sockaddr_in sin;
socklen_t sin_len;
char buf[16];

memset(pfds, 0, sizeof(pfds));

memset(sin, 0, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_len = sizeof(sin);
inet_pton(AF_INET, 127.0.0.1, sin.sin_addr);
for (i = 0; i  1000; i ++) {
if ((pfds[i].fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP))
 0) {
perror(socket);
exit(1);
}
if (bind(pfds[i].fd, (struct sockaddr *)sin, sizeof(sin))  0) 
{
perror(bind);
exit(1);
}
pfds[i].events = POLLIN; 
}

sin_len = sizeof(sin);
if (getsockname(pfds[999].fd, (struct sockaddr *)sin, sin_len)  0) {
perror(getsockname);
exit(1);
}

if (sendto(pfds[999].fd, buf, sizeof(buf), 0, (struct sockaddr *)sin,
   sizeof(sin))  0) {
perror(sendto);
exit(1);
}

n = poll(pfds, 1000, -1);

printf(poll returned: %d\n, n);

for (i = 0; i  1000; i++) {
if ((pfds[i].revents  POLLIN) != 0) {
printf(%dth socket is ready (fd=%d)\n, i, pfds[i].fd);
}
}

exit(0);
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6/IPv4 DNS resolver source

[JINMEI Tatuya / 神明達哉]

At Mon, 26 May 2008 18:49:35 -0400,
Steve Bertrand [EMAIL PROTECTED] wrote:

 Is there anyone here who can advise me where in the source tree I would 
 find the DNS resolver code that performs /A record lookups, and more 
 specifically, the fallback to A lookup if  fails?

Assuming you're considering getaddrinfo(), see res_queryN() in
lib/libc/net/getaddrinfo.c.

BTW: fallback does not really accurately describe the behavior.
When AF_UNPSEC is specified, both  and A queries are issued,
whether or not the  query fails.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPPROTO_DIVERT and PF_INET6

[JINMEI Tatuya / 神明達哉]

At Sat, 3 May 2008 20:00:43 +1000,
Edwin Groothuis [EMAIL PROTECTED] wrote:

 Before somebody shoots me down on it: I know that ipfw_divert() is
 not suitable for IPv6 packets.

[snip]

 which is what I expected. So why doesn't this get displayed for the
 IPv6 sockets?

I don't know much about IPDIVERT, but it seems to me this is simply
because the IPv6 stack (sys/netinet6) doesn't support divert sockets.
So opening an AF_INET6 socket with the protocol being IPPROTO_DIVERT
(which is unknown)

sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT);

matches a wildcard protosw

/* raw wildcard */
{
.pr_type =  SOCK_RAW,
.pr_domain =inet6domain,
.pr_flags = PR_ATOMIC|PR_ADDR,
.pr_input = rip6_input,
.pr_output =rip6_output,
.pr_ctloutput = rip6_ctloutput,
.pr_usrreqs =   rip6_usrreqs
},

whose pr_protocol is implicitly set to 0, which is (accidentally)
interpreted by lsof as HOPOPTS.

This should provide a direct answer to you question of why?  But I
suspect the underlying question is why divert sockets aren't supported
for IPv6.  I don't know why.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Strange resolver behavior

[JINMEI Tatuya / 神明達哉]

At Tue, 12 Feb 2008 17:31:57 -0800,
Xin LI [EMAIL PROTECTED] wrote:

 It looks like that certain (mis)configuration by the baidu.com DNS
 administrators has caused this, but I have no clue why our resolver
 would return NXDOMAIN after it gets a positive response?  (Yes, I know
 that _ is not appropriate for domain names :)

(I've read the entire thread, but since there still seems to be some
confusion, so I'm responding to the very original post of the thread).

This problem is not related to the _.

The fundamental problem is, as Edwin already pointed out, (one of) the
authoritative server(s) of the shifen.com zone returns NOTIMP for MX
of ps_other.a.shifen.com (this is a non-compliant behavior; see
RFC4074 - though the main focus of this RFC is , not MX).  So,
what should have happened is:
 
 Received 127 bytes from 127.0.0.1#53 in 0 ms
 [EMAIL PROTECTED] ~ host ps_other.a.shifen.com
 ps_other.a.shifen.com has address 202.108.22.46

So far, fine.

 Host ps_other.a.shifen.com not found: 3(NXDOMAIN)

At this point host first queried for MX of ps_other.a.shifen.com.
This failed with NOTIMP or SERVFAIL (the latter would be returned from
a caching server).  If your /etc/resolv.conf contains a domain or
search directive (which I guess is the case), (recent versions of)
host then tried the same query using the specified domain name(s),
e.g., ps_other.a.shifen.com.isc.org.  This normally resulted in an
NXDOMAIN error, which you saw as the final output.

You should be able to see this process by host -v dict.baidu.com.

It should also be noted that this is irrelevant to the resolver
implementation in libc.  The host command uses its own parser of
/etc/resolv.conf and resolution routine and doesn't rely on the libc
version of resolver.

Finally, one thing I still don't understand is this symptom:

 Em...  That's fine I think, it does not seem to be the MX to cause the
 problem, though.  I have tried to visit 'dict.baidu.com' in Firefox and
 it told me that the name can not resolve.  tcpdump indicates that the
 server has respond the A RR but resolver still queries ...

As far as I can see, there's no problem in resolving  (although
the response is negative) unlike the MX case.  Can you show the exact
output of tcpdump?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Text for IPv6 Scope

[JINMEI Tatuya / 神明達哉]

At Sat, 5 Jan 2008 12:52:53 +0100,
Michael Tuexen [EMAIL PROTECTED] wrote:

 aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't
 the site-local stuff be removed?

RFC3879 only deprecates site-local *unicast* addresses; the notion of
site-local is still valid for multicast addresses (this is a very
common misunderstanding about the deprecation of site-local).  So we
should not remove IPV6_ADDR_SCOPE_SITELOCAL from in6.h.

Going back to the original question of this thread, I don't have a
strong opinion on whether it's a good idea to show scope types in
alphabets.  But I'd point out that it might break convention (further)
that an output of ifconfig can often be used as an input, too.  For
example, if we have:

ed0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet6 fe80::2c4:77ff:fea1:55ed%ed0 prefixlen 64 scopeid 0x1 
inet 10.211.55.11 netmask 0xff00 broadcast 10.211.55.255
inet6 2001:db8::1234 prefixlen 64 
ether 00:c4:77:a1:55:ed
media: Ethernet autoselect (10baseT/UTP)

then we could do
# ifconfig ed0 `ifconfig ed0 | grep 'inet6 2001'`

Adding the scope type text would break this convention (at least if
implemented naively).  I don't know whether people care about this
much, though.  Also, we've actually already broken this convention by
showing 'scoped 0xXX' for link-locals, so it may not be a big deal any
more.

BTW, the patch in its current form is not correct in that scopeid is
the scope index of a specific type of scope, not the scope type
(link-local, site-local, etc).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

a format error in pf_print_host()

[JINMEI Tatuya / 神明達哉]

(This should probably be reported to an OpenBSD forum, but I'm not
subscribing to any of the lists, so I'm posting this to freebsd-net.
I believe pf maintainers watch this list, too...)

I've found a minor error in pf_print_host() which is revealed for some
time of IPv6 addresses.  This routine always (perhaps unintentionally)
assumes abbreviate-able consecutive zero's, so, for example, it
formats 1:2:3:4:5:6:7:8 as :2:3:4:5:6:7:8.  This can be confirmed
by the sample code attached to this message by
- saving the file as e.g. foo.c
- cc -o foo foo.c
- ./foo 1:2:3:4:5:6:7:8

I've also attached a proposed patch to this problem.  The diff was
made against 6-STABLE, but it's probably applicable to other versions.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: a format error in pf_print_host()

[JINMEI Tatuya / 神明達哉]

At Tue, 20 Nov 2007 23:17:43 +0900,
JINMEI Tatuya [EMAIL PROTECTED] wrote:

 formats 1:2:3:4:5:6:7:8 as :2:3:4:5:6:7:8.  This can be confirmed
 by the sample code attached to this message by
 - saving the file as e.g. foo.c
 - cc -o foo foo.c
 - ./foo 1:2:3:4:5:6:7:8
 
 I've also attached a proposed patch to this problem.  The diff was
 made against 6-STABLE, but it's probably applicable to other versions.

Hmm...apparently attachments were stripped.  I'm directly copying the
file contents below:

=== sample program ===
#include sys/param.h
#include sys/socket.h

#include netinet/in.h

#include arpa/inet.h

#include stdlib.h
#include string.h
#include stdio.h

struct pf_addr {
union {
struct in_addr  v4;
struct in6_addr v6;
u_int8_taddr8[16];
u_int16_t   addr16[8];
u_int32_t   addr32[4];
} pfa;  /* 128-bit address */
#define v4  pfa.v4
#define v6  pfa.v6
#define addr8   pfa.addr8
#define addr16  pfa.addr16
#define addr32  pfa.addr32
};

static void
pf_print_host(struct pf_addr *addr, u_int16_t p, sa_family_t af)
{
switch (af) {
case AF_INET: {
u_int32_t a = ntohl(addr-addr32[0]);
printf(%u.%u.%u.%u, (a24)255, (a16)255,
(a8)255, a255);
if (p) {
p = ntohs(p);
printf(:%u, p);
}
break;
}
case AF_INET6: {
u_int16_t b;
u_int8_t i, curstart = 255, curend = 0,
maxstart = 0, maxend = 0;
for (i = 0; i  8; i++) {
if (!addr-addr16[i]) {
if (curstart == 255)
curstart = i;
else
curend = i;
} else {
if (curstart) {
if ((curend - curstart) 
(maxend - maxstart)) {
maxstart = curstart;
maxend = curend;
curstart = 255;
}
}
}
}
for (i = 0; i  8; i++) {
if (i = maxstart  i = maxend) {
if (maxend != 7) {
if (i == maxstart)
printf(:);
} else {
if (i == maxend)
printf(:);
}
} else {
b = ntohs(addr-addr16[i]);
printf(%x, b);
if (i  7)
printf(:);
}
}
if (p) {
p = ntohs(p);
printf([%u], p);
}
break;
}
}
}

main(int argc, char *argv[])
{
struct pf_addr addr;

if (argc  2) {
fprintf(stderr, specify an address\n);
exit(1);
}

if (inet_pton(AF_INET6, argv[1], addr) != 1) {
fprintf(stderr, inet_pton failed for %s\n, argv[1]);
exit(1);
}
pf_print_host(addr, 0, AF_INET6);
putchar('\n');

exit(0);
}
=== sample program ===

=== patch for pf.c ===
Index: pf.c
===
RCS file: /home/ncvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.34.2.6
diff -u -r1.34.2.6 pf.c
--- pf.c23 Aug 2007 09:38:14 -  1.34.2.6
+++ pf.c20 Nov 2007 14:06:34 -
@@ -1211,7 +1211,7 @@
case AF_INET6: {
u_int16_t b;
u_int8_t i, curstart = 255, curend = 0,
-   maxstart = 0, maxend = 0;
+   maxstart = 255, maxend = 255;
for (i = 0; i  8; i++) {
if (!addr-addr16[i]) {
if (curstart == 255)
=== patch for pf.c ===
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: unknown problem with mx1.freebsd.org

[JINMEI Tatuya / 神明達哉]

At Fri, 12 Oct 2007 18:54:11 +0900,
Byung-Hee HWANG [EMAIL PROTECTED] wrote:

 Let me say this.. I just like all stuff around IPv6. And now I need one
 native IPv6 address for my FreeBSD box, which is email gateway. There
 was unknown problem related to IPv6 area between my FreeBSD box
 [2002:9be6:9d5d:1::1] and mx1.freebsd.org [2001:4f8:fff6::34]. 

I don't know if mx1.freebsd.org delays or refuses delivery when DNS
reverse lookup fails for the source of incoming connections, but
at least there are some problems in the delegation under
2.0.0.2.ip6.arpa: out of 4 authoritative servers,
ns-arin.6to4.nro.net seems to be down, and ns-ripe.6to4.nro.net
returns SEVFAIL.  You should probably contact [EMAIL PROTECTED],
which is the maintainer mail address according to the SOA record of
the 2.0.0.2.ip6.arpa zone.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: infinite loop in esp6_ctlinput()?

[JINMEI Tatuya / 神明達哉]

At Tue, 28 Aug 2007 10:15:31 +0800,
blue [EMAIL PROTECTED] wrote:

 When receiving a packet too big ICMP error message, FreeBSD will call 
 the ctlinput() function of the upper protocol. If the preceding packet 
 is an ESP  IPv6 packet, then FreeBSD will call esp6_ctlinput(). In 
 esp6_ctlinput(), pfctlinput2() will be executed to traverse all possible 
 upper protocols, and call their registered ctlinput() function. However, 
 that would call esp6_ctlinput() again since ESP is one of the upper 
 protocols! Then an infinite loop occurs!!

From a quick look at the code, there's a slight difference between the
IPSEC (netinet6/esp_input.c) and FAST_IPSEC (netipsec/ipsec_input.c)
implementations.  I suspect the loop doesn't occur at least for the
esp_input.c version.  Did you actually see the loop for both, or are
you guessing from the code?

 After comparing both IPSEC and FAST_IPSEC, the operations are exactly 
 the same. Is it a bug?

If it actually causes an infinite loop, it's a bug, of course.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: infinite loop in esp6_ctlinput()?

[JINMEI Tatuya / 神明達哉]

At Tue, 28 Aug 2007 19:49:11 +0800,
blue [EMAIL PROTECTED] wrote:

 According to the GDB backtrace, I think this is what I am talking about.
 
 Besides, this would result in infinite loop just by looking at the 
 codes. However, the author seems knowing the problem, too. The comments 
 in esp6_ctlinput() point out:
   /*
  * Although pfctlinput2 will call esp6_ctlinput(), there is
  * no possibility of an infinite loop of function calls,
  * because we don't pass the inner IPv6 header.
   */
 
 I am not sure what the description means. The behavior of 
 esp6_ctlinput() is the same in HEAD, too.

This means that variable 'ip6' should be NULL for the second time
esp6_ctlinput() is called in the esp_input.c (non-FAST IPSEC)
version.  It prevents the function calls from making an infinite loop.

On the other hand, the ipsec_input.c (FAST_IPSEC) version only seems
to check ip6ctlparam * ('d') is NULL, making the infinite sequence of
calls possible.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/115413: [ipv6] ipv6 pmtu not working

[JINMEI Tatuya / 神明達哉]

At Tue, 21 Aug 2007 16:16:51 +0200,
Jacek Zapala [EMAIL PROTECTED] wrote:

 Btw, how can I examine the route mtu cache? In older FreeBSD 
 netstat -ranW showed cloned routes and their mtus, but this is no longer
 the case with FreeBSD 6.2.

try
 sysctl net.inet.tcp.hostcache.list
and see the MTU column.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/115413: [ipv6] ipv6 pmtu not working

[JINMEI Tatuya / 神明達哉]

At Tue, 21 Aug 2007 18:35:05 +0200,
Daniel Hartmeier [EMAIL PROTECTED] wrote:

  But I'm not sure if I understood well - you suspect that only 8 bytes of
  tcp header are copied from the original tcp packet to the icmp message
  by the router?
 
 No, the router is only required (by the RFCs) to quote the first 8 bytes
 of the TCP header.

This is not true for IPv6.  From Section 2.4 of RFC4443:

   (c) Every ICMPv6 error message (type  128) MUST include as much of
   the IPv6 offending (invoking) packet (the packet that caused the
   error) as possible without making the error message packet exceed
   the minimum IPv6 MTU [IPv6].

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: A and AAAA DNS query process in getaddrinfo()?

[JINMEI Tatuya / 神明達哉]

At Fri, 10 Aug 2007 11:52:09 +0800,
blue [EMAIL PROTECTED] wrote:

 When looking into kame-20070801-freebsd54-snap, the function, 
 _dns_getaddrinfo(), defined in getaddrinfo.c, will check if the device 
 gets any IPv4/global IPv6 address before sending out any A/ query by 
 calling addrconfig() if the user does not specify the family type 
 (AF_UNSPEC). However, FreeBSD-CURRENT (known is going to be FreeBSD7.0), 
 does not do the process.
 
 Do we need to do the same check before sending out the A/ query?

I'm afraid just asking this question without providing a context could
be misleading.  I guess this is a continuation of a thread of the
[EMAIL PROTECTED] list:

ftp://ftp.kame.net/pub/mail-list/snap-users/9541
ftp://ftp.kame.net/pub/mail-list/snap-users/9544

If so, we should discuss this with the understanding of why KAME-snap
version behaves that way, specifically referring to Section 3
(especially 3.4.1) of this document:
http://v6fix.net/docs/wide-draft-v6fix.en

We (KAME) thought the behavior was reasonable but we were also afraid
this might be too experimental to incorporate to *BSD release
versions at that time.  That's why it's not in the FreeBSD repository.
I'm interested in what others think on this.  If others think this
feature is reasonable, too, and want it, I'm happy to commit the
change to the FreeBSD repository.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/108197: [ipv6] IPv6-related crash if if_delmulti

[JINMEI Tatuya / 神明達哉]

At Tue, 22 May 2007 01:48:26 +0100,
Bruce M. Simpson [EMAIL PROTECTED] wrote:

  Responsible-Changed-From-To: freebsd-net-bms
  Responsible-Changed-By: andre
  Responsible-Changed-When: Sun May 13 18:36:25 UTC 2007
  Responsible-Changed-Why: 
  Send over to BMS.  He's active in that area and may have fixed the bug 
  already.
 
  http://www.freebsd.org/cgi/query-pr.cgi?pr=108197
 
 Sorry, but I have no time to look at this at the moment. Is someone else 
 free to look at it?
 The fix probably needs to be borrowed from the IPv4 code which adds an 
 address to an interface.

Recent changes to the head and [56] STABLE *may* fix the problem.
These just fix memory leak while the symptom rather seems to indicate
use-after-free, so I'm not sure if these really solve the problem;
however, the fix indeed affects (either good or bad) the same code
path that caused the problem shown in the PR, so it may happen to fix
this problem via some non trivial side effect.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/108197: [ipv6] IPv6-related crash if if_delmulti

[JINMEI Tatuya / 神明達哉]

At Tue, 22 May 2007 01:48:26 +0100,
Bruce M. Simpson [EMAIL PROTECTED] wrote:

  Synopsis: [ipv6] IPv6-related crash if if_delmulti
 
  Responsible-Changed-From-To: freebsd-net-bms
  Responsible-Changed-By: andre
  Responsible-Changed-When: Sun May 13 18:36:25 UTC 2007
  Responsible-Changed-Why: 
  Send over to BMS.  He's active in that area and may have fixed the bug 
  already.
 
  http://www.freebsd.org/cgi/query-pr.cgi?pr=108197

 
 Sorry, but I have no time to look at this at the moment. Is someone else 
 free to look at it?
 The fix probably needs to be borrowed from the IPv4 code which adds an 
 address to an interface.

Could you be more specific about the 'IPv4 code'?  I've briefly looked
at the both netinet and netinet6 code path shown in the PR but cannot
be sure about which change you meant.

Thanks,

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 Router Alert breaks forwarding

[JINMEI Tatuya / 神明達哉]

At Thu, 5 Apr 2007 16:25:47 +0100,
Andrew McDonald [EMAIL PROTECTED] wrote:

  The behavior looks reasonable, but I'd code it more explicitly with
  some comments so that the intent is clear and others can correctly
  modify it for future extensions.  A possible patch to implement it is
  pasted below.  One thing I'm not really sure is whether someone is
  using (or has used) other predefined alert values:
  
   1Datagram contains RSVP message.
   2Datagram contains an Active Networks message.
  
  (I guess you're now going to use values 3-35 per RFC3175).
  
  If there is a user, we need to be careful not to break compatibility.
 
 That patch looks good to me.
 
 I think RSVP is the only other potential current user (and most likely
 without RFC3175 support). There appears to be some basic support for
 IPv6 in the ISI RSVPd implementation (untouched since 1999), but from a
 quick look at the code it is not clear whether they actually use the
 IPv6 router alert anyway. It predates RFC3175. If you want to be very
 conservative in changing behaviour you might want to include RSVP, but
 it seems unlikely that anyone is using it.
 
 The only reference I know of for the Active Networks use is a published
 paper (and the reference in RFC2711). I don't know of any running code.

Okay, if no one else objects to it, I'll commit the change.

Thanks,

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 Router Alert breaks forwarding

[JINMEI Tatuya / 神明達哉]

At Wed, 4 Apr 2007 22:18:15 +0100,
Andrew McDonald [EMAIL PROTECTED] wrote:

 In the absence of a full fix, it would probably be a good idea to
 remove this unconditional check. This would avoid FreeBSD blocking IPv6
 packets with router alert set. However, I'm not sure if this would have
 an impact on MLD.

It does, so (while I see your point) the fix is not that trivial.

Just out of curiosity, do you have any specific application that
relies on the router alert option and suffers from the current
behavior?  Or are you just talking about stringent compliance with the
specification?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 Router Alert breaks forwarding

[JINMEI Tatuya / 神明達哉]

At Thu, 5 Apr 2007 09:16:39 +0100,
Andrew McDonald [EMAIL PROTECTED] wrote:

 Thinking about it a bit, there is a simple fix that leaves MLD working
 (but currently doesn't provide a way for other applications to use
 router alert). The IPv6 Router Alert Option (RAO) has a 16-bit value
 field. For MLD this is zero. Other uses would contain different values
 (as per RFC2711).
 
 rtalert contains the contents of this value field, or (u_int32_t)~0 if
 there is no router alert option. So, if we change the check to:
   /*
* accept the packet if a router alert option with value 0
* is included and we act as an IPv6 router.
*/
   if (rtalert == 0  ip6_forwarding)
   ours = 1;
 we'll only pick up packets containing ipv6 router alerts with value 0
 (i.e. MLD router alerted packets).

The behavior looks reasonable, but I'd code it more explicitly with
some comments so that the intent is clear and others can correctly
modify it for future extensions.  A possible patch to implement it is
pasted below.  One thing I'm not really sure is whether someone is
using (or has used) other predefined alert values:

 1Datagram contains RSVP message.
 2Datagram contains an Active Networks message.

(I guess you're now going to use values 3-35 per RFC3175).

If there is a user, we need to be careful not to break compatibility.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

Index: ip6_input.c
===
RCS file: /home/ncvs/src/sys/netinet6/ip6_input.c,v
retrieving revision 1.90
diff -u -r1.90 ip6_input.c
--- ip6_input.c 24 Feb 2007 11:38:47 -  1.90
+++ ip6_input.c 5 Apr 2007 13:57:21 -
@@ -657,11 +657,25 @@
nxt = hbh-ip6h_nxt;
 
/*
-* accept the packet if a router alert option is included
-* and we act as an IPv6 router.
+* If we are acting as a router and the packet contains a
+* router alert option, see if we know the option value.
+* Currently, we only support the option value for MLD, in which
+* case we should pass the packet to the multicast routing
+* daemon.
 */
-   if (rtalert != ~0  ip6_forwarding)
-   ours = 1;
+   if (rtalert != ~0  ip6_forwarding) {
+   switch (rtalert) {
+   case IP6OPT_RTALERT_MLD: 
+   ours = 1;
+   break;
+   default:
+   /*
+* RFC2711 requires unrecognized values must be
+* silently ignored.
+*/
+   break;
+   }
+   }
} else
nxt = ip6-ip6_nxt;
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: rtadvd(8) and deprecated prefixes

[JINMEI Tatuya / 神明達哉]

 On Mon, 05 Feb 2007 16:56:49 -0800, 
 Eugene M. Kim [EMAIL PROTECTED] said:

 Note that the two automatically configured addresses on em0 are still
 preferred, while the prefix 2001:470:1f01:3222::/64 is deprecated on the
 router.

 I believe rtadvd(8) should advertise deprecated on-link prefixes with
 pltime of 0, but I still wanted to know what other people think about
 this before working on actual code.  So, here is the question: Is this
 really something to be fixed?

I'm pretty sure different people have different opinions on this
matter, but I personally think we should not try to fix it.

This feature originally intended to make rtadvd as much
configuration-free as possible in the most typical cases, that is, all
addresses on the router is configured by hand and the associated
prefixes are advertised with the default parameters defined in
RFC2461.  This is because why rtadvd does not allow the administrator
to specify just prefix lifetimes while letting the daemon get the
prefixes from the kernel.  So, treating a prefix lifetime of 0
separately is at least against the original design policy (believe me,
I'm confident because it's me who implemented this:-)

Also, once we open the Pandora's box, we'll encounter all other
non-default issues that beg customized behavior or require detailed
considerations on corner cases.  One example is to allow the user to
specify the lifetimes (without specifying prefixes).  We might also
want to have rtadvd follow decreasing lifetimes in real time.  Others
may want to restrict the advertised prefixes to some subset of ones
retrieved from the routing table, etc, etc.

So, (again) I'd personally keep the current feature and requires the
administrator to configure the router explicitly to handle any
non-default cases.  (If we agree on that) we may have to note in the
man page about the implementation policy, though.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[JINMEI Tatuya / 神明達哉]

 On Sun, 21 Jan 2007 09:32:44 +0200, 
 John Hay [EMAIL PROTECTED] said:

 There's another workaround for people stuck in this situation and who
 aren't in a position to try this diff.  That is to manually install
 the host route like this:
 
 # route add -host -inet6 :::::2 -interface gif0 -nostatic 
 -llinfo
 
 Comments?

 Well it seems that even my stuff does not always work perfectly with that
 change (1.48.2.15), so maybe we should revert it and I will search for
 yet other ways to make FreeBSD's IPv6 code to actually work for our stuff.

 My stuff is a wireless IPv6 only network running in adhoc mode with
 olsrd as the routing protocol. The problem is that all nodes on a subnet
 cannot see each other, so olsrd needs to add routes to a node through
 another node. Sometimes, just to complicate matters a little more, you
 would want to have more than one network card in a host, all with the same
 subnet address. (For instance on a high site, with sector antennas.)

 The case that I found that still does not work reliably, is if olsrd add
 the route and route is not immediately used, then the nd code will time
 it out and remove it.

I think I'm responsible for the troubles.  I've been thinking about
how to meet all the requests, and concluded that it's more complicated
than I originally thought.

I've come across an idea that may solve the problems, but I'll need
more time to implement and test it.

At the moment, I suggest reverting the 1.48.2.16 change for those who
simply wanted a gif to work.

Regarding the OLSRD stuff, I'd like to know more specific features
that are sought.  For example,

- what should happen if link-layer address resolution fails?  Should
  then entry be removed?  Probably not according to your description
  above, but what would you expect the entry to become in this case?

- once the link-layer address is resolved for the entry, should it be
  regarded as permanent without any ND state changes?  For example,
  should NUD be performed on the cache?  If yes, what should happen if
  NUD detects the neighbor is unreachable?  Should the entry be
  removed?  Again, probably not, but then what should it become?
  Keeping it with the same link-layer address?  Keeping it with an
  empty link-layer address?  Others?  What if the neighbor is acting
  as a router (setting the router flag in NAs)?  Should destination
  caches using the now-unreachable router be removed as described in
  the protocol spec?  Or should the destination caches be intact?

I have my own speculation on these points, but I'd like to know what
the actual user(s) of these features want before taking any action
based on the speculation.

Thanks,

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: When IPv6 temporary addresses are regenerated?

[JINMEI Tatuya / 神明達哉]

 On Thu, 25 Jan 2007 14:09:28 +0100, 
 Frank Behrens [EMAIL PROTECTED] said:

 I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I 
 used sysctl 
 net.inet6.ip6.use_tempaddr=1. The temporary address is generated and 
 meanwhile expired. 

 Does anybody know, when this address is expected to be regenerated?

As described in RFC3041 (and in its successor draft),

   When a temporary address becomes deprecated, a new one should be
   generated.

(from section 3.4 of RFC3041).  FreeBSD should behave that way (on my
laptop running 6.2-PRERELEASE, I have two temporary addresses; one is
preferred and the other is deprecated).

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

p.s. if you want to get a useful answer, it's generally advisable not
to hide details as in xxx.xxx.xx.xx, especially when you are not
certain about some aspect of the matter - because such details are
often a key to the answer.  If you do not want to disclose your
internal information but want to get an answer, I'd recommend you to
reproduce the situation using prefixes for documentations/examples
like 192.0.2.0/24 and 2001:db8::/32 and show every detail.

 My current interface configuration is
 vlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 inet xxx.xxx.xx.xx netmask 0xff00 broadcast xxx.xxx.xxx.xxx
 inet6 fe80::211:::%vlan0 prefixlen 64 scopeid 0x5
 inet6 2xxx:::: prefixlen 64 anycast
 inet6 2xxx:::0:211:2fff:: prefixlen 64
 inet6 2xxx:::0:54b:5960:: prefixlen 64 deprecated 
 autoconf temporary pltime 0 vltime 509995
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ipv6 connection hash function wanted ...

[JINMEI Tatuya / 神明達哉]

 On Tue, 14 Nov 2006 20:20:47 +0100, 
 Max Laier [EMAIL PROTECTED] said:

  Any ideas?  Any papers that deal with this problem?
 
 Assuming you don't want to use one of the standard cryptographic
 ones (which I can imagine being a bit slow for something done
 per-packet), then one option might be to use a simpler hash that
 is keyed. Choose the key at boot/module load time and make it hard
 to produce collisions unless you know the key.

 That's exactly what I am looking for ... now I need someone[tm] - with 
 better Math-Knowledge than mine - to write such a thing down in a simple 
 formula :-) i.e. take those bits from there and there and XOR them with 
 your canary yada-yada-yada ...

If you want something whose behavior is mathematically guaranteed, I'd
recommend universal hashing as already suggested in this thread.

One example implementation is given below, assuming the hash key is
source and destination IPv6 addresses and transport layer ports(*).
As shown in the implementation, it's pretty simple and should run
reasonably fast.  Also, as long as the random values are reasonably
unpredictable, the expected probability of producing the same hash
value for arbitrarily-chosen two different keys is 1/65537.  In
general, for any prime number p as the value of LARGE_PRIME, this
probability is 1/p (so if 65537 is too large, we can use a smaller
number, e.g., 1009, depending on the desired balance between collision
risk and memory footprint for hash buckets).

(*)Technically, using in6_addr to represent an IPv6 address may not be
enough; we may want to take into account zone indices (sin6_scope_id)
as part of hash keys.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

#define HASHKEYLEN 38/* sizeof(in6_addr) * 2 + sizeof(in_port_t) * 2 */
#define LARGE_PRIME 65537

/*
 * This should be filled with unpredictable random values between 0
 * and LARGE_PRIME-1 at startup time.
 */
u_int32_t random_parameters[HASHKEYLEN];

u_int32_t
hash(struct in6_addr *saddr, struct in6_addr *daddr,
in_port_t sport, in_port_t dport)
{
int i, j = 0;
u_int32_t accumulated = 0;
u_char *cp;

for (i = 0; i  sizeof(*saddr); i++)
accumulated += saddr-s6_addr[i] * random_parameters[j++];
for (i = 0; i  sizeof(*saddr); i++)
accumulated += daddr-s6_addr[i] * random_parameters[j++];
cp = (u_char *)sport;
for (i = 0; i  sizeof(sport); i++)
accumulated += cp[i] * random_parameters[j++];
cp = (u_char *)dport;
for (i = 0; i  sizeof(dport); i++)
accumulated += cp[i] * random_parameters[j++];

return (accumulated % LARGE_PRIME);
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 IOL certification?

[JINMEI Tatuya / 神明達哉]

 On Thu, 09 Nov 2006 10:50:29 -0700 (MST), 
 M. Warner Losh [EMAIL PROTECTED] said:

 Does anybody know if the FreeBSD ipv6 stack has passed the IOL Silver
 or Gold levels from the University of New Hampshire?

I don't have a direct answer to this question, but you might be
interested in the fact that KAME snapshots that base the FreeBSD IPv6
stack passed IPv6-ready logo tests.  See http://www.ipv6ready.org/
for more details.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: PPP IPv6 prefix length and stateless autoconfiguration?

[JINMEI Tatuya / 神明達哉]

(sorry for the delayed response, been busy for a while...)

 On Tue, 17 Oct 2006 10:03:05 -0700, 
 Krejsa, Dan [EMAIL PROTECTED] said:

 This appears to make the autoconfiguration work fine, and I
 encountered no other connectivity issues in brief testing;
 but a coworker of mine noticed that ifconfig no longer showed
 the destination address, and I investigated and found the
 128-bit enforcement in in6_update_ifa().  This makes me somewhat
 nervous; but if configuring a PPP/IPv6 interface without an
 IPv6 destination address is the intended method of use,
 I'd be more comfortable with this.  Is that the standard
 way of doing things?

I don't know in which sense you mean standard, but in any event,
it's an implementation specific decision (not required by a protocol
specification).  I believe it's at least doesn't break any protocol
standard, or cause a problem in operation (except incompatibility with
an application or operation that has a different assumption as you
saw).

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: PPP IPv6 prefix length and stateless autoconfiguration?

[JINMEI Tatuya / 神明達哉]

 On Mon, 16 Oct 2006 15:19:55 -0700, 
 Krejsa, Dan [EMAIL PROTECTED] said:

 Some code in the in6_update_ifa() function in netinet6/in6.c
 enforces that if an IPv6 destination address is specified for
 an interface address, the interface must be point-to-point or
 loopback (fine), and the corresponding prefix length must be
 exactly 128 bits.

 The latter seems (at least naively) to conflict with 
 the definition in

   http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt

 that the interface identifier length for PPP interfaces is 64 bits, and
 correspondingly prefixes accepted from a router advertisement
 must also be 64 bits long; see section 5.5.3 in

   http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt

So shouldn't you simply specify the prefix length of 64 without
specifying the *destination* address of the p2p link?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Point-to-Point interfaces and routing

[JINMEI Tatuya / 神明達哉]

 On Thu, 05 Oct 2006 00:46:15 +0300, 
 Alexander Motin [EMAIL PROTECTED] said:

 I have found to myself strange behaviour and difference between routing 
 to IPs on ngX, tunX interfaces. I will be very grateful if somebody 
 explain me why it is working in such way or give me a link to some good 
 manual about this.

 I have 6.1-STABLE. Do preparations:
 Create two interfaces, ng0 (by ngctl) and tun0 (by running interactive ppp).
 Bring them down and then up with ifconfig.
 Now they looks like:
 ng0: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST mtu 1500
  inet6 fe80::211:2fff:fea9:7627%ng0 prefixlen 64 scopeid 0x4
 tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500
  inet6 fe80::211:2fff:fea9:7627%tun0 prefixlen 64 scopeid 0x3
  Opened by PID 11956

 Questions:
 1. If I look for the routing tables I see:
 fe80::211:2fff:fea9:7627%ng0  fe80::211:2fff:fea9:7627%ng0  UHL ng0
 fe80::211:2fff:fea9:7627%tun0 link#3UHL lo0

 So now I can ping ip on tun0, but can't on ng0. Why did they different 
 and what is right?

Which version of 6.1-STABLE are you using?  I guess this is due to a
bug that was fixed recently.  A fix was already MFC'ed to RELENG_6 on
September 29 (at rev. 1.51.2.10).

 3. mpd ppp daemon on interface up event adds route for the local ip to 
 the lo0. Is it right way? And how in theory it must work for IPv6?

At least we don't have to do that for IPv6.  The kernel (IPv6 stack)
is designed to install the loopback route for any local address,
whether it's on a p2p interface or not.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ipv6 host routes

[JINMEI Tatuya / 神明達哉]

 On Fri, 8 Sep 2006 18:15:14 +0200, 
 John Hay [EMAIL PROTECTED] said:

 With this and my FreeBSD/IPv6 port of olsrd I can run multiple wireless
 interfaces with the same IPv6 subnet and olsrd can make it all work.

I should have looked at it much earlier (sorry about the delay), but I
don't this change is correct.  This will easily bother statically
installed route (especially) on a point-to-point interface.

There seem to be some try-and-errors in the CURRENT branch, but even
the latest revision (1.69) has a bad side-effect.  For example, if you
statically install the following *host* route

# route add -inet6 2001:db8::abcd -host -interface gif0

the latest revision of kernel will eventually remove it due to
unreachability detection, which is unlikely what the administrator
wanted to see.

The key point here is whether the route is statically created or not.
And, if I understand your intent correctly, the host route you want to
install is not really static in that it can (or should) be removed
when it's detected to be unreachable, right?

If so, the correct change to the kernel is the patch attached below
(it's against RELENG_6 as of today, which is rev. 1.48.2.14).

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

Index: nd6.c
===
RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.48.2.14
diff -u -r1.48.2.14 nd6.c
--- nd6.c   20 Sep 2006 19:10:18 -  1.48.2.14
+++ nd6.c   2 Oct 2006 08:17:30 -
@@ -1315,7 +1315,7 @@
callout_init(ln-ln_timer_ch, 0);
 
/* this is required for ndp command. - shin */
-   if (req == RTM_ADD) {
+   if (req == RTM_ADD  (rt-rt_flags  RTF_STATIC)) {
/*
 * gate should have some valid AF_LINK entry,
 * and ln-ln_expire should have some lifetime
@@ -1392,8 +1392,6 @@
ip6_sprintf(llsol), error));
}
}
-   } else if (req == RTM_ADD  SDL(gate)-sdl_alen == 0) {
-   ln-ln_state = ND6_LLINFO_INCOMPLETE;
}
break;
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ipv6 host routes

[JINMEI Tatuya / 神明達哉]

 On Mon, 2 Oct 2006 13:56:06 +0200, 
 John Hay [EMAIL PROTECTED] said:

 The key point here is whether the route is statically created or not.
 And, if I understand your intent correctly, the host route you want to
 install is not really static in that it can (or should) be removed
 when it's detected to be unreachable, right?

 Maybe I should state what I want to achieve again.

I believe I already knew that.  Perhaps I was not really clear about
the point, but the important part is:

+ the code currently committed in the repository is not correct in
  that it has a bad side-effect (so whether my patch is correct or not
  it should be removed or fixed anyway)
+ the proposed change in my previous post should provide what you want
  to achieve without the side-effect

One subtle point is that the host route (a neighbor *cache* entry)
will be removed automatically in the kernel when that host is detected
to be unreachable via the Neighbor Unreachability Detection process.
This should be the case for the current code and for my patch.  The
process (daemon) that installed the host route will thus be
responsible for taking care of the automatic removal event, by
re-installing the route, or synchronizing internal data with the
kernel, etc.  This is what I intended to point out by saying it's not
really 'static'.

Am I now clear enough?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Zeroconfig and Multicast DNS

[JINMEI Tatuya / 神明達哉]

 On Thu, 24 Aug 2006 13:42:29 -0500, 
 Brooks Davis [EMAIL PROTECTED] said:

 Um...I'm not sure if this is even possible. Let's forget mDNS and
 go back to basic IP.
 Say a multi-homed host has two interfaces both configured with an
 address in the rage 169.254/16, say 169.254.1.1 and 169.254.2.1 and
 it wants to initiate a connection to 169.254.3.1, how on earth should
 it be able to tell on which side 3.1 is located? There might even be
 one 3.1 on both side that could be completely different hosts.

 You probably would need an extension similiar to the one for IPv6 LLAs.
 i.e. the %bge0 in fe80::2e0:81ff:fe31:9f00%bge0.

(I've not followed the discussion closely, so my apologize in advance
if this message reacts to an off-topic.)

Note that the '%bge0' notation works well thanks to the sin6_scope_id
field of the sockaddr_in6{} structure.  Since sockaddr_in{} doesn't
have such an additional member to solve the ambiguity, the extension
to the IPv4 addresses would not be that trivial.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: nd6_lookup prints bogus messages with point to point devices

[JINMEI Tatuya / 神明達哉]

 On Thu, 08 Jun 2006 17:51:49 -0700, 
 Bruce A. Mah [EMAIL PROTECTED] said:

 If memory serves me right, George V. Neville-Neil wrote:
 After way too long this has been tested and committed to HEAD, with an
 MFC timout of 1 week.  I have done only limited, aka, ping, testing of
 this fix.
 
 I am currently setting up my own outbound IPv6 network so that I can
 do more real world testing of such patches in future.
 
 Thanks George and JINMEI-san!  I've merged this patch into my local
 RELENG_6 tree and will give it a try on my IPv6 tunnel endpoint...will
 report back results.

 So far so good...no signs of those error messages after a workday's
 worth of uptime.  Although I can't claim to be a heavy IPv6 user, I
 would have noticed those messages by now with pre-patch code.  I'll keep
 an eye on it for a few more days, but if you don't hear anything from
 me, please count me as an the fix works for me.

I'm happy to hear that.  Thanks for the test and confirmation.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: nd6_lookup prints bogus messages with point to point devices

[JINMEI Tatuya / 神明達哉]

 On Mon, 22 May 2006 09:50:37 -0700, 
 George V. Neville-Neil [EMAIL PROTECTED] said:

 Could you try the patch attached below?  It's for 6.1-RELEASE, but I
 guess it's pretty easy to apply to CURRENT.
 
 The essential reason of this problem is that the latest kernel regards
 the destination address of a point-to-point interface as a neighbor
 wrt Neighbor Discovery while a neighbor cache entry is not created on
 configuring the interface with the addresses.  I believe it makes
 sense to treat the destination address as a neighbor, so the fix is to
 make sure that the cache entry is created when the interface is
 configured.

 I can apply and commit this after a bit of testing.

Thanks, please do to.  I believe the patch also fixes this problem
report:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/93220

So, could you also confirm this and give feedback to (or close) the
report?  (I'll send a follow-up message to the report by myself it
it's appropriate).

Thanks,

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: nd6_lookup prints bogus messages with point to point devices

[JINMEI Tatuya / 神明達哉]

 On Mon, 8 May 2006 08:58:41 +0200, 
 Ed Schouten [EMAIL PROTECTED] said:

 I'm seeing the messages on the machine in Eindhoven (running RELENG_6
 from a few days/weeks ago), but they also show up on my HEAD machine at
 home. Below is the output of `ifconfig gif0` on my machine at home:

 | gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280
 | tunnel inet 83.181.147.170 -- 193.109.122.244
 | inet6 fe80::202:a5ff:fe58:4927%gif0 prefixlen 64 scopeid 0x7 
 | inet6 2001:7b8:310::1 -- 2001:7b8:2ff:a4::1 prefixlen 128 

 As far as I know, the latest FreeBSD releases show an error message when
 assigning an address with a non-128 prefixlen.

Sorry for not responding sooner, but I think I've figured out the
problem.  I'm now testing a local patch to this problem, and will
report the details once I confirm the behavior.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 raw socket to send original udp

[JINMEI Tatuya / 神明達哉]

 On Mon, 08 May 2006 05:44:51 +0900 (JST), 
 Hideki Yamamoto [EMAIL PROTECTED] said:

 I wonder if IPv6 raw socket can be used only for ICMPv6.

No, you can use any non built-in protocols on an IPv6 raw socket.  In
fact, IPv6 PIM daemons use IPv6 raw sockets for IPPROTO_PIM.  But...

 I would like to use IPv6 raw socket for original udp packet.

you cannot do this, and, even if it's a PIM packet (for example), I'm
afraid the socket does not meet your requirement: you cannot specify
an arbitrary source address for the packets, which I guess is one of
your goals.  With the IPv6 socket API you can only specify a node's
own address as the source address of outgoing packets sent from an
AF_INET6 socket.

This is a deliberate design choice of the API (RFC2292 or RFC3542).  I
don't know the original intent of IP_HDRINCL, that is, whether it
intentionally allows the specification of an arbitrary source
address, but at least one clear purpose of this option is to allow the
user to specify the value of some specific fields of the IP header.
Since RFC3542 (and RFC3493) provide dedicated API knobs for this
purpose, however, we don't need to provide an IPv6 version of
IP_HDRINCL.

So, if a program needs to specify an arbitrary source IPv6 address for
outgoing packets, it should use other packet injection interface
such as BPF.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: raw ip paket sendto error

[JINMEI Tatuya / 神明達哉]

 On Mon, 10 Apr 2006 11:40:46 +0200, 
 Stefan [EMAIL PROTECTED] said:

 I'm trying to port my little application to the FreeBSD-system and  
 encountered some difficults I can't solve. The program is running  
 fine on SunOS, OpenBSD, Mac OS X and Debian GNU/Linux so I thought it  
 should run fine on FreeBSD too. Maybe I forget something and you can  
 help me out?

 The first problem I had was at the function getaddrinfo. If I don't  
 submit a hints struct I get an error like this:
   servname not supported for ai_socktype

 This is the source part where the error occured:

 if((getaddrinfoError = getaddrinfo(src_addr, src_port, NULL, src_ai))
 != 0) {
  fprintf(stderr, Error getaddrinfo (src address): %s\n,
  gai_strerror(getaddrinfoError));
  exit(EXIT_FAILURE);
  }

 When I changed it to use a hint like this:

 struct addrinfo hints;
 hints.ai_family = PF_UNSPEC;
 hints.ai_socktype = SOCK_DGRAM;
 hints.ai_flags = 0;
 hints.ai_protocol = 0;
 hints.ai_addrlen = 0;
 hints.ai_canonname = NULL;
 hints.ai_addr = NULL;
 hints.ai_next = NULL;

 The function runs fine like I expected. Why does this happen on  
 FreeBSD systems?

I guess in this case getaddrinfo() tried to match the specified
service (port) with a raw socket (for which there is no notion of
service), and returned an error.

BTW, when I tried the same test on Solaris 10 and OpenBSD 3.6 (and
NetBSD 2.0.1 for that matter), I saw the same error.  So, it seems the
current trend is to require a specific hint, and FreeBSD is not that
special.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: raw ip paket sendto error

[JINMEI Tatuya / 神明達哉]

 On Tue, 11 Apr 2006 10:52:31 +0200, 
 Stefan [EMAIL PROTECTED] said:

 Any suggestions for the second major problem?

Sorry, but nope.  But I guess if you can post a complete source code
(not a snippet of it) and arguments to the program that can reproduce
the problem, and identify the FreeBSD version, someone in this list
will identify the reason instantly.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Race condition in ip6_getpmtu (actually gif)?

[JINMEI Tatuya / 神明達哉]

 On Mon, 27 Feb 2006 14:03:01 -0600, 
 Craig Boston [EMAIL PROTECTED] said:

  Attached is a quick hack to protect the cached route with a mutex.  A
  better fix with less overhead would be to allocate the route in a local
  variable on the stack, and only copy it to the softc if route caching is
  enabled.  I'll run for a couple weeks with the patch and file a PR if
  that fixes it.
 
 I guess this problem was fixed with the following changes:
 
 http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_gif.c.diff?r1=1.57r2=1.58
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_gif.c.diff?r1=1.23r2=1.24

 Yes, it was.  I saw the changes in those files when I attempted to
 re-merge my patch after a cvsup.  I've currently been running with no
 panics for 12 days with rev 1.52.2.4 of if_gif.c and rev 1.22.2.2 of
 in6_gif.c.

Okay, thanks for the confirmation.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Changing time causes ipv6 panics

[JINMEI Tatuya / 神明達哉]

 On Sun, 12 Feb 2006 01:58:28 -0500, 
 Kris Kennaway [EMAIL PROTECTED] said:

 Are you sure you applied the patch?  In the 'patched' version of
 nd6.c, line 585 is blank, so at least it doesn't match the above
 backtrace.

 Sorry, you're right - what was happening was that I'd apply the patch,
 then go to build the kernel and realise the time was still wrong, then
 run ntpdate and it would panic again, and because of soft updates the
 patch hadn't been synced yet and it would be gone when I rebooted
 again.

 In fact I cannot seem to reproduce the panic with the patch
 successfully applied.

Okay, glad to hear that.  Thanks for reporting the problem and testing
the patch.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Changing time causes ipv6 panics

[JINMEI Tatuya / 神明達哉]

 On Fri, 10 Feb 2006 22:50:25 -0500, 
 Kris Kennaway [EMAIL PROTECTED] said:

 Sorry, not really (we've not got a test environment to reproduce it).
 But from a quick review of nd6.c, there seems to be one thing that is
 obviously wrong.  The possible bug has been there since rev. 1.19
 committed in April 2002.  We've been probably just lucky so far...
 
 Could you try the patch attached below?  We'll probably also need to
 apply this fix to 4.X and 5.X.

 The patch did not fix the panic.

Hmm, but this time the point where the panic happened should be
different.  Can you identify where it was?

 (a note about the patch: the first chunk is actually not related to
 the bug, but I could not miss the trivial typo)

 You missed the other one though :-)

That's right:-)  I was informed of that one off-list.

 - * However, from a stricter speci-confrmance standpoint, we should
 + * However, from a stricter spec-confrmance standpoint, we should
  ^o

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Changing time causes ipv6 panics

[JINMEI Tatuya / 神明達哉]

 On Sat, 11 Feb 2006 02:14:11 -0500, 
 Kris Kennaway [EMAIL PROTECTED] said:

  Sorry, not really (we've not got a test environment to reproduce it).
  But from a quick review of nd6.c, there seems to be one thing that is
  obviously wrong.  The possible bug has been there since rev. 1.19
  committed in April 2002.  We've been probably just lucky so far...
  
  Could you try the patch attached below?  We'll probably also need to
  apply this fix to 4.X and 5.X.
 
  The patch did not fix the panic.
 
 Hmm, but this time the point where the panic happened should be
 different.  Can you identify where it was?

 I reduced the hw.physmem size and was able to get a dump:

 (kgdb) frame 10

 #10 0x80333a86 in nd6_timer (ignored_arg=0x8059ab60) at 
 ../../../netinet6/nd6.c:585
 585 ia6-ia6_flags |= IN6_IFF_DEPRECATED;

Are you sure you applied the patch?  In the 'patched' version of
nd6.c, line 585 is blank, so at least it doesn't match the above
backtrace.

To make it very clear, I've put a copy of 'before' and 'after' the
patch to nd6.c at:

http://www.jinmei.org/nd6.c.orig
and
http://www.jinmei.org/nd6.c
respectively.

It seems you are still using nd6.c.orig, whose line 585 sets the
IN6_IFF_DEPRECATED flag.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Changing time causes ipv6 panics

[JINMEI Tatuya / 神明達哉]

 On Tue, 7 Feb 2006 00:45:02 -0500, 
 Kris Kennaway [EMAIL PROTECTED] said:

 I ran ntpdate on an amd64 system with ipv6 enabled and a skewed clock
 (ntpdate stepped it back by about an hour), and immediately got a
 use-after-free panic in ifaddr.  When I rebooted with memguard enabled
 on this malloc type and retried, I got this panic upon changing the
 date forward, then back, then forward again (also note the garbage
 return data from ntpdate):

 Has anyone looked at this?  This is on the TODO list for 6.1, so the
 sooner it can be resolved the better.

Sorry, not really (we've not got a test environment to reproduce it).
But from a quick review of nd6.c, there seems to be one thing that is
obviously wrong.  The possible bug has been there since rev. 1.19
committed in April 2002.  We've been probably just lucky so far...

Could you try the patch attached below?  We'll probably also need to
apply this fix to 4.X and 5.X.

(a note about the patch: the first chunk is actually not related to
the bug, but I could not miss the trivial typo)

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

--- nd6.c.orig  Tue Feb  7 18:58:04 2006
+++ nd6.c   Tue Feb  7 18:59:33 2006
@@ -547,7 +547,7 @@
/*
 * expire interface addresses.
 * in the past the loop was inside prefix expiry processing.
-* However, from a stricter speci-confrmance standpoint, we should
+* However, from a stricter spec-confrmance standpoint, we should
 * rather separate address lifetimes and prefix lifetimes.
 */
   addrloop:
@@ -578,8 +578,7 @@
 
if (regen)
goto addrloop; /* XXX: see below */
-   }
-   if (IFA6_IS_DEPRECATED(ia6)) {
+   } else if (IFA6_IS_DEPRECATED(ia6)) {
int oldflags = ia6-ia6_flags;
 
ia6-ia6_flags |= IN6_IFF_DEPRECATED;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

m_tag leak?

[JINMEI Tatuya / 神明達哉]

While tracking a different issue, I felt I just got confused.  From a
very quick look at m_freem() and m_free(), it looks there is a leakage
of m_tag.  This is the definition of m_freem() in rev. 1.160 of
uipc_mbuf.c:

void
m_freem(struct mbuf *mb)
{

while (mb != NULL)
mb = m_free(mb);
}

And the following is the definition of m_free() (defined in
sys/mbuf.h, rev 1.187)

static __inline
struct mbuf *
m_free(struct mbuf *m)
{
struct mbuf *n = m-m_next;

if (m-m_flags  M_EXT)
mb_free_ext(m);
else
uma_zfree(zone_mbuf, m);
return n;
}

Doesn't this mean an m_tag attached to the mbuf to be freed, if any,
will remain without any reference?  Perhaps I'm missing something very
trivial.  It would be appreciated if someone could clarify that.

Thanks,

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Changing time causes ipv6 panics

[JINMEI Tatuya / 神明達哉]

 On Sun, 15 Jan 2006 19:44:38 -0500, 
 Kris Kennaway [EMAIL PROTECTED] said:

 I ran ntpdate on an amd64 system with ipv6 enabled and a skewed clock
 (ntpdate stepped it back by about an hour), and immediately got a
 use-after-free panic in ifaddr.  When I rebooted with memguard enabled
 on this malloc type and retried, I got this panic upon changing the
 date forward, then back, then forward again (also note the garbage
 return data from ntpdate):

Which version of FreeBSD are you using?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: racoon with freebsd-4.11 crashes

[JINMEI Tatuya / 神明達哉]

 On Thu, 8 Dec 2005 05:03:38 + (GMT), 
 priya yelgar [EMAIL PROTECTED] said:

 Running racoon on a Freebsd-4.11 machine gives a
 kernel panic.
 I am using the racoon from ports directory which comes
 with the freebsd installation.

Can you provide a backtrace of the kernel core?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPSEC, Watchguard SOHO 6tc and racoon

[JINMEI Tatuya / 神明達哉]

 On Thu, 17 Nov 2005 12:21:17 +0200, 
 asko [EMAIL PROTECTED] said:

 I have tried also des encryption and sha1 authentication, agressive and 
 main mode, and so on, no joy ;-( It probably needs some specific tweaks?

 FreeBSD 5.4-RELEASE,  racoon-20050510a,  Watchguard SOHO 6 tc firmware 6.3

racoon was incorporated into ipsec-tools and is now maintained there.
The 'racoon' port under ports/security is going to be obsoleted, and
is not recommended to use (we are now asking a port maintainer for
obsoleting this port).  So, please first try ipsec-tools (which
includes its own version of racoon).  If you still have a problem, I'd
then recommend you to ask the ipsec-tools developer.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: issue with route

[JINMEI Tatuya / 神明達哉]

 On Thu, 2 Jun 2005 16:01:40 -0700, 
 Li, Qing [EMAIL PROTECTED] said:

 Then please send me your final patch including proposed 
 commit message for final review again.  After that, when no 
 more issues arise, you can go ahead and commit the change.
 
 Oh, BTW.  Don't be afraid when you get brucified.  Bruce' 

   Does anyone have a good .emacs that conforms to style(9) 
   that could share with me? 

   That might just save me a lot of pain from the 
   inevitable brucifixion.

I believe the built-in bsd style should meet most of the style
requirements (with GNU Emacs 21).  Try (c-set-style bsd) on your
.[ch] buffers (and put it in the c-mode-common-hook if it works).

The only hard part I can see with the bsd style is the four-space
indentation rule for the 2nd level:

=
 Indentation is an 8 character tab.  Second level indents are four spaces.
 If you have to wrap a long statement, put the operator at the end of the
 line.

 while (cnt  20  this_variable_name_is_too_long 
 ep != NULL)
 z = a + really + long + statement + that + needs +
 two + lines + gets + indented + four + spaces +
 on + the + second + and + subsequent + lines;
=

The bsd style would indent these lines as follows:

=
 while (cnt  20  this_variable_name_is_too_long 
ep != NULL)
 z = a + really + long + statement + that + needs +
 two + lines + gets + indented + four + spaces +
 on + the + second + and + subsequent + lines;
=


Are you perhaps asking for .emacs setting which conforms to this (the
four-space) style?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: issue with route

[JINMEI Tatuya / 神明達哉]

(I'm afraid we're going to an off-topic.  If this message needs a
response, we should perhaps do that off-list.)

 On Fri, 3 Jun 2005 15:40:14 -0700, 
 Li, Qing [EMAIL PROTECTED] said:

 Are you perhaps asking for .emacs setting which conforms to this (the
 four-space) style?

 Yes, do you have one ?

I'm using this one.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

(add-hook 'c-mode-common-hook
  (function
   (lambda ()
 (c-set-style bsd)
 (c-set-offset 'statement 'netbsd-knf-lineup-statement)
 (c-set-offset 'arglist-intro 'netbsd-knf-lineup-arglist)
 (c-set-offset 'arglist-cont 'netbsd-knf-lineup-arglist)
 (c-set-offset 'arglist-cont-nonempty 'netbsd-knf-lineup-arglist)
...;;(other personal settings)
)))

(defun netbsd-knf-lineup-arglist (langelem)
  (let ((syntax (car (c-guess-basic-syntax)))
(langelem-col (c-langelem-col langelem t))
(head)
)
(save-excursion
  (while (memq (car syntax)
   '(arglist-cont-nonempty statement-cont
   arglist-intro arglist-cont))
(goto-char (cdr syntax))
(setq syntax (car (c-guess-basic-syntax
  (if (eq (car syntax) 'statement)
  (goto-char (netbsd-knf-statement-head)))
  (beginning-of-line)
  (skip-chars-forward  \t)
  (+ (- (current-column) langelem-col) (/ c-basic-offset 2)

(defun netbsd-knf-statement-head ()
  (let ((cp (point)))
(save-excursion
  (backward-up-list 1)
  (cond ((netbsd-knf-after-for-loop-p (point))
 (beginning-of-line)
 (skip-chars-forward  \t)
 (point))
   (t cp)

(defun netbsd-knf-lineup-statement (langelem)
  (let ((syntax (car (c-guess-basic-syntax
(cond ((and (cdr syntax);to handle (comment-intro) (statement . xx)
(netbsd-knf-after-for-loop-p (cdr syntax)))
   (save-excursion
 (goto-char (cdr syntax))
 (beginning-of-line)
 (skip-chars-forward  \t)
 (+ (- (current-column) (c-langelem-col langelem t))
(/ c-basic-offset 2
(t 0

(defun netbsd-knf-after-for-loop-p (pos)
  True if POS is just after `for ('
  (save-excursion
(goto-char pos)
(condition-case ()
(progn (backward-word 1)
   (looking-at \\bfor ())
  (beginning-of-buffer nil
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: mping

[JINMEI Tatuya / 神明達哉]

 On Mon, 30 May 2005 14:15:34 +0200 (CEST), 
 Olivier Casasole [EMAIL PROTECTED] said:

 I would like to use mping under FreeBSD 5.3.
 mping seems to be installed in /kame directory but it
 doesn't work.

 Do you know why?
 Or do you know where i can find a version of mping?

Please be more specific.  As far as I know, pure FreeBSD 5.3 does not
contain the directory /kame.  (not at least on my 5.4-RELEASE box).
What do you mean by /kame directory?

Also, it doesn't work means almost nothing for getting useful help.
Please be more specific about the symptom, e.g, by copy-and-pasting
the command-line execution of mping and the results.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Code nit questions...

[JINMEI Tatuya / 神明達哉]

 On Thu, 12 May 2005 22:49:12 -0400, 
 [EMAIL PROTECTED] said:

 In a continuing effort to clean up some code nits in the IPv6 code
 I'd like to propose the following diffs.  There is a comment, starting
 with a *) explaining the problem and proposed fix.

Thanks for your continuous efforts.  Here are some comments.

 *) Insert proper return value checking.

in6_embedscope() should not fail in this context (so we could even
panic if it does), but you probably want to be very proactive by
eliminating as many (hidden) assumptions as possible.  If so, please
go ahead with the change, but then I'd rather check the return value
of in6_recoverscope() as well.

 *) Make sure that sro is also valid before de-referencing it.

Aside from the fact that sro is not a pointer type as Andre pointed
out, I'm not even sure whether the code around this point is correct
in the first place.  Rev. 1.30 of in6_src.c currently reads:

struct route_in6 sro;
struct rtentry *rt = NULL;

if (ro == NULL) {
bzero(sro, sizeof(sro));
ro = sro;
}

if ((error = in6_selectroute(dstsock, opts, mopts, ro, retifp,
 rt, 0)) != 0) {
if (rt  rt == sro.ro_rt)
RTFREE(rt);
return (error);
}

So, can't sro.ro_rt be bogus when ro != NULL and in6_selectroute()
fails?

 @@ -667,7 +667,7 @@
* (this may happen when we are sending a packet to one of
*  our own addresses.)
*/
 - if (opts  opts-ip6po_pktinfo 
 + if (ifp  opts  opts-ip6po_pktinfo 
   opts- ip6po_pktinfo-ipi6_ifindex) {
   if (!(ifp-if_flags  IFF_LOOPBACK) 
 ifp-if_index !=

This one does not seem to harm, although ifp can probably be never
NULL in this context as commented around this part (but again, you
probably want to be very proactive, then it's fine).

 *) Make sure that rule is valid before dereferencing it.

(I don't know much about the ip6_fw implementation, so my comment is
not based on any expertise of my own as a KAME developer.)

Although the check does not seem to harm per se, it looks to me that
rule can never be NULL based on the logic of the big for loop above
this point.  In fact, the code has an assertion check which detects
almost the same erroneous condition:

#ifdef DIAGNOSTIC
/* Rule 65535 should always be there and should always match */
if (!chain)
panic(ip6_fw: chain);
#endif

So, there seem to be some inconsistency about unexpected failure.

 *) Do not bcopy if the pointer is NULL, whether or not canwait was
set.

Hmm...can't we assume malloc() returns a valid (non NULL) pointer if
its fourth argument is not M_NOWAIT?  If we can (i.e, it's a
function's feature), ip6po_nexthop == NULL  canwait != M_NOWAIT
should indicate a serious bug within malloc() or some other parts of
the kernel.  So I'm not sure if it's really a good idea to pretend
that the bug didn't exist...

BTW: if you really want to go with this change, you'll also want to
make the same change on ip6po_pktinfo for consistency.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Forward: Page Fault in in6_purgeaddr

[JINMEI Tatuya / 神明達哉]

 On Fri, 13 May 2005 08:11:14 -0700, 
 Mark Klein [EMAIL PROTECTED] said:

 You couldn't get to my web site and I see that this mail has been
 in the queue for a couple of days. I've resent this from the client
 site to see if it gets through.

According to the result of ifconfig -a, your box only has link-local
(and the loopback) IPv6 addresses.  As I said in an earlier message,
those normally should not cause the panic you experienced.  So I
suspect the PPP link happened to have global IPv6 addresses, perhaps
unexpectedly, with a valid lifetime of around 24 hours.  If you have
another chance to reestablish the link, please check whether the link
has an IPv6 address.  And, if it does, please also check the lifetime
of that address(es) by performing ifconfig -L.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Forward: Page Fault in in6_purgeaddr

[JINMEI Tatuya / 神明達哉]

 On Thu, 12 May 2005 06:57:32 -0700, 
 Mark Klein [EMAIL PROTECTED] said:

 Forwarded to the kame folks as well as they might have already fixed
 this in their own code.
 
 Can you tell us what else is going on when this happens?
 
 Is it random?

 It appears to happen at close to 24 hour periods ... almost 23 hours
 and 50 minutes, give or take a few minutes. Happens once per day only.
 IPv6 is NOT explicitly used at this site. Chasing the code makes it
 appear it could be related to the PPP tunnels, which I've disabled
 as of this AM to see what happens.

Hmm, this really sounds strange, since the sequence of
nd6_timer()-in6_purgeaddr(), which was an entry point of the crash,
could take place only when an IPv6 address with a finite lifetime
expires.  This could not happen if IPv6 is NOT explicitly used.
(link-local addresses are automatically assigned unless the INET6
option is removed from the kernel configuration options, but these
addresses have an infinite lifetime and cannot be the cause of this
trouble).

It would be helpful if you can provide the result of ifconfig -a
under the configuration that can cause the crash.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ipv6 host part

[JINMEI Tatuya / 神明達哉]

 On Fri, 29 Apr 2005 17:04:22 +1000 (EST), 
 Neo-Vortex [EMAIL PROTECTED] said:

 - assuming the prefix is P/64, do the followings:
 # ifconfig IFNAME inet6 P::1 prefixlen 64 alias autoconf
 # ifconfig IFNAME inet6 P::2 prefixlen 64 alias autoconf
 # ifconfig IFNAME inet6 P::3 prefixlen 64 alias autoconf

 IIRC, the first address within the prefix should have a prefixlen of 64,
 (providing the prefixlen is actually 64) but others on the same prefix
 should have 128.

I don't remember any such restriction.  What is your source (e.g.,
RFC) of this information?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ipv6 host part

[JINMEI Tatuya / 神明達哉]

 On Thu, 28 Apr 2005 14:20:07 +0300, 
 Petri Helenius [EMAIL PROTECTED] said:

 Is there a way to configure multiple IPv6 address aliases without 
 knowing the prefix in advance and just specifying the lower 64 bits on 
 the ifconfig_ lines on rc.conf?

No.

BTW: are you trying to configure multiple IPv6 addresses on a single
interface by specifying multiple interface IDs and getting prefix from
router advertisements?  If so, it's inherently difficult, not even via
rc.conf, since the kernel implementation can have only one interface
ID for address autoconfiguration.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ipv6 host part

[JINMEI Tatuya / 神明達哉]

 On Fri, 29 Apr 2005 06:40:05 +0300, 
 Petri Helenius [EMAIL PROTECTED] said:

 No.
 
 BTW: are you trying to configure multiple IPv6 addresses on a single
 interface by specifying multiple interface IDs and getting prefix from
 router advertisements?  If so, it's inherently difficult, not even via
 rc.conf, since the kernel implementation can have only one interface
 ID for address autoconfiguration.
 
 That is what I'm trying to do. The reason for that is to be able to 
 support SSL/TLS virtual hosts.

If you do not stick to the standard configuration via rc.conf, one
possible workaround is:

- send a router solicitation and get a prefix via router
  advertisements
- somehow (e.g., by a shell/perl script) identify the prefix
- assuming the prefix is P/64, do the followings:
  # ifconfig IFNAME inet6 P::1 prefixlen 64 alias autoconf
  # ifconfig IFNAME inet6 P::2 prefixlen 64 alias autoconf
  # ifconfig IFNAME inet6 P::3 prefixlen 64 alias autoconf
  ...

The keyword autoconf is the point.  It tells the kernel that the
addresses should be updated based on succeeding router advertisements.

(This may not work depending on the FreeBSD version.  I've tested the
procedure on a 5.3R box)

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 TCP transfers are hanging

[JINMEI Tatuya / 神明達哉]

 On Tue, 11 Jan 2005 14:01:29 -0800, 
 Kevin Oberman [EMAIL PROTECTED] said:

 I think I have found a problem with TCP when run over IPv6.
 I set my MSS for TCP to 1460 to allow a full 1500 byte MTU to be
 utilized on my systems. (Yes, I see that this does break some things
 like communicating via links where PMTUD is blocked and one or more
 links restrict MTU to some size less than 1500 bytes.

 What I am specifically seeing is a packet being sent out with a TCP
 length of 1460. While this is fine for IPv4, it's too back for IPv6 and,
 as you might expect, the far end never receives this packet.

Two questions to clarify things:

1. Which version of FreeBSD are you using?
2. How did you set the MSS?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Initial review request for IPv6 Fast Forwarding and IP6STEALTH

[JINMEI Tatuya / 神明達哉]

 On Mon, 6 Dec 2004 22:16:46 +1030, 
 Wilkinson, Alex [EMAIL PROTECTED] said:

 Nice, needs some cleanup though.  Once you have cleaned it up you can run
 it either through me or [EMAIL PROTECTED]  He is more of a IPv6 fan than I 
 am (in my
 book IPv6 is broken by design^TM).

 Why ?

(Perhaps this is slightly an off-topic for this list, but) I'm also
interested in the reason, but it's not surprising that someone in the
world has a negative impression on a big feature like IPv6 or IPsec,
since such a thing has typically both pros and cons.

And whatever the reason is, the important thing I believe is to
keep IPv6 implementation as good as IPv4 one on FreeBSD, in terms
of both stability and functionality.  I'm quite sure the fact that
FreeBSD has provided a good IPv6 implementation has enlarged the user
base of this particular operating system, comparing to, e.g., Linux.

So, I hope core FreeBSD developers to care about the quality of IPv6
implementation as seriously as that of IPv4 implementation, regardless
of their own position on IPv6 itself.  As an IPv6-related person, I'm
willing to help that process if I can do something in that area.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: the correct ipv6 behavior for interfaces with gif tunnel on them

[JINMEI Tatuya / 神明達哉]

 On Thu, 9 Dec 2004 18:53:37 +0100, 
 Konstantin KABASSANOV [EMAIL PROTECTED] said:

 Please provide more detailed network configuration.  Are you talking
 about a router box forwarding packets onto gif and physical
 interfaces?

 Well, this is a router box with 2 physical interfaces (say xl0 and rl0).
 Rl0 has a gif tunnel (gif0) over it. Xl0,rl0 and gif0 announce in their
 ifconfig an MTU of 1500, but 1300 bytes traffic generated from this box
 and sent through the gif0 interface is fragmented by the rl0 interface to
 1280 bytes...
 
   Please also specify the OS name (which I guess is
 FreeBSD) and its version.

 FreeBSD 4.7 (yes it is a little bit old, but I think the problem still
 persist in more recent versions)... And that's why I'm asking if this
 behavior is normal or not...

This is not the intended behavior, and seems to be fixed at least on
FreeBSD 5.3.  I don't know whether the change is merged into 4.x.  At
least it's not the case with FreeBSD 4.10.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: the correct ipv6 behavior for interfaces with gif tunnel on them

[JINMEI Tatuya / 神明達哉]

 On Wed, 8 Dec 2004 13:22:10 +0100, 
 Konstantin KABASSANOV [EMAIL PROTECTED] said:

 I have a freebsd box with a gif tunnel configured. I observed that even if
 ifconfig displays MTU 1500 for both gif and physical interface, 1300 bytes
 ipv6 packets transiting on the gif interface are systematically fragmented
 while transiting on the lower physical interface to 1280 bytes. Is it the
 normal behavior?

Please provide more detailed network configuration.  Are you talking
about a router box forwarding packets onto gif and physical
interfaces?  Please also specify the OS name (which I guess is
FreeBSD) and its version.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

MUT of stf (Re: (KAME-snap 8815) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE)

[JINMEI Tatuya / 神明達哉]

Forgot to respond to this point:

 On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), 
 Pekka Savola [EMAIL PROTECTED] said:

 Speaking of 6to4, if_stf.c does not support setting the MTU, because
 there's no ioctl handler for it.  It wouldn't IMHO hurt to be able to
 raise it from the glued-in default of 1280..

According to itojun (the principal author of the stf driver), it's on
purpose.  He said the reason for the restriction is because stf
normally had multiple (anonymous) destinations and we couldn't
pre-negotiate the size of the receiving buffer at the other ends.

(No further questions on this to me, please:-)

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: (KAME-snap 8820) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE

[JINMEI Tatuya / 神明達哉]

 On Thu, 30 Sep 2004 12:04:05 +0300 (EEST), 
 Pekka Savola [EMAIL PROTECTED] said:

  Unfortunately, I can't.  The when my SSH session froze, and the 6to4
  SSH sessions as well, my first instinct was 'oh, crap', and knee-jerk
  push of reset button (because the box has no keyboard attached). Sorry
  for being inprecise.
 
 Okay, I just found a bug that only happens when ip6.rtexpire is 0.
 Please try the following patch (with rtexpire=0).

 Well, the box no longer crashed at least, so I'd guess it works. :-)

Glad to hear that.

 Btw, is there any particular reason why net.inet.ip.rtexpire
 automatically dynamically re-adjusts itself (here, it's typically
 around 10 or 12), while net.inet6.ip6.rtexpire does not?

Hmm, good point.  I was also wondering why such a massive number of
route entries remained despite the periodical cleanup mechanism.  Then
I found another bug, which set the cleanup interval to a huge value
(almost infinite in a practical sense).

The patch below, including the previous fix, should also solve the
problem (I must confess I even did not compile it, so please be
careful).  Perhaps you can then live with the original rtexpire value.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

Index: in6_rmx.c
===
RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 in6_rmx.c
--- in6_rmx.c   28 Apr 2002 05:40:27 -  1.1.2.3
+++ in6_rmx.c   30 Sep 2004 20:40:14 -
@@ -270,10 +270,16 @@
rt-rt_flags |= RTPRF_OURS;
rt-rt_rmx.rmx_expire = time_second + rtq_reallyold;
} else {
+   struct rtentry *dummy;
+
+   /*
+* rtrequest() would recursively call rtfree() without the
+* dummy entry argument, causing duplicated free.
+*/
rtrequest(RTM_DELETE,
  (struct sockaddr *)rt_key(rt),
  rt-rt_gateway, rt_mask(rt),
- rt-rt_flags, 0);
+ rt-rt_flags, dummy);
}
 }
 
@@ -379,7 +385,7 @@
}
 
atv.tv_usec = 0;
-   atv.tv_sec = arg.nextstop;
+   atv.tv_sec = arg.nextstop - time_second;
timeout(in6_rtqtimo, rock, tvtohz(atv));
 }
 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: (KAME-snap 8815) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE

[JINMEI Tatuya / 神明達哉]

 On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), 
 Pekka Savola [EMAIL PROTECTED] said:

 Okay.  Now I think I figure out the problem.  Those host routes were
 created not deliberately, so the kernel will eventually need a fix to
 this.
 
 But if you are in a hurry and/or cannot replace the kernel soon, I
 think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with
 this you even do not have to reboot the kernel - though rebooting may
 also help if you can).

 Warning: this freezed the system immediately [all network connectivity
 broke, and I had to do a quick reset].  Maybe I should have set it up
 at reboot before the system was in a 'bad' shape..

Sorry for the trouble, but could you be more specific on freeze?
Does it mean the kernel hanged (you could not type anything from the
keyboard, etc)?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: (KAME-snap 8815) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE

[JINMEI Tatuya / 神明達哉]

 On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), 
 Pekka Savola [EMAIL PROTECTED] said:

 Okay.  Now I think I figure out the problem.  Those host routes were
 created not deliberately, so the kernel will eventually need a fix to
 this.
 
 But if you are in a hurry and/or cannot replace the kernel soon, I
 think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with
 this you even do not have to reboot the kernel - though rebooting may
 also help if you can).

 Warning: this freezed the system immediately [all network connectivity
 broke, and I had to do a quick reset].  Maybe I should have set it up
 at reboot before the system was in a 'bad' shape..

Sorry for the trouble, but could you be more specific on freeze?
Does it mean the kernel hanged (you could not type anything from the
keyboard, etc)?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: (KAME-snap 8818) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE

[JINMEI Tatuya / 神明達哉]

 On Wed, 29 Sep 2004 11:40:23 +0300 (EEST), 
 Pekka Savola [EMAIL PROTECTED] said:

  Okay.  Now I think I figure out the problem.  Those host routes were
  created not deliberately, so the kernel will eventually need a fix to
  this.
  
  But if you are in a hurry and/or cannot replace the kernel soon, I
  think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with
  this you even do not have to reboot the kernel - though rebooting may
  also help if you can).
 
  Warning: this freezed the system immediately [all network connectivity
  broke, and I had to do a quick reset].  Maybe I should have set it up
  at reboot before the system was in a 'bad' shape..
 
 Sorry for the trouble, but could you be more specific on freeze?
 Does it mean the kernel hanged (you could not type anything from the
 keyboard, etc)?

 Unfortunately, I can't.  The when my SSH session froze, and the 6to4
 SSH sessions as well, my first instinct was 'oh, crap', and knee-jerk
 push of reset button (because the box has no keyboard attached). Sorry
 for being inprecise.

Okay, I just found a bug that only happens when ip6.rtexpire is 0.
Please try the following patch (with rtexpire=0).

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]

Index: in6_rmx.c
===
RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 in6_rmx.c
--- in6_rmx.c   28 Apr 2002 05:40:27 -  1.1.2.3
+++ in6_rmx.c   29 Sep 2004 23:57:07 -
@@ -270,10 +270,16 @@
rt-rt_flags |= RTPRF_OURS;
rt-rt_rmx.rmx_expire = time_second + rtq_reallyold;
} else {
+   struct rtentry *dummy;
+
+   /*
+* rtrequest() would recursively call rtfree() without the
+* dummy entry argument, causing duplicated free.
+*/
rtrequest(RTM_DELETE,
  (struct sockaddr *)rt_key(rt),
  rt-rt_gateway, rt_mask(rt),
- rt-rt_flags, 0);
+ rt-rt_flags, dummy);
}
 }
 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: (KAME-snap 8794) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE

[JINMEI Tatuya / 神明達哉]

 On Sat, 25 Sep 2004 14:34:39 +0300 (EEST), 
 Pekka Savola [EMAIL PROTECTED] said:

  1. do you see massive number of entries with netstat -rna?
 
  Yes.
 
  # netstat -nra | wc -l
 32468
  #
 
 Okay, to be sure, most of them are IPv6 routing entries, right?

 Yes, 99.99%.

I can think of several possibilities that may cause the entries:

- when this node sends ICMPv6 error messages to those addresses, it
  can create route entries.  I suspect this is the main reason since
  in this case the destination of route entries would contain other
  types of addresses than 6to4.  You can (implicitly) check if this
  happened by looking at the result of 'netstat -s -p icmp6'
- if this node can be the originator (i.e., not a forwarder as a
  router) to those destinations, it can create host routes for the
  destinations.
- if you use some network-level hooks (e.g., packet filters) that rely
  on routing table lookups, the node may have the host routes.

Can one of those be the case in your environment?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 route mutex recursion (crash) and fix

[JINMEI Tatuya / 神明達哉]

(resending, since the first attempt seems to have failed due to some
DNS-related error)

 On Thu, 23 Sep 2004 14:58:41 -0400, 
 Brian Fundakowski Feldman [EMAIL PROTECTED] said:

 So, as a result, I tend to think the proposed patch is a reasonable
 fix to the problem.  But please add the rationale as comments, since
 the background intent is a bit vague as shown by the question from
 George.

 Thank you for your review.  As you certainly are more knowledgable in KAME
 code than I am, would you mind redoing this so that the style is more
 closely matched; then I could take the change from the KAME repository?

I'm willing to help you, but please let me check to be sure.  Are you
asking me to modify the KAME snap code based on your patch first,
which you'll then merge back to FreeBSD?

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: (KAME-snap 8793) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE

[JINMEI Tatuya / 神明達哉]

 On Fri, 24 Sep 2004 20:39:32 +0300 (EEST), 
 Pekka Savola [EMAIL PROTECTED] said:

 1. do you see massive number of entries with netstat -rna?

 Yes.

 # netstat -nra | wc -l
32468
 #

Okay, to be sure, most of them are IPv6 routing entries, right?

Then please provide some additional information.

1. the result of netstat -rnal.  A digest of the output is probably
   enough, but if you could provide the entire output (on the web, for
   example) it would also be helpful.

2. how did you configure the route to the stf interface?  I guess you
   installed some static route for 2002::/16 to the interface.  The
   command line argument (or the rc.conf parameters) that made the
   route and the corresponding route entry shown by netstat -rn are
   both helpful.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: IPv6 route mutex recursion (crash) and fix

[JINMEI Tatuya / 神明達哉]

 On Tue, 21 Sep 2004 22:09:57 -0400, 
 Brian Fundakowski Feldman [EMAIL PROTECTED] said:

 I've already made noise about this before, so I'll be brief.  I plan on
 committing the following fix that prevents the routing code from being
 recursed upon such that RTM_RESOLVE causes the embryonic new route to
 be looked up again.  I realize that probably no one will bother trying
 to see this bug in action, but all you need to do is send some UDP6 to
 ff02::1%if as a user, with INVARIANTS turned on.

 Are there any objections?  It would be nice to have this in 5-STABLE,
 in case anyone actually wants to have IPv6.

The patch itself looks okay with the rationale you explained in a
follow-up message.  However, I have some related comments.

As commented in nd6_rtrequest(), the purpose for checking
nd6_is_addr_neighbor() in this function was to avoid creating a
neighbor cache for the destination of some special host-routes.  For
FreeBSD, this can happen with the route which has the RTF_PRCLONING
flag.  However, since recent versions of FreeBSD (seems to) have got
rid of this flag, we might even remove the check in nd6_rtrequest()
altogether.  (Then we'd not need to modify nd6_is_addr_neighbor().)

But removing the check may be too radical and may have unexpected
side-effect.  Also, it'd be nice if we could keep the difference
between the FreeBSD repository code and the KAME snap code as small as
possible, in terms of future merge efforts.  In this sense, removing
the nd6_is_addr_neighbor() check from nd6_rtrequest() might be a
suboptimal solution.

So, as a result, I tend to think the proposed patch is a reasonable
fix to the problem.  But please add the rationale as comments, since
the background intent is a bit vague as shown by the question from
George.

Thanks,

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: freeaddrinfo(NULL)

[JINMEI Tatuya / 神明達哉]

 On Tue, 21 Sep 2004 20:07:46 +0200, 
 Thomas Quinot [EMAIL PROTECTED] said:

 Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553
 nor RFC 3493.  Having such an assumption is a potentially bug and
 lose portability.

 Would there be any significant drawback for conforming applications
 if we made our best to deploy a safety net againt buggy user programs
 by not segfaulting in this case?

As Umemoto-san said, if we made freeaddrinfo(NULL) safe, the
application programmers might tend to rely on the safety net and
the uncareful coding style.  This can be worse than the segfault here,
because the reason for the NULL argument might be a bug in the
program, and, as a result of hiding the bug by making
freeaddrinfo(NULL) safe, it might cause much more serious effects
later in the program.

In my understanding, this kind of discussion has always been
controversial; whether we want to make more explicit errors (even if
those are segfaults), or whether we want to spoil bad programmers by
making the library interface safe.

I personally prefer the former idea.  Ideally, freeaddrinfo() should
have provided a return value which is a binary success or fail, so
that the application programmers can check the value to be sure that
they pass a valid pointer.  With the fact that freeaddrinfo() is
actually a void function, however, I'd rather keep the current
behavior (i.e., segfaulting) as an evil error indication.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: freeaddrinfo(NULL)

[JINMEI Tatuya / 神明達哉]

 On Tue, 21 Sep 2004 22:07:17 +0300, 
 Valentin Nechayev [EMAIL PROTECTED] said:

 As Umemoto-san said, if we made freeaddrinfo(NULL) safe, the
 application programmers might tend to rely on the safety net and
 the uncareful coding style.  This can be worse than the segfault here,

 Let you try to apply the same arguments to free() and you'll see nonsense.
 If free(NULL) is freely allowed, what's the problem with freeaddrinfo()?

One major problem is that the result when we pass NULL to freeaddrinfo
is not documented, while C90 (if I understand it correctly) explicitly
says the result is no-op.  In my preference (note that I admit this is
a controversial issue), I'd say the decision of C90 about free(NULL)
is also bad, but I can live with it since the standard is clear on
this.

 because the reason for the NULL argument might be a bug in the
 program, and, as a result of hiding the bug by making

 NULL was specially designed by C authors as special value, no valid pointer
 here. One may wrap anything with if(p) freeaddrinfo(p);, but this
 has no deep sense and leads only to style flames.

 freeaddrinfo(NULL) safe, it might cause much more serious effects
 later in the program.

 What effects? Why they doesn't appear with another pointer?

I was not talking about things like whether NULL had been specially
designed or not.  I was basically talking about any invalid argument
to freeaddrinfo.  More specifically, I was talking about the following
type of coding:

foo(addrinfo)
struct *addrinfo; /* this should be non NULL */
{


freeaddrinfo(addrinfo);

...
}

Here the programmer imposes an assumption that addrinfo is non NULL
(or is valid for freeaddrinfo).  It's the caller's responsibility to
ensure that this is a valid pointer.  But consider the case where the
caller-side code has a bug and passes a NULL pointer to foo().  If
freeaddrinfo(NULL) segfaults, we found the bug at this point.  If
freeaddrinfo(NULL) does no-op, the latter part of the function is
executed whereas the assumption isn't met.  This may or may not
cause a bad effect.  But the real point of the bug that led to the
NULL argument is hidden, which may cause another serious problem in
some other part of the code.

Of course, a careful programmer would always check the assumption
somewhere in the function foo() (probably at the head of the
function), regardless of the behavior of freeaddrinfo(NULL).  This is
desirable.  However, I can easily imagine that a lazy programmer will
tend to omit the check if freeaddrinfo(NULL) does no-op, since the
function itself seems to work without a problem whereas it actually
just hides a bug.

I admit the scenario is not so specific and some others may think it's
not so convincing.  I basically talk about a general practice (which I
personally believe) that it's always better to catch an error than to
ignore it and the sooner is the better.

 In my understanding, this kind of discussion has always been
 controversial; whether we want to make more explicit errors (even if
 those are segfaults), or whether we want to spoil bad programmers by
 making the library interface safe.

 Segfaulting on NULL makes nothing more safe.

This statement is too short to tell if it's valid, but I believe
Segfaulting on freeaddrinfo(NULL) can make something safer for the
reason I described above.  That is, catching a bug earlier *can*
make a safer result.

Again, note that I admit this is a controversial issue.  Regarding
whether we should change FreeBSD's implementation of freeaddrinfo() so
that it does no-op against NULL, I won't strongly oppose to that if
the vast majority supports the idea.  However, since the API
specification is silent on this, I'd then request that the man page
make an explicit note that the application programmer should be check
if the argument to freeaddrinfo() is valid because passing a NULL
pointer may cause an unexpected result, including segfaulting, on
other systems.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: freeaddrinfo(NULL)

[JINMEI Tatuya / 神明達哉]

 On Tue, 21 Sep 2004 23:32:33 +0200, 
 Thomas Quinot [EMAIL PROTECTED] said:

[...snip]

It seems that all these points simply show this is a controversial
issue.  I was not convinced with the argument for the no-op approach,
and still believe segfaulting is better.  But at the same time I seem
to have failed to convince others who believe in no-op.  So I won't
make further comments on those.  (If you feel this is unfair, please
raise the points again.)

One last comment about consistency:

 This statement is too short to tell if it's valid, but I believe
 Segfaulting on freeaddrinfo(NULL) can make something safer for the
 reason I described above.  That is, catching a bug earlier *can*
 make a safer result.

 In some conditions. But we have to take into account the fact that other
 systems do behave differently with a NULL pointer in freeaddrinfo (yes,
 I am specicly thinking of Linux and Windows), and we may also want to
 take *that* into account and find out how we can offer a consistent
 interface to programmers. I also believe that it would be friendlier to
 programmers to offer a behaviour more similar to free(3).

Note also that other *BSDs and Solaris use the segfault logic.  The
freeaddrinfo implementation in the libbind library as a part of the
ISC BIND package, which many UNIX-like OS vendors adopt (perhaps with
vendor-specific modifications though), also segfaults against a NULL
argument.

So, although consistency might in general be a good thing, the real
world's examples show we just have variations.

JINMEI, Tatuya
Communication Platform Lab.
Corporate RD Center, Toshiba Corp.
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]