On Wed, 10 May 2006, Darren Reed wrote:
> > May 9 22:23:57 bose tun: tun_wdata_v6: ip.6to4tun0 (inet6) tun: invalid
> > IPv6 src (fe80::32:0:10)
>
> Do you get that if IPFilter/pfil isn't part of the equation?
I haven't seen it since that one time so I think it really isn't valid for
this problem. Btw, I tried another variant of bringing the
tunnel-with-pfil up - I started with the working "ip.6to4tun0":
# ifconfig ip.6to4tun0 inet6
ip.6to4tun0: flags=2200040<RUNNING,NONUD,IPv6> mtu 1480 index 8
inet tunnel src 81.216.104.103
tunnel hop limit 60
inet6 2002:51d8:6867::1/64
(Notice how it now gets a correct 6to4 IPv6 address too (2002:xxx). I then
tried "modinserting" pfil into various places of the stack, but nothing
that works. If I have a running ping that pings a remote IPv6 address
and and "ipf.conf":
... (other IPv4 related stuff on the normal ethernet interfaces)
IPV6TUN="ip.6to4tun0";
pass in on $IPV6TUN all head 400
pass out on $IPV6TUN all head 450
Then if I do:
ifconfig ip.6to4tun0 inet6 modinsert [EMAIL PROTECTED]
then the ping traffic is stopped until I "modremove" pfil again.
If I insert it at "[EMAIL PROTECTED]" then nothing is never blocked. (I
assume that "modinsert [EMAIL PROTECTED]" is the same as using
"ip.6to4tun.pfil0"
directly. When I use "modinsert [EMAIL PROTECTED]" and check with ndd
I can see that the "nw" field is increasing (when the ping is running).
Is the some debugging flags one can enable in pfil/ipf to be able to
watch what's going on in better detail?
--
Peter Eriksson <[EMAIL PROTECTED]>
