headers
Nick Reilly | 4 Jul 2011 20:37

IPv6 MSS and pflog interface

Hi,
I have run in to an issue with my IPv6 TCP MSS getting set too high
causing IPv6 to drop large frames. The root cause is that the MTU of the
pflog0 is being used for the IPv6 MSS. Searching around I found the same
issue reported back in 2007
http://osdir.com/ml/os.netbsd.ports.sparc64/2007-06/msg00029.html

The reason this affects v6 and not v4 is due to the difference in
in6_setmaxmtu() and in_setmaxmtu(), the v6 version only checks for
loopback whilst the v4 version checks for not loopback and also that the
interface is up. I think the v6 version should change to the same as the
v4.

At the same time, I wonder if the pflog interface type should have the
LOOPBACK flag set on it? There are currently no flags on it and given
that in6_setmaxmtu() / in_setmaxmtu() seem to base real vs virtual
network interface on the LOOPBACK flag and pflog seems to be a sort of
virtual interface type. If this interface were to be brought up then
IPv4 would similarly have an excessive MSS on it. Are there any
drawbacks to setting the LOOPBACK flag on an interface type that I might
be missing?

Of course the simple workaround of setting net.inet6.tcp6.mss_ifmtu=1
works around the issue, but I'm looking at the root cause.
Thanks,
Nick Reilly.
Permalink | Reply | 3 comments |
headers
Zoltan Arnold NAGY | 5 Jul 2011 10:09
Picon

Re: IPv6 MSS and pflog interface

On Mon, Jul 4, 2011 at 8:37 PM, Nick Reilly <nreilly <at> qnx.com> wrote:
> At the same time, I wonder if the pflog interface type should have the
> LOOPBACK flag set on it? There are currently no flags on it and given
> that in6_setmaxmtu() / in_setmaxmtu() seem to base real vs virtual
> network interface on the LOOPBACK flag and pflog seems to be a sort of
> virtual interface type. If this interface were to be brought up then
> IPv4 would similarly have an excessive MSS on it. Are there any
> drawbacks to setting the LOOPBACK flag on an interface type that I might
> be missing?
I second adding LOOPBACK to log interfaces.

Zoltan
Permalink | Reply | 2 comments |
headers
Michael van Elst | 5 Jul 2011 10:52
Picon

Re: IPv6 MSS and pflog interface

zoltan.arnold.nagy <at> gmail.com (Zoltan Arnold NAGY) writes:

>I second adding LOOPBACK to log interfaces.

IFF_LOOPBACK has specific meanings in multicast and routing and
is used for some shortcuts. I don't think that any of this
is true for the pflog interface.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."
Permalink | Reply | 1 comment |
headers
Nick Reilly | 5 Jul 2011 14:34

Re: IPv6 MSS and pflog interface

On Tue, 2011-07-05 at 04:52 -0400, Michael van Elst wrote:
> zoltan.arnold.nagy <at> gmail.com (Zoltan Arnold NAGY) writes:
> 
> >I second adding LOOPBACK to log interfaces.
> 
> IFF_LOOPBACK has specific meanings in multicast and routing and
> is used for some shortcuts. I don't think that any of this
> is true for the pflog interface.

Thanks, that's the kind of thing I was worried about. Any thoughts on
how to mark the pflog interface as a virtual interface that shouldn't be
considered for max MTU calculations? Looks like the IFF_* flags field is
full currently although it is a short so could be expanded to a long and
add a new flag type, but that would be rather a large change to solve
this small issue.

Regards,
Nick.
Permalink | Reply | 0 comments |
headers
Greg Troxel | 7 Jul 2011 14:45
Picon

RTF_ANNOUNCE flags cleanup


RTF_PROTO1 and RTF_PROTO2 are in theory available for users.  Quagga
uses 1 to denote routes added by a routing protocol, leaving 2 as the
only one really available.

RTF_ANNOUNCE silently overloads RTF_PROTO2, leading to non-obvious
and undesired behavior, particularly in IPv6, where routes with PROTO2
basically don't work.

We used to have only 16 bits of flags, but now have 32, so they aren't
scarce.  The only issue is the old compat structures.  RTF_ANNOUNCE is
used in very few places, and binary compat with old programs that
publish proxy arp routes seems to be a non-issue.

Also, there are two other RTF_ flgs defined but not used aywhere,
aliasing PROTO1.

