Pfs tool and pfsync

[Arnaud Degroote]

Hi all

during my GSoC, I have working on some missing features of pf. The first goal
was to provide a tool, similar to ipfs, which is able to dump / restore a
complete state table accross a reboot for example.

I wrote such a tool, which is called pfs. Main difference with ipfs is that, in
default behaviour, dump / restore the table in ascii mode. There is two part
for the tool, a kernel patch at
http://netbsd-soc.sourceforge.net/projects/pfstate/pfs_kernel.diff
and a separate tool :
http://netbsd-soc.sourceforge.net/projects/pfstate/pfs.tar.gz
There is a man page with the tool, or you can read online man here
http://netbsd-soc.sourceforge.net/projects/pfstate/pfs.html8

In a second time, I have ported pfsync(4) from OpenBSD. A full src diff can be
found here
ftp://ftp.netbsd.org/pub/NetBSD/misc/degroote/pfsync.diff

I'm interested in both testing / reviewing for this two things. I would like
to integrate pfsync quickly into NetBSD tree too.

Regards,

[Brian A. Seklecki]

Post by Arnaud Degroote
In a second time, I have ported pfsync(4) from OpenBSD. A full src diff can be
found here
ftp://ftp.netbsd.org/pub/NetBSD/misc/degroote/pfsync.diff

Looks good on netbsd-5. Only two notes:

1) netstat(8) needs the pfsync(8) section
2) tcpdump(8) needs to know about /etc/protcol(5) values:
# Don't wait for IANA; I didn't see them hacking on OpenBSD
pfsync 240 PFSYNC # PF Synchronization


$ uname -a
NetBSD cauldron-nbsd-netbsd-5-i386.lab02.pitbpa0.priv.collaborativefusion.com 5.0_STABLE NetBSD 5.0_STABLE (GENERIC+PFSYNC) #0: Fri Aug 7 13:36:36 EDT 2009 ***@cauldron-nbsd -netbsd-5-i386.lab02. :/home/netbsd/obj.i386/20090729-2158EDT/
sys/arch/i386/compile/GENERIC+PFSYNC i386


pcn0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
address: 00:0c:29:67:52:18
media: Ethernet autoselect (autoselect)
inet 192.168.xxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.xxx
inet alias 192.168.xxx.xxxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.xx
inet6 fe80::20c:29ff:fe67:5218%pcn0 prefixlen 64 scopeid 0x1
inet6 2607:f000:xxxx:xxxx:20c:29ff:fe67:5218 prefixlen 64
pfsync0: flags=41<UP,RUNNING> mtu 1460
pfsync: syncdev: pcn0 syncpeer: 224.0.0.240 maxupd: 128
carp123: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
carp: MASTER carpdev pcn0 vhid 123 advbase 1 advskew 0
address: 00:00:5e:00:01:7b
inet 192.168.xxx.169 netmask 0xffffff00 broadcast 192.168.xxx.255


[4] Running tcpdump -n -tttt -vvvv -s4096 -i carp123 -e "host 224.0.0.240" &
[5]- Running tcpdump -n -tttt -vvvv -s4096 -e "host 224.0.0.240" &
2009-08-07 14:16:52.805504 00:0c:29:67:52:18 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 230: (tos 0x10, ttl 255, id 184, offset 0, flags [DF], proto unknown (240), length 216) 192.168.xxx.54 > 224.0.0.240: ip-proto-240 196
2009-08-07 14:16:53.166751 00:0c:29:67:52:18 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 534: (tos 0x10, ttl 255, id 185, offset 0, flags [DF], proto unknown (240), length 520) 192.168.xxx.54 > 224.0.0.240: ip-proto-240 500
2009-08-07 14:16:53.517746 00:0c:29:67:52:18 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 142: (tos 0x10, ttl 255, id 186, offset 0, flags [DF], proto unknown (240), length 128) 192.168.xxx.54 > 224.0.0.240: ip-proto-240 108




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

[David Young]

Post by Brian A. Seklecki
# Don't wait for IANA; I didn't see them hacking on OpenBSD
pfsync 240 PFSYNC # PF Synchronization

Please do not reproduce the childish comment in /etc/protocol.

Dave

[DEGROOTE Arnaud]

Thanks for the report Brian.

I have updated the patch at

ftp://ftp.netbsd.org/pub/NetBSD/misc/degroote/pfsync.diff

where I fixed carp handling, and add support of pfsync for
tcpdump / libpcap.

Regards,

[Brian A. Seklecki]

Post by DEGROOTE Arnaud
Thanks for the report Brian.
I have updated the patch at

All:

I was just about to do some real world testing with carp(4) and
pfsync(4) on a v6-only system, but I'm getting the following:

Aug 18 10:52:15 hostname /netbsd: carpXXX: ip6_output failed: 65

This is happening inside carp_send_ad() of
sys/netinet/ip_carp.c, but I can't seem to find a reference to error #65
in any of the inet, inet6, or carp headers.

Ideas? TIA,

