Discussion:
pf_test6: kif == NULL, if_xname gre65
(too old to reply)
David Young
2006-11-17 22:02:31 UTC
Permalink
The departure of IPv6 interfaces does not agree with pf. The pfil hooks
that signal the interface's departure run before IPv6 sends messages
to indicate that it is leaving its multicast groups; when pf filters
the departure messages, it does not recognize the output interface,
so it complains at the departure of gre65, for example:

pf_test6: kif == NULL, if_xname gre65

I put a breakpoint at printf to see just what was going on:

# sysctl -w ddb.fromconsole=1
ddb.fromconsole: 0 -> 1
# sysctl -w ddb.onpanic=1
ddb.onpanic: 0 -> 1
#
#
# Stopped at netbsd:cpu_Debugger+0x4: popl %ebp
db> break printf
db> continue
Breakpoint in pid 1725.1 (utd6) at netbsd:printf: pushl %ebp
db> bt
printf(c0332c58,c0693c14,0,c0693c00,c0719780) at netbsd:printf
pf_test6(2,c0693c00,c69b254c,0,c0680880) at netbsd:pf_test6+0x72e
pfil6_wrapper(0,c69b254c,c0693c00,2,c69b26d8) at netbsd:pfil6_wrapper+0x38
pfil_run_hooks(c0364e40,c69b26e8,c0693c00,2,c035c5c0) at netbsd:pfil_run_hooks+0
x8f
ip6_output(c054fd00,c0357c00,c69b2634,0,c69b2764) at netbsd:ip6_output+0xee0
mld_sendpkt(c069087c,c69b28c0,7,202,c69b27b8) at netbsd:mld_sendpkt+0x2e9
in6_delmulti(c068e380,c034e000,2,c0690800,c0693c00) at netbsd:in6_delmulti+0x24d
in6_leavegroup(c0531530,2,4,0,c034ea60) at netbsd:in6_leavegroup+0x19
in6_purgeaddr(c0690800,bbbb001f,bfbf001f,0,0) at netbsd:in6_purgeaddr+0x5b
in6_purgeif(c0693c00,c0693c00,c0693c00,10,3) at netbsd:in6_purgeif+0x3a
udp6_usrreq(c69b29d8,16,0,0,c0693c00) at netbsd:udp6_usrreq+0x96
if_detach(c0693c00,c034f3e4,c69b2aec,246,c69b2b88) at netbsd:if_detach+0x2ba
gre_clone_destroy(c0693c00,0,c690b838,202,c055cd90) at netbsd:gre_clone_destroy+
0xf2
ifioctl(c0545bd0,80206979,c69b2b88,c604d784,c0351080) at netbsd:ifioctl+0xe6
sys_ioctl(c604d784,c69b2c48,c69b2c68,bfbfec70,8056000) at netbsd:sys_ioctl+0x169

syscall_plain() at netbsd:syscall_plain+0xae
--- syscall (number 54) ---
0xbbba87ef:
db> continue
pf_test6: kif == NULL, if_xname gre1

Looks to me like it may be necessary to call pr_usrreq(PRU_PURGEIF) before
pfil_run_hooks(PFIL_IFNET_DETACH) in if_detach(). What do you think?

Dave
--
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Steven M. Bellovin
2006-11-17 22:17:22 UTC
Permalink
Post by David Young
The departure of IPv6 interfaces does not agree with pf. The pfil hooks
that signal the interface's departure run before IPv6 sends messages
to indicate that it is leaving its multicast groups; when pf filters
the departure messages, it does not recognize the output interface,
pf_test6: kif == NULL, if_xname gre65
That works in v4, at least with no multicast running. I use pf filters
for ppp interfaces; I see the message but no further trouble when pppd
ends.


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Young
2006-12-03 19:27:03 UTC
Permalink
Post by Steven M. Bellovin
Post by David Young
The departure of IPv6 interfaces does not agree with pf. The pfil hooks
that signal the interface's departure run before IPv6 sends messages
to indicate that it is leaving its multicast groups; when pf filters
the departure messages, it does not recognize the output interface,
pf_test6: kif == NULL, if_xname gre65
That works in v4, at least with no multicast running. I use pf filters
for ppp interfaces; I see the message but no further trouble when pppd
ends.
pf_test6 returns PF_DROP after it prints that message, so it blocks the
packets that IPv6 tries to send as it removes addresses and multicast
memberships from an interface. That will surprise somebody, someday.
It seems to me that we need to remove the pfil hooks after calling the
protocol purge routines in if_detach(). I wonder if we will lose for
some other reason if I move the hook removal?

Dave
--
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...