The following diffs clean up the situation, removing the other flags,
giving RTF_ANNOUNCE its own bit, and adding support for that bit to
netstat and route.  A previous incarnation was tested on netbsd-5 with
PROTO2 on v4 and v6, and this exacct patch is currently undergoing
testing.

Figuring this out and the changes are due to Bev Schwartz of BBN, and
<a word from our sponsor>
  Approved for Public Release, Distribution Unlimited
  This material is based upon work supported by the Defense Advanced
  Research Projects Agency and Space and Naval Warfare Systems Center,
  Pacific, under Contract No. N66001-09-C-2073.
</a>.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rjs | 13 Jul 2011 13:10
Picon
Picon

bridge(4) behaviour


I am trying to use tap(4) along with bridge(4) in an emulator program
and have run up against similar problems to those described in
kern/40139, with packets not being forwarded between members of the
bridge.

Is there any reason why we couldn't just automatically add the link
addresses of each of the members of the bridge to the cache ?

Robert Swindells
Permalink | Reply | 0 comments |
headers
is | 13 Jul 2011 17:04
Picon

working example setup for source-based routing with ipfilter?

Hi,

I'm trying to setup my router for dual homing- as my "normal" ISP
grew IPv6 - but am not sure how I should do it.

interface pppoe1 receives packets for 2001:db8:1111::/48
interface pppoe2 receives packets for 2001:db8:2222::/48

The default route points to pppoe1.

The idea is to route outgoing packets to the interface that would
receive their source addresses (else my upstreams would filter them).

Would this work?:

block out on pppoe1 to pppoe2 from 2001:db8:2222::/48 to any

Regards,
	-is
Permalink | Reply | 4 comments |
headers
Mouse | 13 Jul 2011 17:28

Re: working example setup for source-based routing with ipfilter?

> The idea is to route outgoing packets to the interface that would
> receive their source addresses (else my upstreams would filter them).

That kind of routing is exactly what srt interfaces are for.  I just
now looked, and the version in the 5.1 source tarballs appears to at
least try to support INET6.  NetBSD's version is missing a change that
makes it cooperate with "keep state" style firewalling (eg, most NAT
setups), but that is unlikely to matter for v6.  However, it may be
effectively unmaintained; it doesn't seem to have real locking calls in
it, and might not work right on little-endian machines - comparing it
against my version I see an ntohl which I think I added when I started
using it on i386 (for most of its existence I was using it on sparc).

Still, might be worth trying.

Of course, if you have some reason for wanting to do this with ipfilter
in particular, then ignore me. :-)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 2 comments |
headers
Matthias Scheler | 14 Jul 2011 16:21
Picon
Favicon

Re: working example setup for source-based routing with ipfilter?

On Wed, Jul 13, 2011 at 05:04:35PM +0200, is <at> netbsd.org wrote:
> Would this work?:
> 
> block out on pppoe1 to pppoe2 from 2001:db8:2222::/48 to any

That is not what I used in the past (more than five years ago).
If I remember correctly it looked something this:

pass out quick pppoe1 fastroute to pppoe2 from 2001:db8:2222::/48 to any

	Kind regards

--

-- 
Matthias Scheler                                  http://zhadum.org.uk/
Permalink | Reply | 0 comments |
headers
is | 15 Jul 2011 10:34
Picon

Re: working example setup for source-based routing with ipfilter?

On Wed, Jul 13, 2011 at 11:28:58AM -0400, Mouse wrote:
> > The idea is to route outgoing packets to the interface that would
> > receive their source addresses (else my upstreams would filter them).
> 
> That kind of routing is exactly what srt interfaces are for.  I just
> now looked, and the version in the 5.1 source tarballs appears to at
> least try to support INET6. 

Ah, I wasn't aware of that.

> NetBSD's version is missing a change that
> makes it cooperate with "keep state" style firewalling (eg, most NAT
> setups), but that is unlikely to matter for v6.  However, it may be
> effectively unmaintained; it doesn't seem to have real locking calls in
> it, and might not work right on little-endian machines - comparing it
> against my version I see an ntohl which I think I added when I started
> using it on i386 (for most of its existence I was using it on sparc).

Oh. Where is that ntohl ? Would you create a patch, please?

> Still, might be worth trying.

> Of course, if you have some reason for wanting to do this with ipfilter
> in particular, then ignore me. :-)

hm... I'm needing it for production use...

	-is
(Continue reading)

Permalink | Reply | 1 comment |

Gmane