Weird ISR accounting in 10-STABLE

[Vlad Galu]

What intrigues me is the reject flag not being honoured. The loopback
traffic was looping.


On Fri, Jul 11, 2014 at 2:45 AM, Ben Morrow <ben at morrow.me.uk> wrote:

> Quoth Vlad Galu <galu at packetdam.com>:
> > On Thu, Jul 10, 2014 at 9:56 PM, Vlad Galu <galu at packetdam.com> wrote:
> > >
> > > Good catch, why didn't I think of that earlier! I can see a lot of IPv6
> > > traffic that I can't really explain. Since I was running pf with
> synproxy I
> > > disabled pf altogether, but that did not improve things. Here is a
> snapshot
> > > (source IP address edited):
> > >
> > > -- cut here --
> > > 22:52:40.195950 IP6 A:B:C:D:E::1000.62571 > ::10.31.31.153.12132: Flags
>
> The second address here is an 'IPv4-compatible IPv6 address', which are
> not these days considered to be useful. See RFC 4291 section 2.5.5.1.
>
> I suspect the process which owns A:B:C:D:E::1000.62571 is playing silly
> games of some sort; possibly it's making Linux-based assumptions about
> the behaviour of dual-stack hosts which don't apply on BSD.
>
> > It was a routing loop! I kept seeing lots of identical SYN packets. I
> > somehow ended up with this v6 table entry:
> > -- cut here --
> > Routing tables
> >
> > Internet6:
> >
> > Destination                       Gateway                       Flags
> > Netif Expire
> >
> > ::/96                             ::1                           UGRS
> > lo0
>
> This is a correct route, and will not cause a routing loop. It's also
> *not* the same as the IPv6 loopback route (as someone else said); that
> route looks like
>
>     ::1     link#2      UH      lo0
>
> and should also be present (the link number might be different,
> obviously).
>
> The 'R' flag means 'reject': because these addresses are not useful,
> there should be a routing table entry to ensure packets addressed to
> them get thrown away rather than sent out on the wire. You need to find
> out why they are being generated in the first place.
>
> Ben
>
>


-- 
Regards,
Vlad