~BAS



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

[Manuel Bouyer]

Post by Brian A. Seklecki

Post by DEGROOTE Arnaud
Thanks for the report Brian.
I have updated the patch at

I was just about to do some real world testing with carp(4) and
Aug 18 10:52:15 hostname /netbsd: carpXXX: ip6_output failed: 65
This is happening inside carp_send_ad() of
sys/netinet/ip_carp.c, but I can't seem to find a reference to error #65
in any of the inet, inet6, or carp headers.

Isn't this just EHOSTUNREACH (from sys/ernno.h) ?

[Brian A. Seklecki]

Post by Manuel Bouyer
Isn't this just EHOSTUNREACH (from sys/ernno.h) ?

Yep I was just mentioning that on IRC from intro(2); however that would
imply that the IPv6 multicast address is unavailable (v4 is fine)

I'm guessing carp(4) requires a V4 destination on the interface since it
statically programmed to use a v4 destination for the "All-Routers"
multicast address.

224.0.0.18 -> 01:00:5e:00:00:12

~BAS





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

[a***@laas.fr]

Post by Manuel Bouyer

Post by Brian A. Seklecki

Post by DEGROOTE Arnaud
Thanks for the report Brian.
I have updated the patch at

I was just about to do some real world testing with carp(4) and
Aug 18 10:52:15 hostname /netbsd: carpXXX: ip6_output failed: 65
This is happening inside carp_send_ad() of
sys/netinet/ip_carp.c, but I can't seem to find a reference to error #65
in any of the inet, inet6, or carp headers.

Isn't this just EHOSTUNREACH (from sys/ernno.h) ?

I think it is EHOSTUNREACH too.

I'm not sure what is your exact settings, but in the current state,
pfsync(4) is just a port from OpenBSD code, and ATM only support pfsync
over INET (by default, on multicast address 224.0.0.240 grp). It can
explain the failure depending your settings.

--
Arnaud Degroote


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

[Brian A. Seklecki]

Post by a***@laas.fr
I'm not sure what is your exact settings, but in the current state,
pfsync(4) is just a port from OpenBSD code, and ATM only support

That is apparently the case. I'm finding that out in the middle of an
upgrade -- it's more than just noise on the debug log.

It's actually causing carp authentication failures and a preemption war.

OpenBSD carp(4) has fully supported V6 for years, AFAIK.

More research later today.

~BAS

Post by a***@laas.fr
pfsync over INET (by default, on multicast address 224.0.0.240 grp).
It can explain the failure depending your settings.

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

[Brian A. Seklecki]

Post by Manuel Bouyer
Isn't this just EHOSTUNREACH (from sys/ernno.h) ?

Two quick ifconfig(8) notes from my testing today:

1) Never manually try to set carpdev on carp(4), it segfaults. It
sets the parent interface for you when you assign an IP, based on
the subnet.

# ifconfig carp123 carpdev pcn0
Segmentation fault (core dumped)

I was just being thorough- following the output of ifconfig(8) -a
and filling in each field respectively.

I can file a PR an we can remote the "carpdev" text from the
usage() output, or we can put a code check in place to ensure that
the user doesn't set it

2) Never set flag 'tso4' on a VLAN interface -- it leads to a panic,
at least on netbsd-5. Some folks running -current on #NetBSD
report a sanity check in ifconfig(8) preventing it.

It could be the bge(4) on this old PowerEdge 850. Its really
sucky; go Dell!

I'll get a KDB backtrace from the console and PR it.


~BAS



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

[Manuel Bouyer]

Post by Brian A. Seklecki

Post by Manuel Bouyer
Isn't this just EHOSTUNREACH (from sys/ernno.h) ?

1) Never manually try to set carpdev on carp(4), it segfaults. It
sets the parent interface for you when you assign an IP, based on
the subnet.
# ifconfig carp123 carpdev pcn0
Segmentation fault (core dumped)

Please send-pr for this. carpdev is supposed to work, and IPs on the carp
and the underlying interface don't have to be in the same subnet.

Post by Brian A. Seklecki
I was just being thorough- following the output of ifconfig(8) -a
and filling in each field respectively.
I can file a PR an we can remote the "carpdev" text from the
usage() output, or we can put a code check in place to ensure that
the user doesn't set it

No, the bug has to be fixed so that carpdev works again.

[David Young]

Post by Manuel Bouyer

Post by Brian A. Seklecki

Post by Manuel Bouyer
Isn't this just EHOSTUNREACH (from sys/ernno.h) ?

1) Never manually try to set carpdev on carp(4), it segfaults. It
sets the parent interface for you when you assign an IP, based on
the subnet.
# ifconfig carp123 carpdev pcn0
Segmentation fault (core dumped)

Please send-pr for this. carpdev is supposed to work, and IPs on the carp
and the underlying interface don't have to be in the same subnet.

Looks like I broke it either in the ifconfig(8) overhaul or in some
subsequent change. I have attached a patch for you to try.

Dave