Re: mrtg for pf
On Monday 14 May 2007, cangak wrote: > hallo all are there any body know how to load pf log i mean pf activity > to mrtg. please give the step to step how to install it. thaks I suggest looking at http://www.benzedrine.cx/pfstat.html (sysutils/pfstat) instead. But there are plenty of references on google e.g. Remko has the first hit here: http://www.evilcoder.org/content/view/545/33/ -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp0T72Vyv2fj.pgp Description: PGP signature
Re: udp fragmentation
Hi Hugo, On Tuesday 29 May 2007 00:42, Hugo Koji Kobayashi wrote: > While making some tests with fragmented udp DNS responses (with > EDNS0), we discovered a possible problem with pf in FreeBSD 6.2 and > 7.0 (200705 snapshot). > > Our test is a DNS query to an DNSSEC enabled server which replies with > a ~4KB udp response. We do this with the following dig command: > > dig @192.36.144.107 se dnskey +dnssec +bufsize=4500 +retry=0 > > pf in FreeBSD 6.2 or 7.0 block the fragments and the DNS queries > timeout. Disabling the firewall, complete replies are received with no > problem. The same test was run on an OpenBSD 4.1 box with no problem. > > Complete test results were sent to the freebsd-stable and freebsd-net > mailing lists and can be found here: > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-May/035154.html > > (The email message above includes tests with ipf) > > > pf rules looks like this in all tests: > > scrub in all fragment reassemble > block drop in log all > pass in log on bge0 inet proto tcp from xxx.xxx.xxx.81 to xxx.xxx.xxx.87 > port = ssh flags S/SA keep state pass out on bge0 proto tcp all flags S/SA > keep state > pass out on bge0 proto udp all keep state > pass out on bge0 proto icmp all keep state > > > Am I doing something wrong? Is there anything else I should try on > FreeBSD? Can you enable extended logging (pfctl -xm) and check your console for messages? Also please check "pfctl -si" for counter increases. Thanks, -- Max ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf(4) status in 7.0-R
[ moving this to the more specific list ] On Friday 01 June 2007, LI Xin wrote: > Stanislaw Halik wrote: > > Heya, > > > > Are there any plans to sync pf(4) before 7.0-R? OpenBSD has some neat > > stuff in it, including expiretable functionality, which would come in > > handy. > > Last time I have talked with Max (Cc'ed) about the issue, we finally > figured out that porting the whole stuff would need some > infrastructural changes to our routing code, which could be risky so we > wanted to avoid it at this stage (about 15 days before RELENG_7 code > freeze). On the other hand, some functionality (like the expiretable > feature) does not seem to touch a large part of kernel and might be > appropriate > RELENG_7(_0) candidate. > > Could you please enumerate some features that FreeBSD is currently lack > of and are considered "high priority" so we will be able to evaluate > whether to port? > > BTW. Patches are always welcome, as usual :-) So don't hesitate to > submit if you already did some work. ditto. I'd like to import a couple of features on a per-feature base rather than doing a complete import which isn't possible anymore due to SMP and routing code changes. Submit your list of features and I'll see what I can do this weekend. My list includes: - keep state and flags S/SA to default - improved state table purgeing (this is internal, but a huge benefit) - interface handling (groups etc.) - pfsync / pflog update (not 100% sure about these due to libpcap / tcpdump dependency) While at it, I might also introduce needed ABI breakage for netgraph interaction. Anything else? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf(4) status in 7.0-R
On Friday 01 June 2007, Greg Hennessy wrote: > > ditto. I'd like to import a couple of features on a per-feature base > > rather than doing a complete import which isn't possible anymore due > > to SMP and routing code changes. > > Is the inability to completely sync PF with the latest OpenBSD release > cast in stone for here on, or it an issue of resource to do ? Oh, and to answer to this part as well ... I'd like to keep the user interface as similar as possible, but the internal workings will and have to diverge due to different takes on SMP and other infrastructure. Also coming FreeBSD specific features (e.g. netgraph) will make a verbatim sync impossible. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf(4) status in 7.0-R
On Friday 01 June 2007, Greg Hennessy wrote: > > ditto. I'd like to import a couple of features on a per-feature base > > rather than doing a complete import which isn't possible anymore due > > to SMP and routing code changes. > > Is the inability to completely sync PF with the latest OpenBSD release > cast in stone for here on, or it an issue of resource to do ? > > Just curious in light of recent PF improvements as detailed here > > http://www.undeadly.org/cgi?action=article&sid=20070528213858 This is a completely unrelated issue really. Is debateable if it is good practice to put all that information into the pkthdr, but the speed improvement is something for sure. It remains to be seen if FreeBSD's mbuf tags perform as badly as OpenBSD's and - if they do - what can be done about that. One thing to keep in mind, however, pf is not the one and only Firewall in FreeBSD and there are *many* other places that use mbuf tags, too. I would rather look for a more general optimization of the mbuf tag framework - if required - , than gluttering the m_pkthdr with all fields one can think of (pf, ipfw, ipf, vlans, ipsec, altq ...) -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: udp fragmentation
Hi Hugo, On Thursday 31 May 2007, Hugo Koji Kobayashi wrote: > Please find attached the tests results after enabling extended > logging. > > I've done the test twice, changing dig's "+bufsize" parameter. looking at your log file, it seems that the packet traverses pf alright: > Console begin > pf_normalize_ip: reass frag 11881 @ 0-1480 > pf_normalize_ip: reass frag 11881 @ 1480-2960 > pf_normalize_ip: reass frag 11881 @ 2960-4094 > pf_reassemble: 4094 < 4094? > pf_reassemble: complete: 0xc4338000(4114) > Console end > > fbsd7# date ; pfctl -si > Tue May 8 04:15:24 BRT 2007 > No ALTQ support in kernel > ALTQ related functions disabled > Status: Enabled for 0 days 00:05:27 Debug: Misc > > Hostid: 0xfd3ea603 > > State Table Total Rate > current entries 3 > searches 405 1.2/s > inserts 40 0.1/s > removals 37 0.1/s > Counters > match 40 0.1/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 0 0.0/s > state-mismatch 0 0.0/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 0 0.0/s So the culprit should be somewhere up the stack. i.e. FreeBSD chokes on the already reassembled packet. Could you also provide netstat -ssp udp and netstat -ssp ip from before and after your test to get an idea where the packet is lost? To make sure I understand your setup correctly: pf is running on the DNS server i.e. the destination address of the datagram is a local address? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf(4) status in 7.0-R
On Saturday 02 June 2007, Michal Mertl wrote: > Max Laier wrote: > > [ moving this to the more specific list ] > > > > On Friday 01 June 2007, LI Xin wrote: > > > Stanislaw Halik wrote: > > > > Heya, > > > > > > > > Are there any plans to sync pf(4) before 7.0-R? OpenBSD has some > > > > neat stuff in it, including expiretable functionality, which > > > > would come in handy. > > > > > > Last time I have talked with Max (Cc'ed) about the issue, we > > > finally figured out that porting the whole stuff would need some > > > infrastructural changes to our routing code, which could be risky > > > so we wanted to avoid it at this stage (about 15 days before > > > RELENG_7 code freeze). On the other hand, some functionality (like > > > the expiretable feature) does not seem to touch a large part of > > > kernel and might be appropriate > > > RELENG_7(_0) candidate. > > > > > > Could you please enumerate some features that FreeBSD is currently > > > lack of and are considered "high priority" so we will be able to > > > evaluate whether to port? > > > > > > BTW. Patches are always welcome, as usual :-) So don't hesitate > > > to submit if you already did some work. > > > > ditto. I'd like to import a couple of features on a per-feature base > > rather than doing a complete import which isn't possible anymore due > > to SMP and routing code changes. > > > > Submit your list of features and I'll see what I can do this weekend. > > My list includes: > > > > - keep state and flags S/SA to default > > - improved state table purgeing (this is internal, but a huge > > benefit) - interface handling (groups etc.) > > - pfsync / pflog update (not 100% sure about these due to libpcap / > > tcpdump dependency) > > > > While at it, I might also introduce needed ABI breakage for netgraph > > interaction. > > > > Anything else? > > The updated ftp-proxy - the one in the tree does not rewrite source IP > address of data connections and some firewalls (e.g. Windows Firewall) > don't let the connection through. It should be pretty easy to import - > the program it already in some form in the ports tree. How do people feel about removing ftp-proxy from the base altogether? I think it's better off in ports anyway. Opinions? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp4XX78D7KSm.pgp Description: PGP signature
Re: pf(4) status in 7.0-R
On Friday 01 June 2007, Henrik Brix Andersen wrote: > Hi Max, > > On Fri, Jun 01, 2007 at 05:17:52PM +0200, Max Laier wrote: > > Submit your list of features and I'll see what I can do this weekend. > > My list includes: > > > > - keep state and flags S/SA to default > > - improved state table purgeing (this is internal, but a huge > > benefit) - interface handling (groups etc.) > > - pfsync / pflog update (not 100% sure about these due to libpcap / > > tcpdump dependency) > > Thank you for looking into this - much appreciated :) > > > While at it, I might also introduce needed ABI breakage for netgraph > > interaction. > > > > Anything else? > > I'm not sure how related this is, but 'carpdev' support is a feature I > (and judging from the archives, many other people) would really like > to see in FreeBSD. In lack of a working test-setup, I will not touch CARP. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpqsDgXOydzY.pgp Description: PGP signature
Re: pf(4) status in 7.0-R
On Sunday 03 June 2007, Gergely CZUCZY wrote: > On Sun, Jun 03, 2007 at 11:43:10PM +0800, LI Xin wrote: > > Max Laier wrote: > > [...] > > > > > How do people feel about removing ftp-proxy from the base > > > altogether? I think it's better off in ports anyway. Opinions? > > I would vote for including pftpx (the newer version in OpenBSD) iirc. > Almost a year ago I've made an ftp service where the ftpd was jailed to > a local IP address, and i had to use ftp-proxy for this propose. This > reverse-proxying stuff couldn't be achived with the ftp-proxy in > base, so i had to use the later version, which has the name pftpx > in the ports tree. I'd vote for replacing ftp-proxy with pftpx. Okay, but why? Is there any reason you can't use pftpx (or the newer version of ftp-proxy) from the ports tree? Why does ftp-proxy have to be in base? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpmxmOUiWaPq.pgp Description: PGP signature
Re: udp fragmentation
Hi again, On Monday 04 June 2007, Hugo Koji Kobayashi wrote: > pf is running on the DNS client machine. The DNS server is on a > completely different network (I don't control this server). The client > can send the udp request with no problem (it's a small udp datagram; > less than 512 bytes), the server sends the udp response fragmented, > but the client can't receive it. > > Please, find attached a new test with the requested information. > udp: > 36 datagrams received > 2 with bad checksum > 34 delivered > 40 datagrams output > udp: > 36 datagrams received > 3 with bad checksum > 33 delivered > 41 datagrams output Aha! Can you confirm that "bad checksum" increases for every fragmented packet and I'll look for a cure. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp19iANn5C0c.pgp Description: PGP signature
Re: pf(4) status in 7.0-R
On Monday 04 June 2007, Dag-Erling Smørgrav wrote: > Max Laier <[EMAIL PROTECTED]> writes: > > Anything else? > > ftp-proxy(8) and tftp-proxy(8) would be nice... ... I'm at it. Could you maybe lend a hand with importing libevent[1] which is a requirement for ftp-proxy now? It should make a good addition to base anyhow - as a convenient (and portable) interface to kqueue. [1] devel/libevent | http://www.monkey.org/~provos/libevent/ -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgptylLfJH52O.pgp Description: PGP signature
Re: pf(4) status in 7.0-R
On Friday 01 June 2007, Max Laier wrote: > [ moving this to the more specific list ] > ... > Anything else? Contrary to earlier remarks, I'll do an almost complete import of pf as per OpenBSD 4.1, not supported features will be disabled. These include routing: tags, multipath, etc. and pfsync ipsec SA-sync support (this might be trivial to fix, some ipsec knowhow provided). From a quick glance, this seems to be it already. Also, due to popular demand, I'll import the new ftp-proxy, too. Stay tuned for patches in the course of the week (if things go according to plan). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpAzKKmJiTCV.pgp Description: PGP signature
Re: pf(4) status in 7.0-R
On Wednesday 06 June 2007, Dag-Erling Smørgrav wrote: > Max Laier <[EMAIL PROTECTED]> writes: > > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > > Max Laier <[EMAIL PROTECTED]> writes: > > > > Anything else? > > > > > > ftp-proxy(8) and tftp-proxy(8) would be nice... > > > > ... I'm at it. Could you maybe lend a hand with importing > > libevent[1] which is a requirement for ftp-proxy now? It should make > > a good addition to base anyhow - as a convenient (and portable) > > interface to kqueue. > > Convenient and portable, but buggy as hell - we used it in Varnish to > begin with but had to ditch it due to a combination of design flaws and > bugs. It also suffers from creeping featuritis - the latest version > includes a DNS resolver and a full HTTP implementation... it's only a > matter of time before it grows a lisp interpreter and a mail reader. hmmm ... okay, didn't know that. But what do you suggest as an alternative? I certainly won't reinvent the wheel for the libevent calls in ftp-proxy. Importing libevent code private to ftp-proxy seems equally wrong. So the alternatives - to me at least - are either importing libevent or leaveing ftp-proxy in ports. Pick your poison. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpEwdpicMHkj.pgp Description: PGP signature
USER/GROUP rules on the chopping Block [ Re: Panic on boot with April 16 src (lengthy info attached) ]
After several attempts to fix user/group rules which ended like the most
recent one - cited below - with *ZERO* feedback, I won't waste anymore
effort. Either somebody steps up, does proper testing and reports back,
or user/group rules go! End of story!
This is not personal against Tillman - he just happend to be the most
recent one to hit the problem.
On Wednesday 18 April 2007, Tillman Hodgson wrote:
> On Wed, Apr 18, 2007 at 10:13:42PM +0200, Max Laier wrote:
> > On Wednesday 18 April 2007 21:28, Tillman Hodgson wrote:
> > > Oh, interesting! I'm rebuilding right now with that option :-)
> > > I'll report back in a few days how it goes.
> >
> > Actually, could you test this? It should enable the hack on the fly
> > as a user/group rule is added. See "sysctl debug.pfugidhack" or
> > "pfctl -x misc" to confirm it's on.
>
> Sure, I've restarted the build with this patch.
and again ... the thread ends here - zero feedback received :-( Does
anyone care about user/group rules at all? If so - speak up now or I'll
just disable them with the upcoming update!!!
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.43
diff -u -r1.43 pf.c
--- pf.c 29 Dec 2006 13:59:03 - 1.43
+++ pf.c 18 Apr 2007 19:55:19 -
@@ -134,6 +134,7 @@
#include
extern int ip_optcopy(struct ip *, struct ip *);
+extern int debug_pfugidhack;
#endif
#define DPFPRINTF(n, x) if (pf_status.debug >= (n)) printf x
@@ -3032,10 +3033,12 @@
return (PF_DROP);
}
-#if defined(__FreeBSD__) && defined(PF_MPSAFE_UGID)
- PF_UNLOCK();
- lookup = pf_socket_lookup(&uid, &gid, direction, pd, inp);
- PF_LOCK();
+#ifdef __FreeBSD__
+ if (debug_pfugidhack) {
+ PF_UNLOCK();
+ lookup = pf_socket_lookup(&uid, &gid, direction, pd, inp);
+ PF_LOCK();
+ }
#endif
r = TAILQ_FIRST(pf_main_ruleset.rules[PF_RULESET_FILTER].active.ptr);
@@ -3434,10 +3437,12 @@
return (PF_DROP);
}
-#if defined(__FreeBSD__) && defined(PF_MPSAFE_UGID)
- PF_UNLOCK();
- lookup = pf_socket_lookup(&uid, &gid, direction, pd, inp);
- PF_LOCK();
+#ifdef __FreeBSD__
+ if (debug_pfugidhack) {
+ PF_UNLOCK();
+ lookup = pf_socket_lookup(&uid, &gid, direction, pd, inp);
+ PF_LOCK();
+ }
#endif
r = TAILQ_FIRST(pf_main_ruleset.rules[PF_RULESET_FILTER].active.ptr);
Index: pf_ioctl.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_ioctl.c,v
retrieving revision 1.27
diff -u -r1.27 pf_ioctl.c
--- pf_ioctl.c 1 Jan 2007 16:51:11 - 1.27
+++ pf_ioctl.c 18 Apr 2007 20:04:57 -
@@ -84,6 +84,7 @@
#include
#include
#include
+#include
#else
#include
#include
@@ -237,6 +238,10 @@
struct mtx pf_task_mtx;
pflog_packet_t *pflog_packet_ptr = NULL;
+int debug_pfugidhack = 0;
+SYSCTL_INT(_debug, OID_AUTO, pfugidhack, CTLFLAG_RW, &debug_pfugidhack, 0,
+"Enable/disable pf user/group rules mpsafe hack");
+
void
init_pf_mutex(void)
{
@@ -1603,6 +1608,13 @@
rule->evaluations = rule->packets = rule->bytes = 0;
TAILQ_INSERT_TAIL(ruleset->rules[rs_num].inactive.ptr,
rule, entries);
+#ifdef __FreeBSD__
+ if (!debug_pfugidhack && (rule->uid.op || rule->gid.op)) {
+ DPFPRINTF(PF_DEBUG_MISC,
+ ("pf: debug.pfugidhack enabled\n"));
+ debug_pfugidhack = 1;
+ }
+#endif
break;
}
@@ -1828,6 +1840,14 @@
newrule->rpool.cur = TAILQ_FIRST(&newrule->rpool.list);
newrule->evaluations = newrule->packets = 0;
newrule->bytes = 0;
+#ifdef __FreeBSD__
+ if (!debug_pfugidhack &&
+ (newrule->uid.op || newrule->gid.op)) {
+DPFPRINTF(PF_DEBUG_MISC,
+("pf: debug.pfugidhack enabled\n"));
+debug_pfugidhack = 1;
+ }
+#endif
}
pf_empty_pool(&pf_pabuf);
pgpwpN2y1QI11.pgp
Description: PGP signature
Re: USER/GROUP rules on the chopping Block [ Re: Panic on boot with April 16 src (lengthy info attached) ]
Hi Tillman, On Wednesday 06 June 2007, Tillman Hodgson wrote: > I think you might have missed some posts :-) I successfully built with > that patch and reported it: ahh ... you dropped -pf@ and myself from the CC-list. -current is just too noisy to spot replys. Thanks for the info and sorry for the rant. This does *not* mean that everybody else can stop testing now! Please follow Tillman's example and report back (just keep me in CC this time ;)). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpu6xZ8xTH4u.pgp Description: PGP signature
Re: USER/GROUP rules on the chopping Block [ Re: Panic on boot with April 16 src (lengthy info attached) ]
On Wednesday 06 June 2007, Chris Marlatt wrote: > Max Laier wrote: > > and again ... the thread ends here - zero feedback received :-( Does > > anyone care about user/group rules at all? If so - speak up now or > > I'll just disable them with the upcoming update!!! > > Unfortunately I can't claim to be seeing this symptom, but I do use > user/group rules on shell servers quite often. They're very useful for > controlling untrusted users in an environment like that. Hopefully it > can continue to be included. Doesn't matter if you see the symptom or not. You should also check how the patch impacts on your workload and if it does at all. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpquFHu6atmG.pgp Description: PGP signature
Here we go again: pf 4.1 !!!ALPHA!!! update
Hi, long story short: http://people.freebsd.org/~mlaier/PF41/ enjoy. A word of caution: This is almost completely untested (eventhough this email passed through a minimal ruleset of pf 4.1 ;). I'd like to hear feedback, but I won't demand feedback from you until I've done some basic tests myself. Note that ALTQ and pfsync are defunct at the moment! As is tcpdumpping on pflog0 (though the basic idea should come through). This includes the new ftp-proxy with a private libevent (as suggested by des@). It also has tftp-proxy, but not yet linked to the build. If you do test it, please note that there are two known problems that don't need to be reported anymore (a LOR and some malloc warnings). Everything else (with sufficient debugging details) very welcome! Thanks - hope to have a more complete update during the week. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpoK4Q2ba1Co.pgp Description: PGP signature
Re: bin/113650: pf does not use IPv6 interface addresses at startups
Synopsis: pf does not use IPv6 interface addresses at startups State-Changed-From-To: open->closed State-Changed-By: mlaier State-Changed-When: Wed Jun 13 11:43:49 UTC 2007 State-Changed-Why: Can be fixed otherwise. Patch not a good idea in general - sorry. http://www.freebsd.org/cgi/query-pr.cgi?pr=113650 ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/113650: pf does not use IPv6 interface addresses at startups
The following reply was made to PR bin/113650; it has been noted by GNATS. From: Max Laier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: bin/113650: pf does not use IPv6 interface addresses at startups Date: Wed, 13 Jun 2007 13:43:51 +0200 The better fix is to use the "(if0)"-syntax to pick up additional addresses as they are configured. Starting pf late(r) has the downside, that unwanted traffic can sneak in during the early boot. -- Max Laier ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Here we go again: pf 4.1 !!!ALPHA!!! update
UPDATE available details below: On Sunday 10 June 2007, Max Laier wrote: > http://people.freebsd.org/~mlaier/PF41/ > > enjoy. > > A word of caution: This is almost completely untested (eventhough this > email passed through a minimal ruleset of pf 4.1 ;). I'd like to hear > feedback, but I won't demand feedback from you until I've done some > basic tests myself. > > Note that ALTQ and pfsync are defunct at the moment! As is tcpdumpping > on pflog0 (though the basic idea should come through). > > This includes the new ftp-proxy with a private libevent (as suggested > by des@). It also has tftp-proxy, but not yet linked to the build. > > If you do test it, please note that there are two known problems that > don't need to be reported anymore (a LOR and some malloc warnings). > Everything else (with sufficient debugging details) very welcome! > > Thanks - hope to have a more complete update during the week. ALTQ should be working again. The malloc warnings have been resolved. tcpdump and pfsync remain for the weekend session. I did some more testing which didn't show any major problems - alpha testing welcome! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpTN2WcJIuYn.pgp Description: PGP signature
Re: PF error message looping on screen. System Locked.
On Thursday 14 June 2007, Volker wrote: > On 06/14/07 15:33, Roger Miranda wrote: ... > > The issue is 5-8 hours after the boot up of the machine we get PF > > loop (Fast, continuous loop, so we can not read the message) on the > > screen. The machine is completly un responsive. But I noticed the > > that Num Lock (only the num lock button) button is still responsive. ... > Are you by any chance being able to get a photopicture (with fast > shutter time) of the debug messages? Do you have anything in > /var/log/debug.log /var/log/messages which might be useful? > > I think we first need an idea of what messages are popping up. Exactly. Other than Volker's pointers, you might also try to include debugger support and use the manual break (Ctrl+Alt+Esc) to pause and get a look at the messages. "ps" from debugger might also be insightful. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpn7kzhw0oPH.pgp Description: PGP signature
Re: PF error message looping on screen. System Locked.
On Thursday 14 June 2007, Roger Miranda wrote: > > I don't think this message is related to your trouble. I think you > > can also avoid these messages by adding 'no scrub' to your pf.conf > > (I'm currently not aware of any side effects by adding this). > > I did add it. > > > Probably Max has some more suggestions on not scrubbing packets. > > > > You should get a debugger into your kernel (like Max suggested) > > The debugger is in the kernel. I can break to it during normal > operation. Except when these messages are loop through the screen. > > > and > > probably also use `pfctl -x loud' or `pfctl -x misc' to get more > > messages out of pf. If these messages are popping up again, break the > > system into the debugger and look for the messages (using 'scroll > > lock' to scroll back some pages), ps and a backtrace. > > I have set debug to loud. > > I found this after I rebooted in dmesg: > > > pf_reassemble: complete: 0xc4338100(1504) > pf_normalize_ip: reass frag 39811 @ 0-1480 > pf_normalize_ip: reass frag 39811 @ 1480-1484 > pf_reassemble: 1484 < 1484? That's a configuration problem. Something seems to assume a MTU of 1484 while there really is a bottleneck with only 1480 which leads to heavy fragmentation. You should find the offender and reduce its MTU. If those messages show up, you did not use "no scrub" however. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp5Stm2rw1sS.pgp Description: PGP signature
Re: pf version 3.7 on freebsd
On Friday 15 June 2007, Leandro Malaquias wrote: > I've heard that the pf version being used on freebsd 6-stable is 3.7 so > the features "pass" and "log" when using "rdr" won't work. > Is this true?? Yes, FreeBSD RELENG_6's pf is based on OpenBSD 3.7. Yes, "log" is not valid for rdr rules in that version. No, "pass" is valid on rdr rules. There is also an update to OpenBSD 4.1 code available from http://people.freebsd.org/~mlaier/PF41/ for testing. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp4RifHi0Pup.pgp Description: PGP signature
Re: Here we go again: pf 4.1 !!!ALPHA!!! update
And again ... On Wednesday 13 June 2007, Max Laier wrote: > UPDATE available details below: > > On Sunday 10 June 2007, Max Laier wrote: > > http://people.freebsd.org/~mlaier/PF41/ > > > > enjoy. minor update to fix a build issue. There is some initial pfsync locking as well, but it's not working yet. This time only the tarball changed, so there is no new diff. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpAWJmvmhzc8.pgp Description: PGP signature
pf 4.1 Update available for testing
Hi, $subject at: http://people.freebsd.org/~mlaier/PF41/ As of today (20070616) I consider this to be BETA quality (at least). Please test and provide me (and freebsd-pf@) with feedback (good or else). If things work out well, I plan to commit this soon. To make testing easier I'm working on RELENG_6 patches as well, but it will be a bit to get through the fix/build/repeat-cycles. Note that almost every API/ABI changed (as usual in OpenBSD-land) and thus you need to compile world, remove your old pflogd files. Also note that the pfsync protocol has changed and thus you won't be able to sync an old and a new box. It should be possible to sync with a OpenBSD 4.1 box, however. Enjoy and report back! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgprmHq9eDszn.pgp Description: PGP signature
Re: pf version 3.7 on freebsd
On Sunday 17 June 2007, Dalibor Gudzic wrote: > On 6/15/07, Max Laier <[EMAIL PROTECTED]> wrote: > > Yes, FreeBSD RELENG_6's pf is based on OpenBSD 3.7. > > I don't want to bore everyone with this but I was wondering whether > it's possible to know what exactly is "available" in FreeBSD's pf in > comparison with OpenBSD's ( 3.7) pf? Everything except route tags. > I've read the details on http://pf4freebsd.love2party.net/ but the > status details there are outdated. FreeBSD Handbook referring to pf > isn't helping much either. Yeah, I have been slacking in that department. I think we should take it to the wiki instead. Volunteers welcome! > So my question is: is it possible to keep track of what options are > available (and which are not) in pf/ALTQ port of FreeBSD? Something > like info on: http://people.freebsd.org/~mlaier/PF41/README.txt > <http://people.freebsd.org/%7Emlaier/PF41/README.txt> > > I understand the purpose of this mailing list but I just wondered > whether it's possible to keep things in one place. As I said above, a wiki page might be in order, but I don't do much wiki or doc work in general - lazy me. > > There is also an update to OpenBSD 4.1 code available from > > http://people.freebsd.org/~mlaier/PF41/ for testing. > > Great work, will definitely update to give it a try. Thanks, please do provide feedback! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp8KugOf4V0u.pgp Description: PGP signature
Re: pf 4.1 Update available for testing
On Sunday 17 June 2007, Eygene Ryabinkin wrote: > Max, good day. > > Sat, Jun 16, 2007 at 03:47:24AM +0200, Max Laier wrote: > > $subject at: http://people.freebsd.org/~mlaier/PF41/ > > I glanced over the new code and found that no changes were > introduced to the altq_subr.c. And there was rather old issue > I found in April: non-initialised callback due to Nate Lawson's > changes in handling the changing CPU frequencies. > > Looks like it is still living in the code. My original posting > is at >http://lists.freebsd.org/pipermail/freebsd-current/2007-April/071652.html > > Could you please take a look? Are you saying that the patch in that mail fixes things for you? I recall the discussion vaguely, but somehow dropped out of it - sorry. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp843GhCXK2b.pgp Description: PGP signature
Re: firewalling and ALTQ
On Tuesday 19 June 2007, Rob Shepherd wrote: > I've just installed FreeBSD with a view to making a traffic shaping, or > essentially transfer capacity limiting device. > > This must sit on bridged interfaces between org and edge outers. It can be difficult to wrap one's head around traffic shaping on bridges because of the ambiguous of IN/OUT on a bridge. Be sure to filter on the member interfaces instead and apply queueing there. > I'm having some difficulty working out which bits I need, which packet > filter to use and how to get started. > > The appears to be 3 packet filters > > pf,ipf,ipfw > > is this right? ALTQ works with each? ALTQ works with pf and can be used from ipfw, too. You will need pf support regardless. ipf does not support the ALTQ version available in FreeBSD at this time (afaik). IPFW has dummynet, which can do traffic shaping, too. > additionaly, I don't seem to have any /dev/ entries kldload pf / ipf / ipfw ... or use the rc.d scripts. e.g. "etc/rc.d/pf forcestart" later automate the process by flipping the right switches in rc.conf(5). You can also build the firewalls into your kernel, see the handbook for details. Note, that ALTQ can *not* be loaded as a module and requires a custom kernel instead. > There are many tutorials, but It's impossible to know what is the > current supported filter package, what works best with bridging and > ALTQ and how to test them when there's bit's missing. Feel free to write down your lessons learned and publish them ;) -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp5aIkfmcNSO.pgp Description: PGP signature
Re: pf 4.1 Update available for testing
On Saturday 16 June 2007, Max Laier wrote: > $subject at: http://people.freebsd.org/~mlaier/PF41/ New drop (20070621) out. Much better tested - thanks to qemu (which I finally got working w/ carp [use the re nics and twiddle vlanhwtag after the carp interfaces are up]. Now I only need a bit more ram *hint* *hint* *hint* ;) -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpJ4T2IMAQd5.pgp Description: PGP signature
Re: pf 4.1 Update available for testing
On Monday 25 June 2007, Abdullah Ibn Hamad Al-Marri wrote: > On 6/21/07, Max Laier <[EMAIL PROTECTED]> wrote: > > On Saturday 16 June 2007, Max Laier wrote: > > > $subject at: http://people.freebsd.org/~mlaier/PF41/ > > > > New drop (20070621) out. > > > > Much better tested - thanks to qemu (which I finally got working w/ > > carp [use the re nics and twiddle vlanhwtag after the carp interfaces > > are up]. Now I only need a bit more ram *hint* *hint* *hint* ;) > > > > -- > > /"\ Best regards, | [EMAIL PROTECTED] > > \ / Max Laier | ICQ #67774661 > > X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] > > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > Max, > > Thank you for the hard work to bring latest pf to FreeBSD. > > When will it hit RELENG_6 and HEAD? :) It will hit HEAD as soon as somebody other than me does proper testing and reports back! It will not hit RELENG_6 - ever. The new version breaks every API/ABI around, which is not acceptable for a STABLE branch. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpWAE1s7Jd3s.pgp Description: PGP signature
Re: pf 4.1 Update available for testing
On Saturday 16 June 2007, Max Laier wrote: > $subject at: http://people.freebsd.org/~mlaier/PF41/ yet another drop (20070625) available. This should fix all remaining issues with user/group rules. One slight limitation is that rules with "log(all, user)" will only log the user on the first packet (but I think one can live with that). This also connects tftp-proxy to the build - if you have a use for it, please take it for a ride and let me know. Other than that, I'm all out of problems. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpoOwnU922bV.pgp Description: PGP signature
Re: udp fragmentation
On Monday 04 June 2007, Max Laier wrote: > Hi again, > > On Monday 04 June 2007, Hugo Koji Kobayashi wrote: > > pf is running on the DNS client machine. The DNS server is on a > > completely different network (I don't control this server). The > > client can send the udp request with no problem (it's a small udp > > datagram; less than 512 bytes), the server sends the udp response > > fragmented, but the client can't receive it. > > > > Please, find attached a new test with the requested information. > > > > udp: > > 36 datagrams received > > 2 with bad checksum > > 34 delivered > > 40 datagrams output > > > > > udp: > > 36 datagrams received > > 3 with bad checksum > > 33 delivered > > 41 datagrams output > > Aha! Can you confirm that "bad checksum" increases for every > fragmented packet and I'll look for a cure. I can't reproduce this. What hardware are you running on? (arch, nic (rx/txcsum), non-standart CFLAGS). Just to confirm I'm testing the right cases, my setup looks like: Host1 Host2 Host3 netsend -> pf scrub -> pf scrub -> netreceive Everthing works as expected with various UDP payloads > MTU. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp7avr3rskdv.pgp Description: PGP signature
Re: udp fragmentation
On Thursday 28 June 2007, Hugo Koji Kobayashi wrote: > On Thu, Jun 28, 2007 at 07:19:25PM +0200, Max Laier wrote: > > Just to confirm I'm testing the right > > cases, my setup looks like: > > > > Host1 Host2 Host3 > > > > netsend -> pf scrub -> pf scrub -> netreceive > > I'm not sure I understood your setup. Why there are 3 hosts? In order to test scrub on forward and receiver at the same time (but taking Host2 out of the stream doesn't change the result). > I think a query should be sth like this: > >Client[netsend->pf scrub] -> Internet -> DNS server > > And the response should be: > >DNS server -> Internet -> Client[pf scrub->netreceive] > > > Everthing works as expected with various UDP payloads > MTU. > > Are you saying that you're able to receive responses to the following > dig command when it's run from a client machine running pf scrub? > > dig @a.ns.se se dnskey +dnssec +bufsize=4500 > > This query is supposed to receive a DNS answer of more than 4KB. See the attached script I did just now. The only thing common about your setup seems to be the bge(4) NIC. Can you try disabling hardware checksumming (ifconfig -txcsum -rxcsum)? My test is over a hardware checksumming fxp(4) card, though. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News Script started on Thu Jun 28 21:20:28 2007 21:20 amd64# dmesg > pre.dig 21:20 amd64# echo "scrub in" | pfctl -ef- pf enabled 21:20 amd64# dmesg > pre.dig 21:21 amd64# pfctl -sr scrub in all fragment reassemble 21:21 amd64# pfctl -xm debug level set to 'misc' 21:21 amd64# dig @a.ns.se se dnskey +dnssec +bufsize=4500 ; <<>> DiG 9.4.1 <<>> @a.ns.se se dnskey +dnssec +bufsize=4500 ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43979 ;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 10, ADDITIONAL: 24 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;se.IN DNSKEY ;; ANSWER SECTION: se. 3600IN DNSKEY 257 3 5 AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe3Y 9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbbOTcM 8pwXlj0EiX3oDFVmjHO444gLkBOUKUf/mC7HvfwYH/Be22GnClrinKJp 1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt8lgnyTUHs 1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/buvF4qJCydui eHukuY3H4XMAcR+xia2nIUPvm/oyWR8BW/hWdzOvnSCThlHf3xiYleDb t/o1OTQ09A0= se. 3600IN DNSKEY 257 3 5 AwEAAb6xRZHEf+PyF5dxEvz0BHEHbziu6iZaiNW/yjSaZcmrmZiRMF8F PppD+XuKSau0rgu4eBwYdpkEoMVR4FhI8frkuPHIue2LP1ETo+2hCrdr 60K1538yLvzbOhMxXt6knjPN+OlalMmCknadaofKga5FLKOPQs2C3nw6 AH4WUNGrchmDMVBwRwfZdQXYZTXesqULmGMK7mwjQGOxerRDQWrFv8Nh NnVV31PihaYBdQ1TJjvfGS/FYZJwv/BddiELiLeUnNWu3AOsRAshgOcD BOAPUvKJNEq6RHELFmvXOOe2d8H2yzv02EMQik6GwUm16DrSdmX+SWfe lQs+9ELFN6k= se. 3600IN DNSKEY 256 3 5 AwEAAbhCVInOCVKWoaeWFmCHfO0SW4MAEWiM2MrbR6q1fclgAa04Lkqu c2Lp1xQ1ssO7rDYDLf8Uhe6EU6Xs56mRS5ZhHGiWwozrY4duxyAaYQUo d6LuH0u5Q0VRUs5Yv5hh9YvVxR1iclbQleg6NDVVeMQU4lFWOnHbP6Md 2SNWptVV se. 3600IN DNSKEY 256 3 5 AwEAAcWT6tpmgKhM53EgomdSmbai1MRzj0bA6wWfmkFRU7wkNgKAP/Z+ 2Lc80W0EmNBwaT5mi2QDqKXCMXS4GgxNCNg5nOAgdcS2XqGYPFYNkETW iTtjnO3MPSZb4i77BEpAP2OtbazmRBAeYVNYV61X8o6X3H808b4mRIFF VBeMacsR se. 3600IN DNSKEY 256 3 5 AwEAAc3n4vV7f6TbRjSpfADcIBn+MDqzuFUo+s3b85wC8Tp+d1EDlLPF /5GIR4Y3P+8u1OpPKuCCzurvfics/HiGQU3Jkv3wlFP5cZLBSpCiwazY 253uJwXpItS+liP6AK+kOOwsEWTYxG6vvBodm/ASTbqs2FqokFTPLW74 lTOp51a5 se. 3600IN RRSIG DNSKEY 5 1 3600 20070704234724 20070628060616 55323 se. YXrv/m8r7cJgBXvI8RSGWnijl+P+5e+zrYeeIaBVKZkgAA3kt4+F16h7 hlEG/WBRR45lQUk+0A79hly/MkXQ11TgoJWd18t6YLDrkYkzL7Mu8XhU ohyTcXowVjICf8GjYwROofql2Gavb1ixsWu8HDj1V9PfOc5y7xdiPzFg Fnc= se. 3600IN RRSIG DNSKEY 5 1 3600 2007071400 20070601133943 6166 se. HAhEV9y1pe52qxK5kwkYQtGQr7uyJgfONWUbiY/j1sJLL4O9jP9TEP+d 5dNaPodc67IOChQ4kxqVDieqlHns7NsVA8yu2TaQkujS9jfp5fgewhlE 5NFEdBgsn1HZJXlAW+OtxqDYvNVien0072XNkGXpc5GtWpA2b6ky1aZ5 RAZHAoXO1gFa1qRdXlcsvLzdpe/SglFHCLCcfW3cSoVgRTfHGwQbncjg Qjg6ldDvZYpHYLZE/jMxh7BVzUxRugAx0PpGn4D3n/Y8dfUBTRU3f9El b+7NRyvSaFwXEx3OfPpAN4fmB0PUhWcuT02XPYL6zYYkW7b5Y5kr0mgf aoBasQ== se. 3600IN RRSIG DNSKEY 5 1 3600 2007071400 20070601133943 17686 se. nhpLK0Vt+CSH6GqIBbbNigrx2WivrH14tgXfAYhjMM5bnuTXHaYvmgJ9 1pjxgK8rAVJu2VOCapXyVonEK9hCUCsN7IjENgUdDrjwiWP7
Re: udp fragmentation
[ Please don't top post, fixed ]
On Thursday 28 June 2007, Vadym Chepkov wrote:
> From: "Max Laier" <[EMAIL PROTECTED]>, Thursday, June 28, 2007 3:34 PM
> > On Thursday 28 June 2007, Hugo Koji Kobayashi wrote:
> > > On Thu, Jun 28, 2007 at 07:19:25PM +0200, Max Laier wrote:
> > > > Just to confirm I'm testing the right
> > > > cases, my setup looks like:
> > > >
> > > > Host1 Host2 Host3
> > > >
> > > > netsend -> pf scrub -> pf scrub -> netreceive
> > >
> > > I'm not sure I understood your setup. Why there are 3 hosts?
> >
> > In order to test scrub on forward and receiver at the same time (but
> > taking Host2 out of the stream doesn't change the result).
> >
> > > I think a query should be sth like this:
> > >
> > >Client[netsend->pf scrub] -> Internet -> DNS server
> > >
> > > And the response should be:
> > >
> > >DNS server -> Internet -> Client[pf scrub->netreceive]
> > >
> > > > Everthing works as expected with various UDP payloads > MTU.
> > >
> > > Are you saying that you're able to receive responses to the
> > > following dig command when it's run from a client machine running
> > > pf scrub?
> > >
> > > dig @a.ns.se se dnskey +dnssec +bufsize=4500
> > >
> > > This query is supposed to receive a DNS answer of more than 4KB.
> >
> > See the attached script I did just now.
> >
> > The only thing common about your setup seems to be the bge(4) NIC.
> > Can you try disabling hardware checksumming (ifconfig -txcsum
> > -rxcsum)? My test is over a hardware checksumming fxp(4) card,
> > though.
>
> Yes, this eliminated the issue. Bug in bge driver?
Kind of - the driver claims to have done UDP checksum testing on the
fragment (which is impossible). The attached patch should fix the issue
for bge(4) and any other similar NIC.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf_norm.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_norm.c,v
retrieving revision 1.17
diff -u -r1.17 pf_norm.c
--- pf_norm.c 25 Mar 2006 21:15:25 - 1.17
+++ pf_norm.c 28 Jun 2007 20:49:33 -
@@ -411,6 +411,11 @@
/* Strip off ip header */
m->m_data += hlen;
m->m_len -= hlen;
+#ifdef __FreeBSD__
+ /* Checksum is not applicable to the reassembled packet */
+ m->m_pkthdr.csum_flags &= ~(CSUM_IP_CHECKED | CSUM_IP_VALID |
+ CSUM_DATA_VALID | CSUM_PSEUDO_HDR);
+#endif
/* Create a new reassembly queue for this packet */
if (*frag == NULL) {
pgpfsAq6VZjiU.pgp
Description: PGP signature
Re: udp fragmentation
On Friday 29 June 2007, Pyun YongHyeon wrote:
> On Thu, Jun 28, 2007 at 10:56:01PM +0200, Max Laier wrote:
> > [ Please don't top post, fixed ]
> >
> > On Thursday 28 June 2007, Vadym Chepkov wrote:
> > > From: "Max Laier" <[EMAIL PROTECTED]>, Thursday, June 28, 2007
> > > 3:34 PM
> > >
> > > > On Thursday 28 June 2007, Hugo Koji Kobayashi wrote:
> > > > > On Thu, Jun 28, 2007 at 07:19:25PM +0200, Max Laier wrote:
> > > > > > Just to confirm I'm testing the right
> > > > > > cases, my setup looks like:
> > > > > >
> > > > > > Host1 Host2 Host3
> > > > > >
> > > > > > netsend -> pf scrub -> pf scrub -> netreceive
> > > > >
> > > > > I'm not sure I understood your setup. Why there are 3 hosts?
> > > >
> > > > In order to test scrub on forward and receiver at the same time
> > > > (but taking Host2 out of the stream doesn't change the result).
> > > >
> > > > > I think a query should be sth like this:
> > > > >
> > > > >Client[netsend->pf scrub] -> Internet -> DNS server
> > > > >
> > > > > And the response should be:
> > > > >
> > > > >DNS server -> Internet -> Client[pf scrub->netreceive]
> > > > >
> > > > > > Everthing works as expected with various UDP payloads > MTU.
> > > > >
> > > > > Are you saying that you're able to receive responses to the
> > > > > following dig command when it's run from a client machine
> > > > > running pf scrub?
> > > > >
> > > > > dig @a.ns.se se dnskey +dnssec +bufsize=4500
> > > > >
> > > > > This query is supposed to receive a DNS answer of more than
> > > > > 4KB.
> > > >
> > > > See the attached script I did just now.
> > > >
> > > > The only thing common about your setup seems to be the bge(4)
> > > > NIC. Can you try disabling hardware checksumming (ifconfig
> > > > -txcsum -rxcsum)? My test is over a hardware checksumming
> > > > fxp(4) card, though.
> > >
> > > Yes, this eliminated the issue. Bug in bge driver?
> >
> > Kind of - the driver claims to have done UDP checksum testing on the
> > fragment (which is impossible). The attached patch should fix the
> > issue for bge(4) and any other similar NIC.
>
> I guess bge(4) has Rx checksum offload bug on fragmented UDP
> datagrams. Since other hardwares with checksum offload capability
> does not show this issue, it could be related with UDP pseudo header
> calculation. How about disabling UDP pseudo header calculation?
>
> I don't have bge(4) hardwares so the patch is just guess work.
In fact it doesn't seem broken at all, we would just have to do something
along the lines of ip_input.c::ip_reass() (line 1001 ff):
for (q = nq; q != NULL; q = nq) {
nq = q->m_nextpkt;
q->m_nextpkt = NULL;
m->m_pkthdr.csum_flags &= q->m_pkthdr.csum_flags;
m->m_pkthdr.csum_data += q->m_pkthdr.csum_data;
m_cat(m, q);
}
/*
* In order to do checksumming faster we do 'end-around carry' here
* (and not in for{} loop), though it implies we are not going to
* reassemble more than 64k fragments.
*/
m->m_pkthdr.csum_data =
(m->m_pkthdr.csum_data & 0x) + (m->m_pkthdr.csum_data >> 16);
Have to ponder a bit, if this is easily possible in pf's reassembly.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpS76N7lYGYr.pgp
Description: PGP signature
Re: udp fragmentation
On Friday 29 June 2007, Max Laier wrote:
> On Friday 29 June 2007, Pyun YongHyeon wrote:
> > On Thu, Jun 28, 2007 at 10:56:01PM +0200, Max Laier wrote:
> > > > > The only thing common about your setup seems to be the bge(4)
> > > > > NIC. Can you try disabling hardware checksumming (ifconfig
> > > > > -txcsum -rxcsum)? My test is over a hardware checksumming
> > > > > fxp(4) card, though.
> > > >
> > > > Yes, this eliminated the issue. Bug in bge driver?
> > >
> > > Kind of - the driver claims to have done UDP checksum testing on
> > > the fragment (which is impossible). The attached patch should fix
> > > the issue for bge(4) and any other similar NIC.
> >
> > I guess bge(4) has Rx checksum offload bug on fragmented UDP
> > datagrams. Since other hardwares with checksum offload capability
> > does not show this issue, it could be related with UDP pseudo header
> > calculation. How about disabling UDP pseudo header calculation?
> >
> > I don't have bge(4) hardwares so the patch is just guess work.
>
> In fact it doesn't seem broken at all, we would just have to do
> something along the lines of ip_input.c::ip_reass() (line 1001 ff):
>...
> Have to ponder a bit, if this is easily possible in pf's reassembly.
Works - see attached.
Does anyone know of a tool to generate nasty fragments to really test
this? Reordered / overlapping / etc. ?
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
//depot/user/mlaier/pfsrc/sys/contrib/pf/net/pf_norm.c#9 - /home/mlaier/devel/FreeBSD/p4/pfsrc/sys/contrib/pf/net/pf_norm.c
--- /tmp/tmp.1610.37 2007-06-29 15:01:49.552518013 +0200
+++ /home/mlaier/devel/FreeBSD/p4/pfsrc/sys/contrib/pf/net/pf_norm.c 2007-06-29 14:50:37.299015057 +0200
@@ -568,8 +568,22 @@
m2 = frent->fr_m;
pool_put(&pf_frent_pl, frent);
pf_nfrents--;
+#ifdef __FreeBSD__
+ DPFPRINTF(("csum: 0x%x 0x%x\n", m->m_pkthdr.csum_flags,
+ m->m_pkthdr.csum_data));
+ m->m_pkthdr.csum_flags &= m2->m_pkthdr.csum_flags;
+ m->m_pkthdr.csum_data += m2->m_pkthdr.csum_data;
+#endif
m_cat(m, m2);
}
+#ifdef __FreeBSD__
+ DPFPRINTF(("fcsum: 0x%x 0x%x\n", m->m_pkthdr.csum_flags,
+ m->m_pkthdr.csum_data));
+ m->m_pkthdr.csum_data =
+ (m->m_pkthdr.csum_data & 0x) + (m->m_pkthdr.csum_data >> 16);
+ DPFPRINTF(("fcsum: 0x%x 0x%x\n", m->m_pkthdr.csum_flags,
+ m->m_pkthdr.csum_data));
+#endif
ip->ip_src = (*frag)->fr_src;
ip->ip_dst = (*frag)->fr_dst;
pgpaD7yVj12nG.pgp
Description: PGP signature
Re: pf won't start because tun0 doesn't exist yet
On Saturday 30 June 2007, Frank Steinborn wrote: > I'm going to set up a FreeBSD-router running pf. I have rules in > pf.conf containing rules with 'tun0'. Here is the problem: > > When booting the machine, pf won't load the rules because tun0 doesn't > exist at this time. Of course I could easyilly workaround this, but I > wonder if there is a more elagant or even official way on this issue? This is a FAQ - search the archives. In short: If you need ALTQ on tun0 the only workaround is ppp.linkup (or similar). loginterface is unnecessary since pfctl -vvvsI -i tun0. Addresses are written "(tun0)" not "tun0". -- FreeBSD Status reports due: 07/07/07 :-) /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpIIxDD0IwLJ.pgp Description: PGP signature
HEADSUP: pf 4.1 import
All, in the course of this afternoon (CEST) I'll import the OpenBSD 4.1 version of pf. The build might break for a short time, but I'll try to keep it as short as possible. Users of pf should hold off a bit as I plan to commit a tiny ABI break after the update is finished in order to be able to add netgraph support in the future. After that a full "buildworld buildkernel installkernel installworld mergemaster"-run is advised. Will send an all clear when done. -- FreeBSD Status reports due: 07/07/07 :-) /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpntSoUWXGVc.pgp Description: PGP signature
Re: HEADSUP: pf 4.1 import
On Tuesday 03 July 2007, Thomas Quinot wrote:
> * Max Laier, 2007-07-03 :
> > in the course of this afternoon (CEST) I'll import the OpenBSD 4.1
> > version of pf. The build might break for a short time, but I'll try
> > to keep it as short as possible.
>
> Thanks Max! Is there a place on the web that lists interesting new
> features and fixes in that release?
http://www.openbsd.org/{38,39,40,41}.html Note that some functionality is
not available in FreeBSD (routing code related stuff, pfsync for IPSEC,
something I'm forgetting right now ... I'll try to compile a list later).
--
FreeBSD Status reports due: 07/07/07 :-)
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpgxZ2fNH8wD.pgp
Description: PGP signature
Re: HEADSUP: pf 4.1 import
On Tuesday 03 July 2007, Max Laier wrote:
> Users of pf should hold off a bit as I plan to commit a tiny ABI break
> after the update is finished in order to be able to add netgraph
> support in the future. After that a full "buildworld buildkernel
> installkernel installworld mergemaster"-run is advised.
>
> Will send an all clear when done.
this is it. Though my post commit build is still running, things should
be alright again.
Users of pf please note that tcpdump and libpcap need additional patches
that need to go through the vendor first. I'm trying to get things
moving there, but for the time being, please use the attached patch to
understand the new pflog format.
Anyone with hands at tcpdump.org? Help appreciated!
--
FreeBSD Status reports due: 07/07/07 :-)
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: contrib/libpcap/gencode.c
===
RCS file: /usr/store/mlaier/fcvs/src/contrib/libpcap/gencode.c,v
retrieving revision 1.16
diff -u -r1.16 gencode.c
--- contrib/libpcap/gencode.c 4 Sep 2006 19:54:21 - 1.16
+++ contrib/libpcap/gencode.c 30 Jun 2007 17:01:13 -
@@ -75,7 +75,14 @@
#include "ppp.h"
#include "sll.h"
#include "arcnet.h"
+#ifdef HAVE_NET_PFVAR_H
+#include
+#include
+#include
+#include
+#else
#include "pf.h"
+#endif
#ifndef offsetof
#define offsetof(s, e) ((size_t)&((s *)0)->e)
#endif
Index: contrib/libpcap/grammar.y
===
RCS file: /usr/store/mlaier/fcvs/src/contrib/libpcap/grammar.y,v
retrieving revision 1.11
diff -u -r1.11 grammar.y
--- contrib/libpcap/grammar.y 4 Sep 2006 19:54:21 - 1.11
+++ contrib/libpcap/grammar.y 30 Jun 2007 17:02:55 -
@@ -53,7 +53,13 @@
#include "pcap-int.h"
#include "gencode.h"
+#ifdef HAVE_NET_PFVAR_H
+#include
+#include
+#include
+#else
#include "pf.h"
+#endif
#include
#ifdef HAVE_OS_PROTO_H
Index: contrib/tcpdump/print-pflog.c
===
RCS file: /usr/store/mlaier/fcvs/src/contrib/tcpdump/print-pflog.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 print-pflog.c
--- contrib/tcpdump/print-pflog.c 4 Sep 2006 20:04:14 - 1.1.1.3
+++ contrib/tcpdump/print-pflog.c 30 Jun 2007 17:03:26 -
@@ -28,6 +28,16 @@
#include "config.h"
#endif
+#ifdef HAVE_NET_PFVAR_H
+#include
+#include
+#include
+#include
+#include
+#else
+#include "pf.h"
+#endif
+
#include
#include
@@ -35,7 +45,6 @@
#include "interface.h"
#include "addrtoname.h"
-#include "pf.h"
static struct tok pf_reasons[] = {
{ 0, "0(match)" },
Index: lib/libpcap/config.h
===
RCS file: /usr/store/mlaier/fcvs/src/lib/libpcap/config.h,v
retrieving revision 1.5
diff -u -r1.5 config.h
--- lib/libpcap/config.h 29 May 2005 18:12:46 - 1.5
+++ lib/libpcap/config.h 30 Jun 2007 17:05:20 -
@@ -45,6 +45,9 @@
/* Define to 1 if you have the header file. */
#define HAVE_MEMORY_H 1
+/* Define to 1 if you have the header file. */
+#define HAVE_NET_PFVAR_H 1
+
/* Define to 1 if you have the header file. */
/* #undef HAVE_NETINET_ETHER_H */
Index: usr.sbin/tcpdump/tcpdump/config.h
===
RCS file: /usr/store/mlaier/fcvs/src/usr.sbin/tcpdump/tcpdump/config.h,v
retrieving revision 1.7
diff -u -r1.7 config.h
--- usr.sbin/tcpdump/tcpdump/config.h 11 Jul 2005 04:14:42 - 1.7
+++ usr.sbin/tcpdump/tcpdump/config.h 30 Jun 2007 17:06:34 -
@@ -193,6 +193,9 @@
/* Define to 1 if you have the header file. */
/* #undef HAVE_NETDNET_DNETDB_H */
+/* Define to 1 if you have the header file. */
+#define HAVE_NET_PFVAR_H 1
+
/* Define to 1 if you have the header file. */
/* #undef HAVE_NETINET_ETHER_H */
pgpsRY9WmomQi.pgp
Description: PGP signature
Re: HEADSUP: pf 4.1 import
In case you wondered, too. The signature on my last message was bad because the ?list? applied the following cleanup: -Content-Type: text/x-diff; charset="iso-8859-6"; - name="pf.41.tcpdump_local.diff" +Content-Type: text/x-diff; + charset="iso-8859-6"; + name="pf.41.tcpdump_local.diff" The patch is good - there is no conspiracy ;) -- FreeBSD Status reports due: 07/07/07 :-) /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpfphxdu09ZX.pgp Description: PGP signature
Re: Current problem reports assigned to you
I'll ask all owners of pf-related PRs to reevaluate the problem in light of the update. It's unlikely that fixes can easily be backported, but I will try if positive feedback is available. -- FreeBSD Status reports due: 07/07/07 :-) /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpPLT7Zmuuff.pgp Description: PGP signature
Re: HEADSUP: pf 4.1 import
Hi Brian, On Tuesday 10 July 2007, Brian A. Seklecki wrote: > On Tue, 2007-07-03 at 12:26 +0200, Max Laier wrote: > > All, > > > > in the course of this afternoon (CEST) I'll import the OpenBSD 4.1 > > version > > We'll also have to see if Joel Knight's Net-SNMP patches work with our > 5.3 in ports/net-mgmnt. not 100% sure what you are talking about, but I'll CC the p5-Net-SNMP maintainer - maybe Lars has an idea. Note that the changes for the base system SNMP module where rather painless. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pf 4.1 Update available for testing
On Tuesday 10 July 2007, Henrik Brix Andersen wrote: > Hi, > > On Sat, Jun 16, 2007 at 03:47:24AM +0200, Max Laier wrote: > > To make testing easier I'm working on RELENG_6 patches as well, but > > it will be a bit to get through the fix/build/repeat-cycles. > > I can't seem to locate the patches for RELENG_6 on > http://people.freebsd.org/~mlaier/PF41/ - are they available for > testing? Oh ... forgot about that ... there are several problems with that. First of all RELENG_6 is missing the interface group infrastructure which is essential to pf now. This makes it difficult to produce patches. I could do it, but ... > Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is > branched? ... it can never be MFCed due to the ABI breakage in several essential places (ifnet and pf ioctls). There is some work going on in OpenBSD 4.2 to reduce userland ABI changes in the future, but for now updating pf means breaking ABIs means no MFC unfortunately. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pf load balance rapidshare problem
On Friday 13 July 2007, sukaca wrote: > dear all. > at the moment i used pf load balancing with 4 adsl connections. > everything work as i expected. > but the problem is whan i open rapidshare download with ticket. > as i known.rapidshare ticket is check ip connection.and i always got > invalid session. > > is there another way to make my ip established with. > or another way yo make it is possible. There is the sticky-address option to ensure repeated connections are issued from the same source address. As rapidshare might forward you to a different server, however, you might need something different. I'd simply use a rule to "pin" the rapidshare netblock to a certain uplink. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0
[ Excess CC-list ... testers needed!!! ] On Tuesday 17 July 2007, Robert Watson wrote: > Dear all: > > This is a reminder e-mail that, in the very near future, Giant > compatibility shims for network protocols will be removed. <...> > The *only* remaining case I am aware of where removing debug.mpsafenet > presents an issue is credential-related firewall rules (uid, gid, > jail). I'm am currently in an active e-mail discussion with the > various firewall maintainers about how to address this issue; as the > implementations of these rules violate the global lock order, deadlocks > occur if debug.mpsafenet isn't set to 1, which causes Giant to act as a > guard lock preventing parallel lock acquisition in the firewall. > Hopefully we will have this resolved, in some form, soon. What we really need right now, is real understanding of the problem (if there even is any). So we would like to ask everybody who is able to - to stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw) with debug.mpsafenet=1 It is normal that (in an WITNESS enabled kernel) you get a LOR similar to 14-17 and 32 from [1]. Everything different to those should be reported. If you indeed get a deadlock, please let us know and provide as much debugging information as you can. DDB's "ps", "show locks", "show alllocks" would be perfect, but detailed information how to repeat would be a good start to already. Thanks a lot! If you are unable to provoke a deadlock, please let us know as well. Include a few setup details (ruleset, SMP, special sysctl settings ...) so we can look for patterns. [1] http://sources.zabbadoz.net/freebsd/lor.html -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Session Limit
On Thursday 19 July 2007, Lorenz Helleis wrote: > I'm using PF and i would like to know how can i implement PF on a big > network? with more than 100.000 connections ? I read that the limit > of PF is 100.000 sessions.. :( There is no limit on the number of sessions. The only limit is (kernel) memory. In order to not panic there is an upper limit on states, but that can be adjusted with "set limit states". Read pf.conf(5) -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Single IP failover without carpdev
I am working on a patch to bring over carpdev functionality sponsored by pil.sk This will, however, take a bit longer than I initially though it would. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
RELENG_6 patch [Re: pf 4.1 Update available for testing]
now available at: http://people.freebsd.org/~mlaier/PF41/ with instructions how to build. Please test if possible and provide me with feedback. Again, this work can't be MFC'ed, but I'll try to keep up2date patches available for RELENG_6 and release branches. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: connect: not permitted by pf state lookup failures on heavier load
On Thursday 26 July 2007, Gergely CZUCZY wrote: > Recently I've been playing around with a carp+pfsync+pound applevel > proxy. On a high connection rate I've noticed some failed connections > and the applevel proxy rendered the backend web servers DEAD, that > means unreachable. See http://lists.freebsd.org/pipermail/freebsd-pf/2007-July/003563.html -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pf and keep/modulate state on 6.2
On Saturday 21 July 2007, Jordan Gordeev wrote:
> J.D. Bronson wrote:
> > At 02:52 AM 02/26/2007, you wrote:
> >> Wow, this fixed my FTP-over-DSL-to-6.2 problem too. With modulate
> >> state, I was getting ~30K/sec. With just keep state, I'm now getting
> >> more like what my connection is capable of. This is between two 6.2
> >> hosts on opposite sides of the Atlantic.
> >>
> >> Ted, I use pf because I like the format of the configuration file, I
> >> like the logging and pftop, and like how it's harder to lock
> >> yourself out of a remote machine by accident :)
> >>
> >> /JMS
> >
> > I use pf since its newer (I think?) and I came from openbsd..pf just
> > works and the config file is nice and sweet.
> >
> > I had thought that modulate state would put a load on my proc, but
> > sheesh, its a p4-3.06 - thats more than robust for a router.
> >
> > I wonder if we should file a bug on this?
> >
> > I am glad my post helped here. I still use modulate state for any
> > INCOMING connections though (www/smtp/etc).
>
> I'm replying to an old and long-forgotten thread to report my recent
> findings.
> There's a bug in PF with modulate/synproxy state. Modulate/synproxy
> state modulate sequence numbers, but don't modulate sequence numbers in
> TCP SACK options. Some firewalls block TCP segments with sequence
> numbers in the SACK option pointing outside the window, which causes
> connection stalls. The bug was fixed in OpenBSD with revision 1.509 of
> src/sys/net/pf.c about an year and a half ago. The bug is present in
> FreeBSD-STABLE. A fix for the bug was imported in FreeBSD-CURRENT with
> the big import of PF from OpenBSD 4.1.
> I'm CC-ing Max to notify him of the bug present in -STABLE and to ask
> him to deal with the issue by either porting the fix from OpenBSD, or
> by documenting that modulate/synproxy state is broken.
Good catch - sorry for the delay. Here is the diff (almost verbatim from
OPENBSD_3_8). Please test and report back. I plan to commit this to
RELENG_6 in a bit.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.34.2.4
diff -u -r1.34.2.4 pf.c
--- pf.c 19 Sep 2006 15:45:20 - 1.34.2.4
+++ pf.c 25 Jul 2007 18:51:35 -
@@ -1,5 +1,5 @@
/* $FreeBSD: src/sys/contrib/pf/net/pf.c,v 1.34.2.4 2006/09/19 15:45:20 csjp Exp $ */
-/* $OpenBSD: pf.c,v 1.483 2005/03/15 17:38:43 dhartmei Exp $ */
+/* $OpenBSD: pf.c,v 1.502.2.1 2006/05/02 22:55:52 brad Exp $ */
/*
* Copyright (c) 2001 Daniel Hartmeier
@@ -170,6 +170,8 @@
void pf_change_ap(struct pf_addr *, u_int16_t *,
u_int16_t *, u_int16_t *, struct pf_addr *,
u_int16_t, u_int8_t, sa_family_t);
+int pf_modulate_sack(struct mbuf *, int, struct pf_pdesc *,
+ struct tcphdr *, struct pf_state_peer *);
#ifdef INET6
void pf_change_a6(struct pf_addr *, u_int16_t *,
struct pf_addr *, u_int8_t);
@@ -1483,6 +1485,63 @@
}
#endif /* INET6 */
+
+/*
+ * Need to modulate the sequence numbers in the TCP SACK option
+ */
+int
+pf_modulate_sack(struct mbuf *m, int off, struct pf_pdesc *pd,
+struct tcphdr *th, struct pf_state_peer *dst)
+{
+ int hlen = (th->th_off << 2) - sizeof(*th), thoptlen = hlen;
+ u_int8_t opts[MAX_TCPOPTLEN], *opt = opts;
+ int copyback = 0, i, olen;
+ struct sackblk sack;
+
+#define TCPOLEN_SACKLEN (TCPOLEN_SACK + 2)
+ if (hlen < TCPOLEN_SACKLEN ||
+ !pf_pull_hdr(m, off + sizeof(*th), opts, hlen, NULL, NULL, pd->af))
+ return 0;
+
+ while (hlen >= TCPOLEN_SACKLEN) {
+ olen = opt[1];
+ switch (*opt) {
+ case TCPOPT_EOL: /* FALLTHROUGH */
+ case TCPOPT_NOP:
+ opt++;
+ hlen--;
+ break;
+ case TCPOPT_SACK:
+ if (olen > hlen)
+olen = hlen;
+ if (olen >= TCPOLEN_SACKLEN) {
+for (i = 2; i + TCPOLEN_SACK <= olen;
+i += TCPOLEN_SACK) {
+ memcpy(&sack, &opt[i], sizeof(sack));
+ pf_change_a(&sack.start, &th->th_sum,
+ htonl(ntohl(sack.start) -
+ dst->seqdiff), 0);
+ pf_change_a(&sack.end, &th->th_sum,
+ htonl(ntohl(sack.end) -
+ dst->seqdiff), 0);
+ memcpy(&opt[i], &sack, sizeof(sack));
+}
+copyback = 1;
+ }
+ /* FALLTHROUGH */
+ default:
+ if (olen < 2)
+olen = 2;
+ hlen -= olen;
+ opt += olen;
+ }
+ }
+
+ if (copyback)
+ m_copyback(m, off + sizeof(*th), thoptlen, opts);
+ return (copyback);
+}
+
void
pf_change_icmp(s
Fwd: call for ALTQ users
Here should be most of them ... help Kip testing. -- Forwarded message -- From: Kip Macy <[EMAIL PROTECTED]> Date: Jul 28, 2007 2:03 PM Subject: call for ALTQ users To: freebsd-net <[EMAIL PROTECTED]> I'm looking at extending ifnet to support multiple tx queues. It appears that this will inevitably interact with ALTQ. I don't know anyone using ALTQ so I need users to raise their hands to eventually test prospective changes. Thanks. -Kip -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pf eates syn packet?
On Thursday 02 August 2007, Frank Behrens wrote: > Frank Behrens <[EMAIL PROTECTED]> wrote on 2 Aug 2007 13:29: > > > > Aug 2 13:17:26 moon kernel: pf: state insert failed: > > tree_ext_gwy lan: 84.182.237.27:50517 gwy: 84.182.237.27:50517 ext: > > 193.99.144.85:80 > > The new pf(4) from > http://people.freebsd.org/~mlaier/PF41/ > on FreeBSD 6.2-STABLE-200708021147 i386 shows the same problem. :-( > > Is this a problem for pf(4) on FreeBSD or should the report be sent to > OpenBSD? Can you follow up with the complete pf.conf you are using? The "state insert failed" error suggests a logic problem in your config (or a missed PF_TAG_GENERATED somewhere). It seems that the same packet is run through the firewall twice, generating state on the first run, but not matching it on the second ... somehow strange. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Using PF + ALTQ in FreeBSD 6.2
On Monday 13 August 2007, Chris Marlatt wrote: > Dian Candra wrote: > > Yes, it's work with Dummynet well, cause I'm using dummynet for some > > years. The problem is, with dummynet I could not do "borrow" > > bandwidth from the parent. > > So, I should move to ALTQ+PF, but unfortunately I'm facing a problem > > with it. > > Please give me some comment, If I use ALTQ+PF in my router, it's > > really could not limit incoming and outgoing traffic from/to my > > client ? Does no one have a bettter experience ? > > > > regards, > > > > Dian > > I haven't had time to test this idea yet, maybe someone else can shed > some light on this, but seeing as ALTQ can only queue outbound traffic, > have you thought about queuing on both your external and internal > interfaces? Simply changing perspective of the rules? Yes, this is a functional approach. It's silly, but it does what you are asking for. It doesn't matter if you use ALTQ or dummynet for this, btw. > This is dependent upon pf/ALTQ actually taking two "altq" statements in > the pf.conf which I'm not certain it can do. It doesn't complain about > the syntax but like I said before, I haven't tested this yet. > > You could also try to use a combination of pf and ipfw. I used such an > implementation when I needed to do per ip bw limits and needed more > queues than ALTQ would support. ipfw's "mask src-ip" and "mask dst-ip" > work nicely for this. > > Best of luck in finding a functional solution. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: ifconfig carpdev
On Wednesday 22 August 2007, Alexandre Biancalana wrote: > Someone have news about ifconfig carpdev option implementation on > FreeBSD ? I'm preoccupied with academia at the moment. I will do it after September 10th. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: kern/115725: pf nat -> ($if) works only intermittently
The following reply was made to PR kern/115725; it has been noted by GNATS. From: Max Laier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/115725: pf nat -> ($if) works only intermittently Date: Wed, 22 Aug 2007 23:44:39 +0200 > nat pass on $ext_if from $freenx_jail_ip to any -> ($ext_if) > > When I then jexec a shell in the jail and try to do things on the > network, only 1 in 3 or so connections would work. Ideally they should > have all worked. This usually happens when you have aliases on $ext_if. In this case ($ext_if) expands to a round-robin pool with all addresses assigned to the interface. If you want to use the primary address on that interface you can use the "($ext_if:0)" syntax to exclude aliases. If the address you want to use is an alias, you have to specify it manually. -- Max ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pfsync errors
On Wednesday 22 August 2007, Bill Marquette wrote:
> For the last two days I've been troubleshooting a wierd issue where my
> secondary firewall in a pfsync/carp cluster isn't maintaining a state
> table similar in size to the primary - it's slowly increasing to the
> max size. I think I've finally tracked it down to ip_output()
> returning an error, but at this point I'm lost. The interfaces show
> no errors, this box happily ran OpenBSD for the last three years with
> no similar errors and has only started exhibiting this behavior after
> converting it. I'm seeing this on multiple boxes, but am spending my
> time troubleshooting just one. Any advice/assistance would be greatly
> appreciated, I'm at a loss and this is affecting my production
> environment.
>
> We're running RELENG_6_2, nics are Intel PRO/1000's (copper, but the
> cat-5e cable is a direct run to the 6513 switch one cabinet over -
> 15ft cable).
>
> This is a netstat from the primary machine, the secondary has been
> failed over to a couple times and looks similar (although
> interestingly the cluster seems to handle being on the secondary box
> better)
> # netstat -s -p pfsync
> pfsync:
> 409302985 packets received (IPv4)
> 0 packets received (IPv6)
> 0 packets discarded for bad interface
> 0 packets discarded for bad ttl
> 0 packets shorter than header
> 0 packets discarded for bad version
> 0 packets discarded for bad HMAC
> 0 packets discarded for bad action
> 0 packets discarded for short packet
> 0 states discarded for bad values
> 0 stale states
> 16980281 failed state lookup/inserts
> 1541416698 packets sent (IPv4)
> 0 packets sent (IPv6)
> 0 send failed due to mbuf memory error
> 182754275 send error
There are two reasons why we increase the send error counter. Either the
internal deferred work queue is full or ip_output fails. Could you
locate "pfsyncstats.pfsyncs_oerrors++" in your source code and replace
either occurrence with a printf(). Maybe use the attached. This way we
will know what exactly fails and if it is ip_output, why.
> # netstat -i -Iem2
> NameMtu Network Address Ipkts IerrsOpkts
> Oerrs Coll em21500 00:04:23:a6:b7:be 40932871327
> 1359271127 0 0
> em21500 192.168.100.2 l4dupfw140-sync 409327567 - 1359270884
> - -
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: if_pfsync.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pfsync.c,v
retrieving revision 1.19.2.5
diff -u -r1.19.2.5 if_pfsync.c
--- if_pfsync.c 19 Jan 2007 23:01:26 - 1.19.2.5
+++ if_pfsync.c 22 Aug 2007 22:05:04 -
@@ -1842,13 +1842,14 @@
{
struct pfsync_softc *sc = (struct pfsync_softc *)arg;
struct mbuf *m;
+ int error;
for(;;) {
IF_DEQUEUE(&sc->sc_ifq, m);
if (m == NULL)
break;
- if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL))
- pfsyncstats.pfsyncs_oerrors++;
+ if ((error = ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo, NULL)))
+ printf("pfsync_senddef: ip_output %d\n", error);
}
}
signature.asc
Description: This is a digitally signed message part.
Re: pfsync errors
On Tuesday 28 August 2007, Bill Marquette wrote: > On 8/22/07, Max Laier <[EMAIL PROTECTED]> wrote: > > There are two reasons why we increase the send error counter. Either > > the internal deferred work queue is full or ip_output fails. Could > > you locate "pfsyncstats.pfsyncs_oerrors++" in your source code and > > replace either occurrence with a printf(). Maybe use the attached. > > This way we will know what exactly fails and if it is ip_output, why. > > Here's what we get with the patch: > pfsync_senddef: ip_output 64 that's EHOSTDOWN ... that's strange. Are you using syncpeer? > # netstat -s -p pfsync > pfsync: > 1264507 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for bad ttl > 0 packets shorter than header > 0 packets discarded for bad version > 0 packets discarded for bad HMAC > 0 packets discarded for bad action > 0 packets discarded for short packet > 0 states discarded for bad values > 0 stale states > 115608 failed state lookup/inserts > 86591 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > 37231 send error > But since the send error still increases it seems as if the internal queue is overflowing, too. This is something that must be fixed as well, but I think the EHOSTDOWN from ip_output is more serious. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pfsync errors
On Tuesday 28 August 2007, Bill Marquette wrote: > On 8/27/07, Bill Marquette <[EMAIL PROTECTED]> wrote: > > > > Here's what we get with the patch: > > > > pfsync_senddef: ip_output 64 > > > > > > that's EHOSTDOWN ... that's strange. Are you using syncpeer? > > After converting both sides to using syncpeer, I now got this in my > dmesg after reboot: > > Trying to mount root from ufs:/dev/da0s2a > pfsync_senddef: ip_output 65 > pfsync_senddef: ip_output 65 > > $ netstat -s -ppfsync && sleep 1 && netstat -s -ppfsync > pfsync: > 699811 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for bad ttl > 0 packets shorter than header > 0 packets discarded for bad version > 0 packets discarded for bad HMAC > 0 packets discarded for bad action > 0 packets discarded for short packet > 0 states discarded for bad values > 0 stale states > 61740 failed state lookup/inserts > 46728 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > 23020 send error > pfsync: > 704677 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for bad ttl > 0 packets shorter than header > 0 packets discarded for bad version > 0 packets discarded for bad HMAC > 0 packets discarded for bad action > 0 packets discarded for short packet > 0 states discarded for bad values > 0 stale states > 62032 failed state lookup/inserts > 47070 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > 23221 send error > > The other pfsyncstats.pfsyncs_oerrors++ is after a IF_HANDOFF macro, I > traced it back to if_handoff() in if.c, but I'm not sure how to track > it down any further as it look like it's _IF_QFULL(ifq) that's > triggering the return 0. > > I'm going to toy with some settings for the em(4) driver in > loader.conf and see if I can raise the txd and rxd descriptors since > we're not running on 82542 or 82543 chipped hardware we can go above > 256 descriptors. No that's the internal work deferral queue. Try something like the following in contrib/pf/net/if_pfsync.c: @@ -229,7 +229,7 @@ callout_init(&sc->sc_bulk_tmo, NET_CALLOUT_MPSAFE); callout_init(&sc->sc_bulkfail_tmo, NET_CALLOUT_MPSAFE); callout_init(&sc->sc_send_tmo, NET_CALLOUT_MPSAFE); - sc->sc_ifq.ifq_maxlen = ifqmaxlen; + sc->sc_ifq.ifq_maxlen = 2 * ifqmaxlen; mtx_init(&sc->sc_ifq.ifq_mtx, ifp->if_xname, "pfsync send queue", MTX_DEF); if_attach(ifp); But there might be other reasons like timing wrt the locks. I'll have to check for details. It might also be a good idea to MFC the taskqueue approach from CURRENT, rather than using the callout ... that's a bit of work however. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: ping of death
On Thursday 30 August 2007, Lorenz Helleis wrote:
> Nessus give it to me:
>
> Mensagem:
> The machine crashed when pinged with an incorrectly fragmented packet.
> This is known as the 'jolt' or 'ping of death' denial of service
> attack.
>
> An attacker may use this flaw to shut down this server,
> thus preventing you from working properly.
>
> Solution : contact your operating system vendor for a patch.
>
> How can i fix this using pf ??
basic scrubbing will take care of the classic 'ping of death':
/* Respect maximum length */
if (fragoff + ip_len > IP_MAXPACKET) {
DPFPRINTF(("max packet %d\n", fragoff + ip_len));
goto bad;
}
so
scrub in on $ext_if
should keep you save.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
signature.asc
Description: This is a digitally signed message part.
Re: Updating PF
On Friday 31 August 2007, Greg Hennessy wrote: > > Hello, > > > > I'm using PF from a 6.1 FreeBSD kernel (Just added pf_enable="YES" in > > rc.conf) and also using Firewall Builder. > > Updating why exactly ? > > > How do I know what version is running? > > You are running the version of PF which ships as standard with FreeBSD > 6.1. Which IIRC is the same as shipped with OpenBSD 3.6. 3.7 in RELENG_6, 3.5 in RELENG_5, 4.1 in what is to become RELENG_7. > > What are the options to update PF? Is there a how-to? > > Yes, update your kernel to whatever the last STABLE release of 6.1 is. There are also patches for RELENG_6 to update to 4.1 pf, but given your inexperience with compilation that might not be the best choice for you. In any case, they are at: http://people.freebsd.org/~mlaier/PF41/ with instructions. If this box can take a downtime once in a while (i.e. not 100% mission critical) and you are interested in helping, then consider running the latest CURRENT. It is in good shape and has the newest pf (4.1). Just grab a snapshot or compile from source. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pfsync errors
On Wednesday 05 September 2007, Rian Shelley wrote:
> As far as I can tell, am having the same problem described by bill
> marquette. I have two firewalls using pfsync, where the secondary
> firewall just increases its state count steadily.
>
> I created a simple libpcap program to watch the pfsync headers flowing
> by, and i see types 8, 4, 2, which are PFSYNC_ACT_UREQ,
> PFSYNC_ACT_UPD_C, PFSYNC_ACT_UPD. I dont see any of type 3 or 5, which
> are the ones that delete state. As far as i can tell, states are
> pumped across the link, but never removed and are left to time out on
> their own.
Very good observation. I don't quite believe that you don't see *any*
three or fives, but I do see that those would get lost most easily. The
problem stems from the way states are purged in 3.7/RELENG_6. Newer pf
4.1/(soon to be)RELENG_7 splits the state removal.
I'm attaching a *very* experimental *HACK* that might help the situation.
I believe however, that you would be better off with moving to
4.1/RELENG_6 (patches at [1]) or 4.1/RELENG_7 as soon as it's done. The
state purge is one of the biggest weaknesses of 3.7/RELENG_6 which isn't
easily solveable.
Another way to go is setting the queuelength for the internal processing
queue to something insanely high (1000+). This will most likely work
around the problem at the cost of burning (mbuf) memory.
[1] http://people.freebsd.org/~mlaier/PF41/
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.34.2.5
diff -u -r1.34.2.5 pf.c
--- pf.c 28 Jul 2007 22:32:57 - 1.34.2.5
+++ pf.c 9 Aug 2007 20:51:42 -
@@ -1145,17 +1145,34 @@
pf_status.states--;
}
+static struct pf_state *pf_purge_pickup;
+
void
pf_purge_expired_states(void)
{
struct pf_state *cur, *next;
+ int max_purge = 5000;
+
+ if (pf_purge_pickup != NULL)
+ cur = pf_purge_pickup;
+ else
+ cur = RB_MIN(pf_state_tree_id, &tree_id);
- for (cur = RB_MIN(pf_state_tree_id, &tree_id);
- cur; cur = next) {
+ pf_purge_pickup = NULL;
+ for (;cur && max_purge; max_purge--, cur = next) {
next = RB_NEXT(pf_state_tree_id, &tree_id, cur);
if (pf_state_expires(cur) <= time_second)
pf_purge_expired_state(cur);
}
+ if (max_purge) {
+ cur = RB_MIN(pf_state_tree_id, &tree_id);
+ for (;cur && max_purge; max_purge--, cur = next) {
+ next = RB_NEXT(pf_state_tree_id, &tree_id, cur);
+ if (pf_state_expires(cur) <= time_second)
+pf_purge_expired_state(cur);
+ }
+ }
+ pf_purge_pickup = cur;
}
int
signature.asc
Description: This is a digitally signed message part.
Re: pfsync errors
On Thursday 06 September 2007, Bill Marquette wrote: > On 9/5/07, Max Laier <[EMAIL PROTECTED]> wrote: > > Another way to go is setting the queuelength for the internal > > processing queue to something insanely high (1000+). This will most > > likely work around the problem at the cost of burning (mbuf) memory. > > Assuming mbuf memory is essentially free that's certainly not a > problem for me. Is this the max ifqlen patch you had me try last > week? If so, what's a reasonably (relative to insanely high :)) > number to set that multiplier to? 2 times queue length "helped". I > don't want to set it so high that the box panics or something silly :) > Or for that matter, stops forwarding traffic while processing. We'll > give these patches a try in our lab shortly. We just started getting > the Smartbits online to try and duplicate the errors (straight up udp > testing can't replicate it). Try 1000 (or 20 * maxifqlen iirc). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pflog problem
On Wednesday 12 September 2007, Mike Tancsa wrote:
> On a box that got recently upgraded to current, I am having a problem
> reading from the pflog file.
>
> Not sure what are the "unknown" bits are, but I cant match hosts.
You are missing the attached patch - which I am trying to get through
tcpdump.org. The pflog header changed (once again) and changes are
required. Sorry for the mess.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: contrib/libpcap/gencode.c
===
RCS file: /usr/store/mlaier/fcvs/src/contrib/libpcap/gencode.c,v
retrieving revision 1.16
diff -u -r1.16 gencode.c
--- contrib/libpcap/gencode.c 4 Sep 2006 19:54:21 - 1.16
+++ contrib/libpcap/gencode.c 30 Jun 2007 17:01:13 -
@@ -75,7 +75,14 @@
#include "ppp.h"
#include "sll.h"
#include "arcnet.h"
+#ifdef HAVE_NET_PFVAR_H
+#include
+#include
+#include
+#include
+#else
#include "pf.h"
+#endif
#ifndef offsetof
#define offsetof(s, e) ((size_t)&((s *)0)->e)
#endif
Index: contrib/libpcap/grammar.y
===
RCS file: /usr/store/mlaier/fcvs/src/contrib/libpcap/grammar.y,v
retrieving revision 1.11
diff -u -r1.11 grammar.y
--- contrib/libpcap/grammar.y 4 Sep 2006 19:54:21 - 1.11
+++ contrib/libpcap/grammar.y 30 Jun 2007 17:02:55 -
@@ -53,7 +53,13 @@
#include "pcap-int.h"
#include "gencode.h"
+#ifdef HAVE_NET_PFVAR_H
+#include
+#include
+#include
+#else
#include "pf.h"
+#endif
#include
#ifdef HAVE_OS_PROTO_H
Index: contrib/tcpdump/print-pflog.c
===
RCS file: /usr/store/mlaier/fcvs/src/contrib/tcpdump/print-pflog.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 print-pflog.c
--- contrib/tcpdump/print-pflog.c 4 Sep 2006 20:04:14 - 1.1.1.3
+++ contrib/tcpdump/print-pflog.c 30 Jun 2007 17:03:26 -
@@ -28,6 +28,16 @@
#include "config.h"
#endif
+#ifdef HAVE_NET_PFVAR_H
+#include
+#include
+#include
+#include
+#include
+#else
+#include "pf.h"
+#endif
+
#include
#include
@@ -35,7 +45,6 @@
#include "interface.h"
#include "addrtoname.h"
-#include "pf.h"
static struct tok pf_reasons[] = {
{ 0, "0(match)" },
Index: lib/libpcap/config.h
===
RCS file: /usr/store/mlaier/fcvs/src/lib/libpcap/config.h,v
retrieving revision 1.5
diff -u -r1.5 config.h
--- lib/libpcap/config.h 29 May 2005 18:12:46 - 1.5
+++ lib/libpcap/config.h 30 Jun 2007 17:05:20 -
@@ -45,6 +45,9 @@
/* Define to 1 if you have the header file. */
#define HAVE_MEMORY_H 1
+/* Define to 1 if you have the header file. */
+#define HAVE_NET_PFVAR_H 1
+
/* Define to 1 if you have the header file. */
/* #undef HAVE_NETINET_ETHER_H */
Index: usr.sbin/tcpdump/tcpdump/config.h
===
RCS file: /usr/store/mlaier/fcvs/src/usr.sbin/tcpdump/tcpdump/config.h,v
retrieving revision 1.7
diff -u -r1.7 config.h
--- usr.sbin/tcpdump/tcpdump/config.h 11 Jul 2005 04:14:42 - 1.7
+++ usr.sbin/tcpdump/tcpdump/config.h 30 Jun 2007 17:06:34 -
@@ -193,6 +193,9 @@
/* Define to 1 if you have the header file. */
/* #undef HAVE_NETDNET_DNETDB_H */
+/* Define to 1 if you have the header file. */
+#define HAVE_NET_PFVAR_H 1
+
/* Define to 1 if you have the header file. */
/* #undef HAVE_NETINET_ETHER_H */
signature.asc
Description: This is a digitally signed message part.
Re: ifconfig carpdev
On Saturday 15 September 2007, Ingo Flaschberger wrote: > Ingo Flaschberger wrote: > > I have implemented at FreeBSD 6.2-STABLE. > > http://www.nabble.com/file/p12686194/carpdev.diff carpdev.diff > > Is a working solution, but not 100% failsave. > > See fixme. > > argl.. need some more tweaks. > > carp adds only a hostroute, and no network. > fixed that it add a network, but now kernels cries to receive the arp > at the parent interface and not at the carp interface... There is a lot more to this. Please hold your breath just a few more days and I'll have a working sollution as promised. Also, the proposed ioctl change is not the preferred way of doing things. If you pass in an interface index, there is no way of making sure that the interface didn't change underneath you - that's why we rather pass the whole string and do the resolution in the kernel. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pfctl -e and pfctl -d kills all connections
On Wednesday 19 September 2007, Abdullah Ibn Hamad Al-Marri wrote: > Hello Guys, > > Here are my full rules. > > When I pfctl -e or pfctl -d all connections will die. ... "rules with synproxy state" > Do you know the cause? see above. Using "synproxy state" causes pf to complete the 3WHS before contacting the other endpoint, hence it has to translate all future sequence numbers for this connection. If you disable pf, the translation goes away and the connection dies. The same thing happens if you use "modulate state". For the "pfctl -e" case: The pf in CURRENT uses "keep state flags S/SA" by default for any tcp pass rule. That means that it will only match on the initial SYN that starts the connection. The rest of the connection is then passed based on the state entry. Consequently any pre-existing connection will not have a state entry and be blocked. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: ifconfig carpdev
On Saturday 15 September 2007, I wrote:
> On Saturday 15 September 2007, Ingo Flaschberger wrote:
> > Ingo Flaschberger wrote:
> > > I have implemented at FreeBSD 6.2-STABLE.
> > > http://www.nabble.com/file/p12686194/carpdev.diff carpdev.diff
> > > Is a working solution, but not 100% failsave.
> > > See fixme.
> >
> > argl.. need some more tweaks.
> >
> > carp adds only a hostroute, and no network.
> > fixed that it add a network, but now kernels cries to receive the arp
> > at the parent interface and not at the carp interface...
>
> There is a lot more to this. Please hold your breath just a few more
> days and I'll have a working sollution as promised. Also, the proposed
> ioctl change is not the preferred way of doing things. If you pass in
> an interface index, there is no way of making sure that the interface
> didn't change underneath you - that's why we rather pass the whole
> string and do the resolution in the kernel.
So here you go ... this is the ***ALPHA*** version of carpdev support.
Note that there are *a lot* of raw edges, untested areas and missing
features still, but "it's working"[tm].
For the moment that means the IPv4 carpdev case is working. i.e.
configuring a carp on an otherwise unused interface:
ifconfig carp create
ifconfig carp0 carpdev rl0 vhid 1 pass foo 10.0.0.1
ifconfig rl0 up
This patch is FYI, not something I'd recommend to use or even test. I'll
do cleanup, testing and polishing over the coming days and let you know
when it's in testable shape.
This work is generously sponsored by pil.dk.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
--- //depot/vendor/freebsd/src/sbin/ifconfig/ifcarp.c 2005/02/22 14:37:13
+++ //depot/user/mlaier/carp2/sbin/ifconfig/ifcarp.c 2007/09/12 16:12:46
@@ -52,13 +52,7 @@
static const char *carp_states[] = { CARP_STATES };
-void carp_status(int s);
-void setcarp_advbase(const char *,int, int, const struct afswtch *rafp);
-void setcarp_advskew(const char *, int, int, const struct afswtch *rafp);
-void setcarp_passwd(const char *, int, int, const struct afswtch *rafp);
-void setcarp_vhid(const char *, int, int, const struct afswtch *rafp);
-
-void
+static void
carp_status(int s)
{
const char *state;
@@ -76,17 +70,17 @@
else
state = carp_states[carpr.carpr_state];
- printf("\tcarp: %s vhid %d advbase %d advskew %d\n",
- state, carpr.carpr_vhid, carpr.carpr_advbase,
- carpr.carpr_advskew);
+ printf("\tcarp: %s carpdev %s vhid %d advbase %d advskew %d\n",
+ state, carpr.carpr_carpdev, carpr.carpr_vhid,
+ carpr.carpr_advbase, carpr.carpr_advskew);
}
return;
}
-void
-setcarp_passwd(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_passwd, val, d)
{
struct carpreq carpr;
@@ -105,8 +99,8 @@
return;
}
-void
-setcarp_vhid(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_vhid, val, d)
{
int vhid;
struct carpreq carpr;
@@ -130,8 +124,8 @@
return;
}
-void
-setcarp_advskew(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_advskew, val, d)
{
int advskew;
struct carpreq carpr;
@@ -152,8 +146,8 @@
return;
}
-void
-setcarp_advbase(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_advbase, val, d)
{
int advbase;
struct carpreq carpr;
@@ -174,11 +168,51 @@
return;
}
+static
+DECL_CMD_FUNC(setcarp_carpdev, val, d)
+{
+ struct carpreq carpr;
+
+ memset((char *)&carpr, 0, sizeof(struct carpreq));
+ ifr.ifr_data = (caddr_t)&carpr;
+
+ if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGVH");
+
+ strlcpy(carpr.carpr_carpdev, val, sizeof(carpr.carpr_carpdev));
+
+ if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSVH");
+
+ return;
+}
+
+static
+DECL_CMD_FUNC(setcarp_unsetcarpdev, val, d)
+{
+ struct carpreq carpr;
+
+ memset((char *)&carpr, 0, sizeof(struct carpreq));
+ ifr.ifr_data = (caddr_t)&carpr;
+
+ if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGVH");
+
+ memset(carpr.carpr_carpdev, 0, sizeof(carpr.carpr_carpdev));
+
+ if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSVH");
+
+ return;
+}
+
static struct cmd carp_cmds[] = {
DEF_CMD_ARG("advbase", setcarp_advbase),
DEF_CMD_ARG("advskew", setcarp_advskew),
DEF_CMD_ARG("pass", setcarp_passwd),
DEF_CMD_ARG("vhid", setcarp_vhid),
+ DEF_CMD_ARG("carpdev", setcarp_carpdev),
+ DEF_CMD_OPTARG("-carpdev", setcarp_uns
Re: Weird Problem with NAT
On Friday 21 September 2007, Washington Odhiambo wrote:
> Hello people,
>
> I have a box which I'd like to do some port forwarding to two boxes on
> my internal LAN.
>
> I have reduced my pf.conf to just the following:
>
> # define macros for each network interface
> extif = "em0"
> intif = "xl0"
> server = "192.168.0.2"
> exch_svr = "192.168.0.26"
>
> services="{ 80, 110, 443, 53 }"
> exchange_svcs="{ 3000 }"
>
> rdr pass on $extif inet proto tcp to port $services -> $server
> rdr pass on $extif inet proto tcp to port $exchange_svcs -> $exch_svr
> port 80 rdr pass on $extif inet proto { tcp, udp } to port $services ->
> $server
>
>
> Well, this server's external IP is 212.22.160.35, if anyone is
> interested.
>
> I have been trying whole day to get "telnet 212.22.160.35 110" to
> work, but it wouldn't.
From where?
> From the server, I can connect to 192.168.0.2 port 110 without a
> problem.
>
> I am stuck at the moment.
>
> What am I missing?
>
> FreeBSD 6.2-STABLE here.
The dumps you sent in the other mail are pretty useless. What is required
is a dump from the internal interface and/or from the destination router
itself.
Are you sure you got the routing right on all boxes? Do you have
net.inet.ip.forwarding enabled? Where are you trying from?
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
signature.asc
Description: This is a digitally signed message part.
Re: Rule doubt
On Thursday 27 September 2007, David Verzolla wrote: > Hi All, > Its possible creates a rule that can match all the traffic designated > to an specific interface? > > Example: > > pass in on $vlan10 from to (the interface, not the address) > $ext_if I'm not 100% sure what you are after here. The from/to part always takes an address as argument. You can use the "($ext_if)" syntax to dynamically fill in all addresses that are configured on the interface at the moment of evaluation, but you can't directly influence routing decisions. That means you can't write a single rule that says "traffic from $vlan10 must only go to $ext_if". In order to do this, you should take a look at tagging. > The $ext_if:network doesn't works for me. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: ifconfig carpdev
On Friday 12 October 2007, Alexandre Biancalana wrote: > On 9/19/07, Max Laier <[EMAIL PROTECTED]> wrote: > > So here you go ... this is the ***ALPHA*** version of carpdev > > support. Note that there are *a lot* of raw edges, untested areas and > > missing features still, but "it's working"[tm]. > > Hi Max ! > > Any Beta version is coming ? hacking away on it ... got it to panic twice earlier, but in terms of functionality it's done (for IPv4) ... I'll put out a beta for IPv4 ASAP. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: ifconfig carpdev
On Friday 12 October 2007, Gergely CZUCZY wrote: > On Fri, Oct 12, 2007 at 06:55:02AM +0200, Max Laier wrote: > > On Friday 12 October 2007, Alexandre Biancalana wrote: > > > On 9/19/07, Max Laier <[EMAIL PROTECTED]> wrote: > > > > So here you go ... this is the ***ALPHA*** version of carpdev > > > > support. Note that there are *a lot* of raw edges, untested areas > > > > and missing features still, but "it's working"[tm]. > > > > > > Hi Max ! > > > > > > Any Beta version is coming ? > > > > hacking away on it ... got it to panic twice earlier, but in terms of > > functionality it's done (for IPv4) ... I'll put out a beta for IPv4 > > ASAP. > > When It's Done, will it hit RELENG_7? There is one ABI breakage in the patch (the change of the ioctl structure to include the carpdev name). It might be possible to backdoor this through SIOCGPRIVATE_0 or similar - in which case it would be MFC'able. In any case there is still a lot of work to be done. 7.0 certainly not, 7.1 maybe ... 8.0 very likely (unless something completely different is implemented by then). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: PF and UID
On Tuesday 16 October 2007, Lorenz Helleis wrote: > Hello... > > Can I create a rule using PF and UID ? > > like this: > > " permit uid 1005 tcp port 22 " > > thanks The syntax is very different, but yes - pf does support matching by user credentials on the socket in question. The pf.conf(5) man page explains in detail. Look for the "user"/"group" modifiers. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: disabling implicit creation of state for NAT, BINAT and RDR
On Wednesday 24 October 2007, Nex Mon wrote: > On 10/24/07, Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 24, 2007 at 01:50:55PM +0800, Nex Mon wrote: > > > hello, is there a way to disable implicit creation of states for > > > NAT, > > > > BINAT > > > > > and RDR rules? the man page of pf.conf says this: > > > > > > Note: nat, binat and rdr rules implicitly create state for > > > connections. > > > > Yes, translations require states. > > > > Imagine you have a connection from > > > > Client Gateway External > > 10.1.2.3 -> 62.65.145.30 -> 69.147.83.33 > > > > i.e. the client 10.1.2.3 sends a TCP SYN to external server > > 69.147.83.33. The NAT gateway replaces the source address with > > 62.65.145.30. > > > > Now the external server sends a TCP SYN+ACK back to 62.65.145.30. > > How would the gateway know that this packet is for 10.1.2.3, and > > needs the destination address translated back to 10.1.2.3, without a > > state entry? > > > > The state entry is the only part that holds this mapping information. > > Are you saying there is only one type of state for all the filter, RDR, > etc rules? I have this understanding that NAT has its own translation > table where it keeps states of NAT sessions. So in the example above, > the only way to apply filter rules for translated (reply)packets would > be at the internal interface? The translations states are different from the filter states. The former just record the addresses on each side to be able to do the translation, the later record the addresses to be able to match traffic to the state and consequently allow or deny it. Unless you use the "pass" modifier on the translation statement, a translation state does not automatically allow the matched traffic to flow. The pf.conf(5) manpage states: If the pass modifier is given, packets matching the translation rule are passed without inspecting the filter rules: rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \ port 8080 Otherwise you will have to have a pass rule for that traffic as well. > I'm curious about OpenBSD's implementation of "no state" which can be > applied to NAT, RDR, etc. Is there any chance this feature will be > supported in FreeBSD? The "no state" modifier is supported in FreeBSD (7.0 and later) for pass rules only. This is the same in OpenBSD. Translation rules allways have to keep state as they can otherwise not do the translation! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: spamd nonfunctioning due to power outage in SD
On Wednesday 24 October 2007, [EMAIL PROTECTED] wrote: > I had a power outage to our building due to the fires in San Diego and > it crashed those without UPSes. One of them is the spamd machine. I've > brought it back up and ran fsck on all volumes. However, mail will not > come into our mailboxes from outside but mail can be delivered to > outside recipients. I can telnet into the spamd machine and send mail > externally and internally. Postfix seems to be ok. When I stop pf, mail > from the outside of our LAN come pouring in. When I start up pf, > inbound mail comes to a stop. In the spamd log, I see all kinds of > connections being blacklisted and greylisted but still not one mail is > being delivered. I am using spamd-mywhite as my whitelist and put all > known GMail IP addresses on it. I then send an email from my GMail > account to this machine. It gets greylisted and eventually sits in the > greylist for quite a while. I also see ports 25 open on both external > and internal NICs and port 8025 open on the localhost interface. > > I need assistance in troubleshooting this. Running spamd 4.1.2 on > FreeBSD 6.2. We average 800 valid mail per day and so far in the last > 24 hours, not one mail has come through using the existing spamd > configuration. Wild guess: Did you forget to mount fdescfs(5) by default? I know I've been bitten by this before. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
carpdev ...
... the neverending story continues :-\
I am making progress ... really, really slowly as I'm not at the top of my
health (inflammation in my front teeth) and 7.0 got in the way, too.
Anyways, here is something for *BETA* testing. Nobody put this in
production (or you deserve whatever goes wrong). But if you have spare
time and lab machines, please test and report back! Details welcome ;)
IPv6 is still TBD.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
--- //depot/vendor/freebsd/src/contrib/pf/pflogd/pidfile.c 2007/07/03 14:46:49
+++ //depot/user/mlaier/carp2/contrib/pf/pflogd/pidfile.c 2007/09/12 12:13:13
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/contrib/pf/pflogd/pidfile.c,v 1.6 2007/07/03 14:08:49 mlaier Exp $ */
+/* $FreeBSD: src/contrib/pf/pflogd/pidfile.c,v 1.4 2005/05/03 16:55:20 mlaier Exp $ */
/* $OpenBSD: pidfile.c,v 1.5 2002/05/26 09:29:02 deraadt Exp $ */
/* $NetBSD: pidfile.c,v 1.4 2001/02/19 22:43:42 cgd Exp $ */
--- //depot/vendor/freebsd/src/contrib/pf/pflogd/pidfile.h 2007/07/03 14:46:49
+++ //depot/user/mlaier/carp2/contrib/pf/pflogd/pidfile.h 2007/09/12 12:13:13
@@ -1,3 +1,1 @@
-/* $FreeBSD: src/contrib/pf/pflogd/pidfile.h,v 1.3 2007/07/03 14:08:49 mlaier Exp $ */
-
int pidfile(const char *);
--- //depot/vendor/freebsd/src/sbin/ifconfig/ifcarp.c 2005/02/22 14:37:13
+++ //depot/user/mlaier/carp2/sbin/ifconfig/ifcarp.c 2007/09/12 16:12:46
@@ -52,13 +52,7 @@
static const char *carp_states[] = { CARP_STATES };
-void carp_status(int s);
-void setcarp_advbase(const char *,int, int, const struct afswtch *rafp);
-void setcarp_advskew(const char *, int, int, const struct afswtch *rafp);
-void setcarp_passwd(const char *, int, int, const struct afswtch *rafp);
-void setcarp_vhid(const char *, int, int, const struct afswtch *rafp);
-
-void
+static void
carp_status(int s)
{
const char *state;
@@ -76,17 +70,17 @@
else
state = carp_states[carpr.carpr_state];
- printf("\tcarp: %s vhid %d advbase %d advskew %d\n",
- state, carpr.carpr_vhid, carpr.carpr_advbase,
- carpr.carpr_advskew);
+ printf("\tcarp: %s carpdev %s vhid %d advbase %d advskew %d\n",
+ state, carpr.carpr_carpdev, carpr.carpr_vhid,
+ carpr.carpr_advbase, carpr.carpr_advskew);
}
return;
}
-void
-setcarp_passwd(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_passwd, val, d)
{
struct carpreq carpr;
@@ -105,8 +99,8 @@
return;
}
-void
-setcarp_vhid(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_vhid, val, d)
{
int vhid;
struct carpreq carpr;
@@ -130,8 +124,8 @@
return;
}
-void
-setcarp_advskew(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_advskew, val, d)
{
int advskew;
struct carpreq carpr;
@@ -152,8 +146,8 @@
return;
}
-void
-setcarp_advbase(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_advbase, val, d)
{
int advbase;
struct carpreq carpr;
@@ -174,11 +168,51 @@
return;
}
+static
+DECL_CMD_FUNC(setcarp_carpdev, val, d)
+{
+ struct carpreq carpr;
+
+ memset((char *)&carpr, 0, sizeof(struct carpreq));
+ ifr.ifr_data = (caddr_t)&carpr;
+
+ if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGVH");
+
+ strlcpy(carpr.carpr_carpdev, val, sizeof(carpr.carpr_carpdev));
+
+ if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSVH");
+
+ return;
+}
+
+static
+DECL_CMD_FUNC(setcarp_unsetcarpdev, val, d)
+{
+ struct carpreq carpr;
+
+ memset((char *)&carpr, 0, sizeof(struct carpreq));
+ ifr.ifr_data = (caddr_t)&carpr;
+
+ if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGVH");
+
+ memset(carpr.carpr_carpdev, 0, sizeof(carpr.carpr_carpdev));
+
+ if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSVH");
+
+ return;
+}
+
static struct cmd carp_cmds[] = {
DEF_CMD_ARG("advbase", setcarp_advbase),
DEF_CMD_ARG("advskew", setcarp_advskew),
DEF_CMD_ARG("pass", setcarp_passwd),
DEF_CMD_ARG("vhid", setcarp_vhid),
+ DEF_CMD_ARG("carpdev", setcarp_carpdev),
+ DEF_CMD_OPTARG("-carpdev", setcarp_unsetcarpdev),
};
static struct afswtch af_carp = {
.af_name = "af_carp",
--- //depot/vendor/freebsd/src/sys/net/ethernet.h 2007/05/29 12:43:19
+++ //depot/user/mlaier/carp2/sys/net/ethernet.h 2007/09/19 18:47:18
@@ -380,6 +380,7 @@
extern void ether_ifattach(struct ifnet *, const u_int8_t *);
extern void ether_ifdetach(struct ifnet *);
extern int ether_ioctl(struct ifnet *, u_long, caddr_t);
+extern void ether_input(struct ifnet *, struct mbuf *);
extern int ether_output(struct ifnet *,
st
Re: carp_iamatch filling up system log
On Monday 05 November 2007, Mark Miles wrote: > I am getting a lot of errors using the carpdev BETA patch against HEAD > provided by Max a few days ago. I don't know if I should be concerned > about them or if they are just informational. These are the main two > carp/vlan devices causing errors, but it happens on others as well - > at random times. > > > carp_iamatch(vlan2, xx.xxx.xx.37, xx.xx.xxx.137, ...) > not: carp2 > carp_iamatch(vlan6, xx.xxx.xx.6, xx.xx.xxx.169, ...) > not: carp6 Ups ... left over debugging. I'll provide an updated patch in a bit. You can also just grep for that printf and comment it out. Thanks for testing! > fxp1: flags=8943 > metric 0 mtu 1500 > options=4b > ether 00:02:b3:4d:0b:58 > media: Ethernet 100baseTX > status: active > > vlan2: flags=8943 > metric 0 mtu 1500 > ether 00:02:b3:4d:0b:58 > media: Ethernet 100baseTX > status: active > vlan: 2 parent interface: fxp1 > > vlan6: flags=8943 > metric 0 mtu 1500 > ether 00:02:b3:4d:0b:58 > media: Ethernet 100baseTX > status: active > vlan: 6 parent interface: fxp1 > > carp2: flags=8843 metric 0 mtu > 1500 ether 00:00:5e:00:01:02 > inet xx.xxx.xxx.137 netmask 0xfff8 > carp: BACKUP carpdev vlan2 vhid 2 advbase 1 advskew 200 > > carp6: flags=8843 metric 0 mtu > 1500 ether 00:00:5e:00:01:06 > inet xx.xx.xxx.169 netmask 0xfff8 > carp: BACKUP carpdev vlan6 vhid 6 advbase 1 advskew 200 > > I also got this error when I had an IP on fxp0 and carp100 using > carpdev fxp0: > > arp: xx.xxx.xx.34 is on fxp0 but got reply from 00:03:47:71:a8:b3 on > carp100 carp_iamatch(fxp0, xx.xxx.xx.37, xx.xxx.xx.34, ...) > arp: xx.xxx.xx.33 is on fxp0 but got reply from 00:0c:f1:bb:66:84 on > carp100 I'll look into it. Looks like a too strict check for the carp case - i.e. the code should ignore this condition on carp interfaces, but somehow my check is wrong. > Please advise, I am filling up message logs at the rate of every 3 > hours!! > > On a side note, this machine is serves vlan trunks which is why I > needed carpdev in the first place (as to not waste more usable public > ips with two gateway ips in a /29 that are silent just to run the one > gateway needed), thus giving my customers 2 useable IP addresses. > With carpdev I can give them 5. Currently, an OpenBSD 4.2-current box > serves as the "MASTER" and I am using a FreeBSD 8.0-CURRENT box to > serve as "BACKUP". When I rebooted the OpenBSD box, everything failed > over as it should, but I got more carp_iamatch errors on almost every > vlan/carp pair. Could the OpenBSD <-> FreeBSD differences in carp be > causing these errors?? Neither are real errors, as far as I can tell ... I'll look into it in more detail and provide an updated patch. For now you can just shut up the printfs. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pflogd not logging certain rules
On Wednesday 07 November 2007, syle ishere wrote:
> pass in log proto { tcp, udp } from any to $ext_if port { 21, 22 }
> flags S/SA keep state \(max-src-conn 5, max-src-conn-rate 5/60,
> overload flush global)
>
> I use the "pass in LOG" here and it does not log at all.
> I go connect to port 21 or 22 and watch logs and nothing.
> My other logging rules do work for things like:
> pass in log proto tcp from any to $ext_if port 25 keep state
>
> So i know the logging actually does work, but the first line does not,
> any ideas?
Are you sure the rule is even hit? Check with "pfctl -vvvsr" and look at
the match/packets/bytes counters.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
signature.asc
Description: This is a digitally signed message part.
Re: About Packet Filter 4.2
On Tuesday 06 November 2007, Atanas Gendov wrote: > Dear developers, I found this mail and I hope this is the right > address. I have questions about new OpenBSD's PF 4.2. I found some > interesting news about PF http://www.onlamp.com/lpt/a/7155 > Me and many other people are interested to see PF 4.2 in FreeBSD 7, > because we like FreeBSD, but we use PF. Are you planning to include PF > 4.2 in FreeBSD 7 during the Beta versions? > Please give me an answer about PF on FreeBSD! :) We will first have to get 7.0 out of the door and look at the 4.2 improvements after that. There are some things in there that break ABI and will thus not be in any 7.x releases, but most of the performance improvements can easily be MFCed later on. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pf+ipv6 bug?
On Tuesday 13 November 2007, Mars G Miro wrote:
> Hiya,
>
> I've encountered this bug for about a few weeks now . The attached
> kernel config and the minimalist ruleset (i have a much more
> complicated ruleset), when pf is enabled and you have ipv6, when
> sending ipv6 packets? (in this case icmp6) to, say, your ipv6 default
> gw, will crash your box always at this spot:
>
> ++
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x1e8
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc094a726
> stack pointer = 0x28:0xe606dbc0
> frame pointer = 0x28:0xe606dc6c
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 17 (swi1: net)
> trap number = 12
> panic: page fault
> cpuid = 0
> Uptime: 1h35m21s
> Physical memory: 3955 MB
> Dumping 122 MB: 107 91 75 59 43 27 11
>
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) list *0xc094a726
> 0xc094a726 is in ip6_input (/usr/src/sys/netinet6/ip6_input.c:265).
> 260 ip6stat.ip6s_m1++;
> 261 #undef M2MMAX
> 262 }
> 263
> 264 /* drop the packet if IPv6 operation is disabled on the
> IF */ 265 if ((ND_IFINFO(m->m_pkthdr.rcvif)->flags &
> ND6_IFF_IFDISABLED)) {
> 266 m_freem(m);
> 267 return;
> 268 }
> 269
> ++
>
> Adding in ipv6 neighb* rules (comment out lines 47,48 in the attached
> ruleset) seem to not crash your box.
> This is on 7.0-BETA2 (i386,amd64) and from my own tests, this has
> been on 7.X, since around August back then. This does not seem to
> exist on 6.X.
Can you please get a complete trace and print the mbuf in the ip6_input
frame?
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
signature.asc
Description: This is a digitally signed message part.
Re: 7-STABLE panic: mtx_lock() of spin mutex %s @ %s:%d
) of spin mutex
> ", size=256, format=0xc0703a01 "mtx_lock() of spin mutex %s @ %s:%d",
> ap=0xccd41a08 " Mo??\001") at /usr/src/sys/kern/subr_prf.c:483 #12
> 0xc05152f3 in panic (fmt=0xc0703a01 "mtx_lock() of spin mutex %s @
> %s:%d") at /usr/src/sys/kern/kern_shutdown.c:530
> #13 0xc0509eba in _mtx_lock_flags (m=0xc1d3ad0c, opts=0,
> file=0xc06f4d20 "/usr/src/sys/contrib/altq/altq/altq_priq.c", line=416)
> at
> /usr/src/sys/kern/kern_mutex.c:180
> #14 0xc0437b83 in priq_class_destroy (cl=0xc22138c0) at
> /usr/src/sys/contrib/altq/altq/altq_priq.c:416
> #15 0xc0437c7d in priq_remove_altq (a=0xc2048a80) at
> /usr/src/sys/contrib/altq/altq/altq_priq.c:252
> #16 0xc0438635 in altq_remove (a=0xc2048a80) at
> /usr/src/sys/contrib/altq/altq/altq_subr.c:650
> #17 0xc04508ee in pf_commit_altq (ticket=5) at
> /usr/src/sys/contrib/pf/net/pf_ioctl.c:867
> #18 0xc0456341 in pfioctl (dev=0xc1d82600, cmd=3222029394,
> addr=0xc22d32e0 "\a", flags=3, td=0xc2014a50) at
> /usr/src/sys/contrib/pf/net/pf_ioctl.c:3170
> #19 0xc04bcfe9 in devfs_ioctl_f (fp=0xc20270d8, com=3222029394,
> data=0xc22d32e0, cred=0xc200bd00, td=0xc2014a50) at
> /usr/src/sys/fs/devfs/devfs_vnops.c:494
> #20 0xc054d563 in kern_ioctl (td=0xc2014a50, fd=3, com=3222029394,
> data=0xc22d32e0 "\a") at file.h:266
> #21 0xc054d6c4 in ioctl (td=0xc2014a50, uap=0xccd41cfc) at
> /usr/src/sys/kern/sys_generic.c:570
> #22 0xc06d07f3 in syscall (frame=0xccd41d38) at
> /usr/src/sys/i386/i386/trap.c:1008
> #23 0xc06b9770 in Xint0x80_syscall () at
> /usr/src/sys/i386/i386/exception.s:196
> #24 0x0033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) frame 13
> #13 0xc0509eba in _mtx_lock_flags (m=0xc1d3ad0c, opts=0,
> file=0xc06f4d20 "/usr/src/sys/contrib/altq/altq/altq_priq.c", line=416)
> at
> /usr/src/sys/kern/kern_mutex.c:180
> 180 KASSERT(LOCK_CLASS(&m->lock_object) == &lock_class_mtx_sleep,
> (kgdb) list
> 175 {
> 176
> 177 MPASS(curthread != NULL);
> 178 KASSERT(m->mtx_lock != MTX_DESTROYED,
> 179 ("mtx_lock() of destroyed mutex @ %s:%d", file, line));
> 180 KASSERT(LOCK_CLASS(&m->lock_object) == &lock_class_mtx_sleep,
> 181 ("mtx_lock() of spin mutex %s @ %s:%d",
> m->lock_object.lo_name, 182 file, line));
> 183 WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER |
> LOP_EXCLUSIVE,
> 184 file, line);
> (kgdb)
>
>
> As the panic/page fault seems to be connected to the altq/priq rules i
> have added the definition of the altq part
>
> altq on $ext_if priq bandwidth 960Kb qlimit 250 queue { std_out,
> smtp_out, ssh_out, tcp_ack_out }
>
> queue smtp_out priq(default) qlimit 250
> queue std_outpriority 2 qlimit 250
> queue ssh_out priority 5 qlimit 250
> queue tcp_ack_out priority 6 qlimit 250
>
> And of course there are some pass rules which add packets to the
> queues.
>
> Is there anything else needed from the core dump?
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
signature.asc
Description: This is a digitally signed message part.
ALTQ for dynamic interfaces [Re: 7-STABLE panic: mtx_lock() of spin mutex %s @ %s:%d]
On Tuesday 27 November 2007, Florian Smeets wrote:
> Max Laier wrote:
> > On Tuesday 27 November 2007, Florian Smeets wrote:
> >> Hi
> >>
> >> i was able to reproduce a hang on a 7-STABLE (csuped just after
> >> Scotts critical section MFC) firewall which runs mpd4 from ports and
> >> uses pf for packet filtering. Sometimes when i restart mpd4 the box
> >> just hangs. I have a up-script which calls /sbin/pfctl -f
> >> /etc/pf.conf.
> >
> > It's an ALTQ problem, really. I don't know if there is a down-script
> > that runs before the interface is destroyed, but if there is - adding
> > pfctl -Fq there should work around your problem. I did have some
> > patches to have ALTQ working with dynamic interfaces, but I must have
> > dropped them. I'll see what I can dig up in the next few days.
>
> That would be great. I have a second non productive box where i can
> reproduce the problem. I'll be glad to test any patches.
Okay ... try this. Not final yet, but should be functional. With this
you should be able to:
1) Safely remove an interface with active queues
2) Re-add the interface and *magically* get the queues back
3) Write queue rules for non-existing interfaces
- Note that we will assume an MTU of 1500 and you have to specify a
fixed bandwidth as we don't know the interface's native speed
- Obviously these queues will be activated as soon as a matching
interface is created.
BUGS: Doesn't print queues on removed interfaces at all. Should be
changed to something like "queue foo on bar0 (N/A) ...", but it seems I
was too strict with the local_flags. The error handling might need some
work in order to avoid panic if something goes wrong while we de-activate
queues.
I'd like to hear back from you in order to see if I at least got the basic
workings right enough so you can survive the mpd interface destroy.
Could you - in addition to you current setup w/ if-up script - also test
the magic part? i.e. load the ruleset before loading mpd. This should
now be possible as long as you don't put "set loginterface" or fixed
interface-to-address src/dst in it \o/
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
diff --git a/contrib/pf/pfctl/pfctl_altq.c b/contrib/pf/pfctl/pfctl_altq.c
index 9104f5a..d2a21c8 100644
--- a/contrib/pf/pfctl/pfctl_altq.c
+++ b/contrib/pf/pfctl/pfctl_altq.c
@@ -154,6 +154,10 @@ print_altq(const struct pf_altq *a, unsigned level, struct node_queue_bw *bw,
}
printf("altq on %s ", a->ifname);
+#ifdef __FreeBSD__
+ if (a->local_flags)
+ printf("N/A ");
+#endif
switch (a->scheduler) {
case ALTQT_CBQ:
@@ -1145,7 +1149,11 @@ getifmtu(char *ifname)
sizeof(ifr.ifr_name))
errx(1, "getifmtu: strlcpy");
if (ioctl(s, SIOCGIFMTU, (caddr_t)&ifr) == -1)
+#ifdef __FreeBSD__
+ ifr.ifr_mtu = 1500;
+#else
err(1, "SIOCGIFMTU");
+#endif
if (shutdown(s, SHUT_RDWR) == -1)
err(1, "shutdown");
if (close(s))
diff --git a/contrib/pf/pfctl/pfctl_qstats.c b/contrib/pf/pfctl/pfctl_qstats.c
index 3eb2987..15695cb 100644
--- a/contrib/pf/pfctl/pfctl_qstats.c
+++ b/contrib/pf/pfctl/pfctl_qstats.c
@@ -157,7 +157,11 @@ pfctl_update_qstats(int dev, struct pf_altq_node **root)
warn("DIOCGETALTQ");
return (-1);
}
+#ifdef __FreeBSD__
+ if (pa.altq.qid > 0 && !pa.altq.local_flags) {
+#else
if (pa.altq.qid > 0) {
+#endif
pq.nr = nr;
pq.ticket = pa.ticket;
pq.buf = &qstats.data;
diff --git a/sys/contrib/pf/net/pf_if.c b/sys/contrib/pf/net/pf_if.c
index 74e9dcb..8b09cc3 100644
--- a/sys/contrib/pf/net/pf_if.c
+++ b/sys/contrib/pf/net/pf_if.c
@@ -893,6 +893,9 @@ pfi_attach_ifnet_event(void *arg __unused, struct ifnet *ifp)
{
PF_LOCK();
pfi_attach_ifnet(ifp);
+#ifdef ALTQ
+ pf_altq_ifnet_event(ifp, 0);
+#endif
PF_UNLOCK();
}
@@ -901,6 +904,9 @@ pfi_detach_ifnet_event(void *arg __unused, struct ifnet *ifp)
{
PF_LOCK();
pfi_detach_ifnet(ifp);
+#ifdef ALTQ
+ pf_altq_ifnet_event(ifp, 1);
+#endif
PF_UNLOCK();
}
diff --git a/sys/contrib/pf/net/pf_ioctl.c b/sys/contrib/pf/net/pf_ioctl.c
index 136e710..0681abf 100644
--- a/sys/contrib/pf/net/pf_ioctl.c
+++ b/sys/contrib/pf/net/pf_ioctl.c
@@ -787,7 +787,11 @@ pf_begin_altq(u_int32_t *ticket)
/* Purge the old altq list */
while ((altq = TAILQ_FIRST(pf_altqs_inactive)) != NULL) {
TAILQ_REMOVE(pf_altqs_inactive, altq, entries);
+#ifdef __FreeBSD__
+ if (altq->qname[0] == 0 && altq->local_flags == 0) {
+#else
if (altq->qname[0] == 0) {
+#endif
/* detach and destroy the disci
Re: carpdev ...
On Tuesday 04 December 2007, Alexandre Biancalana wrote:
> On Oct 27, 2007 7:11 PM, Max Laier <[EMAIL PROTECTED]> wrote:
> > ... the neverending story continues :-\
> >
> > I am making progress ... really, really slowly as I'm not at the top
> > of my health (inflammation in my front teeth) and 7.0 got in the way,
> > too.
> >
> > Anyways, here is something for *BETA* testing. Nobody put this in
> > production (or you deserve whatever goes wrong). But if you have
> > spare time and lab machines, please test and report back! Details
> > welcome ;)
>
> Have someone tested this patch ? I'm about to put this in a
> production, not intessive or high traffic, but production environment.
>
> Any hints ?
The attached removes a debugging printf I left in by accident. There is
an additional printf in if_ether.c in line 684 that should be shut up in
the carp case, but I have the logic screwed up that should set
carp_match. You can shut it up for everything by setting sysctl
net.link.ether.inet.log_arp_wrong_iface=0, but that's only bandaid.
Other than that I'm not aware of any problems, panic or the like. Please
let me know how things go for you!
Oh ... IPv6 is not working with this patchset! The attachment is relative
to the patched source!
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
diff --git a/sys/netinet/ip_carp.c b/sys/netinet/ip_carp.c
index 7bb9404..aea3518 100644
--- a/sys/netinet/ip_carp.c
+++ b/sys/netinet/ip_carp.c
@@ -1213,17 +1213,9 @@ carp_iamatch(void *v, struct in_ifaddr *ia,
struct carp_softc *vh;
int index, count = 0;
struct ifaddr *ifa;
- char iastr[INET_ADDRSTRLEN];
- char isstr[INET_ADDRSTRLEN];
-
CARP_LOCK(cif);
- inet_ntoa_r(ia->ia_addr.sin_addr, iastr);
- inet_ntoa_r(*isaddr, isstr);
- printf("carp_iamatch(%s, %s, %s, ...)\n", cif->vhif_ifp->if_xname,
- iastr, isstr);
-
if (carp_opts[CARPCTL_ARPBALANCE]) {
/*
* XXX proof of concept implementation.
@@ -1275,11 +1267,8 @@ carp_iamatch(void *v, struct in_ifaddr *ia,
ia->ia_ifp == SC2IFP(vh) &&
vh->sc_state == MASTER) {
*enaddr = IF_LLADDR(vh->sc_ifp);
-printf("found: %s\n", vh->sc_ifp->if_xname);
CARP_UNLOCK(cif);
return (1);
- } else {
-printf("not: %s\n", vh->sc_ifp->if_xname);
}
}
}
signature.asc
Description: This is a digitally signed message part.
Re: carpdev ...
All,
the arp error print turned out to be a really stupid error - as suspected.
The attached should now be all quite and works for me in every possible
IPv4 scenario I could think up (mixed environment with OpenBSD and
unpatched FreeBSD tested, too).
All is still IPv4 only!!! But I'll see to remedy this last problem next
week.
I'd be very, very eager to hear test reports now! This is still use with
care etc. but you can easily patch your BACKUP for testing. The patch is
relative to HEAD and should apply to RELENG_7 ... I'll see what RELENG_6
does in a few days ... unless somebody beats me to it.
Please report in case of failure *and* success! Thanks.
This work is sponsored by pil.dk
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
diff --git a/sbin/ifconfig/ifcarp.c b/sbin/ifconfig/ifcarp.c
index 9c961b7..82dbd50 100644
--- a/sbin/ifconfig/ifcarp.c
+++ b/sbin/ifconfig/ifcarp.c
@@ -52,13 +52,7 @@
static const char *carp_states[] = { CARP_STATES };
-void carp_status(int s);
-void setcarp_advbase(const char *,int, int, const struct afswtch *rafp);
-void setcarp_advskew(const char *, int, int, const struct afswtch *rafp);
-void setcarp_passwd(const char *, int, int, const struct afswtch *rafp);
-void setcarp_vhid(const char *, int, int, const struct afswtch *rafp);
-
-void
+static void
carp_status(int s)
{
const char *state;
@@ -76,17 +70,17 @@ carp_status(int s)
else
state = carp_states[carpr.carpr_state];
- printf("\tcarp: %s vhid %d advbase %d advskew %d\n",
- state, carpr.carpr_vhid, carpr.carpr_advbase,
- carpr.carpr_advskew);
+ printf("\tcarp: %s carpdev %s vhid %d advbase %d advskew %d\n",
+ state, carpr.carpr_carpdev, carpr.carpr_vhid,
+ carpr.carpr_advbase, carpr.carpr_advskew);
}
return;
}
-void
-setcarp_passwd(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_passwd, val, d)
{
struct carpreq carpr;
@@ -105,8 +99,8 @@ setcarp_passwd(const char *val, int d, int s, const struct
afswtch *afp)
return;
}
-void
-setcarp_vhid(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_vhid, val, d)
{
int vhid;
struct carpreq carpr;
@@ -130,8 +124,8 @@ setcarp_vhid(const char *val, int d, int s, const struct
afswtch *afp)
return;
}
-void
-setcarp_advskew(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_advskew, val, d)
{
int advskew;
struct carpreq carpr;
@@ -152,8 +146,8 @@ setcarp_advskew(const char *val, int d, int s, const struct
afswtch *afp)
return;
}
-void
-setcarp_advbase(const char *val, int d, int s, const struct afswtch *afp)
+static
+DECL_CMD_FUNC(setcarp_advbase, val, d)
{
int advbase;
struct carpreq carpr;
@@ -174,11 +168,51 @@ setcarp_advbase(const char *val, int d, int s, const
struct afswtch *afp)
return;
}
+static
+DECL_CMD_FUNC(setcarp_carpdev, val, d)
+{
+ struct carpreq carpr;
+
+ memset((char *)&carpr, 0, sizeof(struct carpreq));
+ ifr.ifr_data = (caddr_t)&carpr;
+
+ if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGVH");
+
+ strlcpy(carpr.carpr_carpdev, val, sizeof(carpr.carpr_carpdev));
+
+ if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSVH");
+
+ return;
+}
+
+static
+DECL_CMD_FUNC(setcarp_unsetcarpdev, val, d)
+{
+ struct carpreq carpr;
+
+ memset((char *)&carpr, 0, sizeof(struct carpreq));
+ ifr.ifr_data = (caddr_t)&carpr;
+
+ if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGVH");
+
+ memset(carpr.carpr_carpdev, 0, sizeof(carpr.carpr_carpdev));
+
+ if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSVH");
+
+ return;
+}
+
static struct cmd carp_cmds[] = {
DEF_CMD_ARG("advbase", setcarp_advbase),
DEF_CMD_ARG("advskew", setcarp_advskew),
DEF_CMD_ARG("pass", setcarp_passwd),
DEF_CMD_ARG("vhid", setcarp_vhid),
+ DEF_CMD_ARG("carpdev", setcarp_carpdev),
+ DEF_CMD_OPTARG("-carpdev", setcarp_unsetcarpdev),
};
static struct afswtch af_carp = {
.af_name= "af_carp",
diff --git a/sys/amd64/conf/CARP b/sys/amd64/conf/CARP
new file mode 100644
index 000..710a970
--- /dev/null
+++ b/sys/amd64/conf/CARP
@@ -0,0 +1,4 @@
+includeGENERIC
+ident
Re: Spurious error from i[pf]_carp
On Friday 14 December 2007, Bruce M. Simpson wrote: > Tom Judge wrote: > > I guess that there will be more than one VRRP implementation that > > does not generate packets with a header the same size as the carp > > header. > > > > I will look into generating a patch for this over the weekend, > > however any thoughts/suggestions would be appreciated before I start > > working on it. > > Sounds fine to me, thanks for doing this. Alternatively you could change IPPROTO_CARP in netinet/in.h to another unused protocol number. This is really the preferred way of dealing with mixed CARP and VRRP environments as the CARP packets might in turn irritate the VRRP routers, too. > It is regrettable that CARP had to come into existence in the first > place because of the VRRP intellectual property situation, and I guess > this is one of the turds which end up floating in everyone's midst as a > result, if you'll pardon the analogy. /* no comment */ -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: occasional "Operation not permitted" on state-mismatch
On Tuesday 18 December 2007, Atrox wrote: > Atrox wrote: > > Hello! > > > > I have some FreeBSD-boxes (2x6.3-PRERELEASE (installed on 08.Dec), > > 1x6.2-RELEASE) with PF configured. They are connected with OpenVPN > > LAN-to-LAN > > and the problem is that a few times per hour connection drops between > > computers from one LAN to another. At first I blamed OpenVPN, then I > > blamed > > bridge, but now I've realized that the problem is in PF. > > So I've tried increasing TCP-timeouts and setting optimization > > to "aggressive", but well, it's still the same. > > > > I monitor connections by sending TCP packets once per second to some > > other host and wait for reply. I use Nagios-plugins' check_tcp for > > that. The script > > looks like: > > = > > while [ 1 ]; do > > pfctl -si |grep mismatch > > /usr/local/libexec/nagios/check_tcp -H $host -p $port -t 2 > > pfctl -si |grep mismatch > > sleep 1 > > done > > = > > > > So if I let this script into action, I see that in 2-3 minutes, > > check_tcp gets "Operation not permitted" error and just in this > > moment packet-mismatch > > counter is increased by one (on machine with lesser traffic, I get > > the timeout > > in a few hours). That's on both 6.3-PRERELEASE as well as on > > 6.2-RELEASE. I've > > tried connections: > > * along WAN to IPFW-enabled machines > > * along WAN to PF-enabled machines > > * along LAN to PF-enabled machines > > * along LAN to Windows machines > > * along VPN to PF-enabled machines > > * along VPN to Windows machines > > > > Sometimes I get just some connection timeout: CRITICAL - Socket > > timeout after > > 2 seconds (I don't know what could cause that). > > > > I can see this behaviour in about every FreeBSD/PF machine I have. > > > > The basic PF-configuration looks like: > > = > > set block-policy return > > set loginterface $ext_if > > set timeout tcp.closed 15 > > set optimization aggressive > > scrub in all no-df > > > > block drop out quick on $ext_if from ($ext_if) to 0.0.0.0 > > block log all > > pass quick on lo0 all > > pass out all modulate state > > pass out proto tcp all flags S/SA modulate state > > pass on $int_if all modulate state > > pass on $int_if proto tcp all flags S/SA modulate state > > pass in on $ext_if proto tcp from any to ($ext_if) port $tcp_services > > flags > > S/SA modulate state > > = > > > > Is PF buggy or have I misconfigured smth? > > Today I installed an OpenBSD-4.2 box just to see whether PF does the > same thing there. And yes, it does. > pf.conf: > = > ext_if = rl0 > set block-policy return > set loginterface $ext_if > scrub in all no-df > block drop out quick on $ext_if from ($ext_if) to 0.0.0.0 > pass all modulate state > pass quick on lo0 all > = > > I check TCP without "sleep 1" now, and I do it to FreeBSD box without > firewall. state-mismatch gets increased by one, and I get either "No > route to host" or "Socket timeout after 2 seconds". > > Am I still misconfiguring the thing? No idea, you don't give nearly enough data for us to figure out what your setup looks like. Regular tcp state mismatch usually hints that pf isn't seeing all packets of the conversation. This can be caused by triangular routing, load balanceing or if_bridge (which is difficult to get right in some scenarios). You should figure out the exact path your tcp packets are taking (back and forth) and make sure pf sees all of them. Enabling additional pf logging (pfctl -xm) helps to figure out what kind of mismatch is happening. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: PF not routing traffic to IPv4 interface when IPv6 is enabled
On Thursday 13 December 2007, Ryan Phillips wrote: > Ryan Phillips <[EMAIL PROTECTED]> said: > > Hi all, > > > > I just noticed that on my Freebsd server the PF firewall is not > > filtering packets for ipv4. Recently another admin enabled IPv6 > > within rc.conf, but we never assigned an IP6 IP. The interface has > > one IPv4 IP and many aliases for other IP4 IPs we own. > > Clarification: The IPv6 interface does have a ipv6 link local address. You don't give enough information to debug this problem. At very least your ruleset (-vvgsr) and ifconfig should be supplied. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Forwarding another host
On Friday 11 January 2008, Rodrique Heron wrote: > On 1/10/08, Michal Varga <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-01-10 at 12:10 -0500, Rodrique Heron wrote: > > > Thanks > > > > > > FreeBSD syntax for log all is "log-all", I have no block rules. I > > > am passing everything with. > > > > > > pass in quick all > > > pass out qick all > > > > ah, I think this may be another problem. Syntax for log (all) really > > *was* log-all, in PF 3.7, that is approximately the version used in > > FreeBSD 6.x. I somehow forgot about this from your first mail. As > > FreeBSD 7 incporporates PF 3.9, things behave a little differently > > here and there. anyway, can you show me the exact PF config you are > > using now, one that you think should work and doesn't? > > Sorry for the duplicate, I forgot to CC the list. > > Both host are in the same broadcast domain,connected to the same > switch. Sounds like you are looking for some kind of reflection rather than just redirection. If resources on the pf box are plenty and you don't mind running network daemons on it, something like net/rinetd might do the trick. > INTERNET > > > PIX Firewall > > > SWITCH*---*HOSTA 192.168.2.14 >* > > >* > HOSTB 192.168.2.27 > > > ### /etc/pf.conf > ext_if = "em0" > int_if = "lo0" > > host_ip = " 192.168.2.14" > jail_ip = "192.168.2.18" > external_host = "192.168.2.27" > > rdr on $ext_if proto tcp from any to $host_ip port 22 -> $external_host > port 22 > rdr on $ext_if proto tcp from any to $host_ip port 26 -> $jail_ip port > 22 > > pass in quick all > pass out quick all > ___ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: carpdev ...
On Wednesday 09 January 2008, Alexandre Biancalana wrote: > On 12/9/07, Max Laier <[EMAIL PROTECTED]> wrote: > > Please report in case of failure *and* success! Thanks. > > Hi Max ! > > Yesterday put one firewall running pf with this patch and everything > worked perfect ! (until now). I just tested the running config with > carp (real network interface without ip address and using ifconfig > carpdev option to associate carp interface with real network > interface) if nothing bad happened until tomorrow, I will put another > machine to test all carp faillover features and let you know. > > Thank you Max for your great work !! That's good to hear, keep us up to date! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: kern/120057: [patch] Allow proper settings of ALTQ_HFSC. The check i wrong since even with the values forbidden from this check you get a concave curve.
The following reply was made to PR kern/120057; it has been noted by GNATS. From: Max Laier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/120057: [patch] Allow proper settings of ALTQ_HFSC. The check i wrong since even with the values forbidden from this check you get a concave curve. Date: Mon, 28 Jan 2008 19:45:01 +0100 http://www.cs.cmu.edu/~hzhang/HFSC/main.html agrees with the pfctl restrictions. Can you give an example that is restricted by this check and shouldn't be? - Max ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR in pf on 6.2
Am Di, 29.01.2008, 19:37, schrieb Bill Marquette: > Been having some kernel locks on some machines at work, not sure if > this LOR is related (and I see an XXX LOR comment in the code too, so > I'm guessing it's been seen before) although I have certainly had some > of the machines lock during bootup right around the place that this > LOR prints out. > > Jan 29 12:11:46 1st 0xc09e4420 pf task mtx (pf task mtx) @ > /usr/src/sys/contrib/pf/net/pf.c:6386 > Jan 29 12:11:46 2nd 0xc0a5142c udp (udp) @ > /usr/src/sys/contrib/pf/net/pf.c:2744 > > I've got a couple machines that reliably lock w/in 24 hours or so of > uptime, I can easily test any source patches on them. All machines > are built off of FreeBSD 6.2-RELEASE-p10 sources. Thanks >From the pf.conf(5) in RELENG_6_2: BUGS Due to a lock order reversal (LOR) with the socket layer, the use of the group and user filter parameter in conjuction with a Giant-free netstack can result in a deadlock. If you have to use group or user you must set debug.mpsafenet to ``0'' from the loader(8), for the moment. This work- around will still produce the LOR, but Giant will protect from the dead- lock. A better fix is in RELENG_7 ... backporting won't make much sense. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Res: Dropped Packets
t; max session limit. I've had some of my firewalls over 1,000,000 > sessions without a problem. > > You may want to check your switch for errors and watch your interface > (netstat -I IFACE -nd 1) to see when/where your drops are. What kind of > cpu usage are you seeing when you start dropping the packets? > > Regards, > > Chris > > > > > > > Abra sua conta no Yahoo! Mail, o único sem limite de espaço para > armazenamento! http://br.mail.yahoo.com/ > ___ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Res: Res: Dropped Packets
AGAIN: PLEASE DON'T TOP-POST! Am Fr, 7.03.2008, 19:16, schrieb Lorenz Helleis: > Max.. > > the Current entry is not 5005. I got this value after "pfctl -d"... then these numbers are completely useless! > the number of concurrent connections is 70.000 Okay, so let's say every connection just passes ~10pps (that's not even 7kB/s with standard TCP) then you have to forward 700kpps. This is a *huge* load, even without firewalling. If you count in scrubbing and "just" statefull lookups, this is about the maximum that you can hope to push with commodity hardware. Sure, PCIe has removed one of the worst bottlenecks, but as I pointed out in my other reply - pf is still "giant"-locked and thus poses a bottleneck of it's own, but there are few (if any) alternatives. If you are serious about wanting a *firewall* for security. Otherwise you can use IPFW w/o states! Which will give some concurrency and less per-packet overhead due to fewer sanity checks. > > In this moment my firewall is disable until i find a solution to solve > this problem. I think i will try to increase the number of states and > change the NIC. > > I use a Gigabit card and the traffic is 300Mbs and the concurrent sessions > 70.000. > > And now i'm studing about tables entries, src-nodes .. > > > Provérbios 1:27 > > Mas Deus escolheu as coisas loucas deste mundo para confundir as > sábias; e Deus escolheu as coisas fracas deste mundo para confundir as > fortes; > > - Mensagem original > De: Max Laier <[EMAIL PROTECTED]> > Para: freebsd-pf@freebsd.org > Cc: Lorenz Helleis <[EMAIL PROTECTED]>; Chris Marlatt > <[EMAIL PROTECTED]> > Enviadas: Sexta-feira, 7 de Março de 2008 14:55:52 > Assunto: Re: Res: Dropped Packets > > [ please don't top-post ] > > On Friday 07 March 2008, Lorenz Helleis wrote: >> I don't think that is a hardware problem, sometimes the "congestion >> rate" increase to 1500,0/s and the "state-mismatch" to 300.0/s.. I >> don't know if it is normal... >> >> I think that the conections is being droped when increase a lot the >> number of packets on the network. >> >> >> >> can you tell me about your firewall ? I will need to install a biggest >> one here, and I'm a little afraid to do. Can you show me some >> configuration? the traffic of you network?, hardware? conections ? >> >> look some configurations do i need to increase something ? >> >> >> # pfctl -sm >> stateshard limit 10 >> src-nodes hard limit1 >> frags hard limit 5000 >> tableshard limit 1000 >> table-entries hard limit 20 >> >> >> # top >> >> load averages: 0.20, 0.12, 0.09 >> 13:29:40 35 processes: 34 idle, 1 on processor >> CPU0 states: 0.6% user, 0.0% nice, 0.7% system, 0.0% interrupt, >> 98.7% idle CPU1 states: 0.1% user, 0.0% nice, 0.2% system, 0.0% >> interrupt, 99.7% idle >> >> # vmstat -i >> >> interrupt total rate >> irq0/clock 257506609 199 >> irq0/ipi183393879 142 >> irq81/em0 8638587188 6706 >> irq83/skc0 6011660768 4667 >> irq80/fxp0 2292732543 1779 > > These interrupt numbers don't seem to match up with the above load > numbers. I'd expect a higher interrupt load. You could also try to > replace the sk(4) adapter with another em(4) or the like? I have had > trouble with sk(4) in the past. > >> irq64/ahc070125605 >> irq112/pckbc0 80 >> Total 1739089355513501 >> >> # pfctl -si >> >> State Table Total Rate >> current entries 5005 >> searches 30026832082 441000.4/s > > 441kpps are quite a load! And this is with only 5000 connections. While > FreeBSD can forward 1Mpps and more on commodity hardware 500-700kpps is > probably the limit with (sensible) firewalling. It'd be surprised if you > could do significantly better with anything else. N.B. that this could > be improved by using fine grained locking for pf - this is on my TODO > list for quite some time, but I didn't yet get to it. > >> inserts406964726 5977.0/s >> removals 406959721 5977.0/s >> Counters >> match 417436387
Re: kern/121668: connect randomly fails with EPERM with some pf rules
The following reply was made to PR kern/121668; it has been noted by GNATS.
From: Max Laier <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED],
[EMAIL PROTECTED]
Cc:
Subject: Re: kern/121668: connect randomly fails with EPERM with some pf rules
Date: Thu, 13 Mar 2008 20:26:39 +0100
> sysctl net.inet.tcp.nolocaltimewait=1
> not needed, but helps to reproduce the problem with client and server
> on the same computer.
Okay, now this is just asking for trouble. pf does thorough checks on TCP
states, one of which is to enforce the 2MSL quite time before port reuse.
If you set above sysctl you specificly ask FreeBSD to break that rule and
thus cause pf to bark.
You can also hit the issue if you have a large number of (consecutive)
connections between two hosts (e.g. [poorly configured] squid ->
www-backends, mysql, ...). The sollution is to:
1) Reduce the connection spree and use one permanent connection
2) Increase the ephemeral port range net.inet.ip.portrange.hi{first,last}
3) Decrease the pf state timeout tcp.{closing,closed} in order to relax
the check. You can do this globaly and on a per-rule basis.
-- Max
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bacula File/Storage Connection Woes using PF
168.1.17.54569: P 125:203(78) ack 271 win 33304 16163441[|tcp]> > 100679 rule 16/0(match): pass out on xl0: 192.168.1.25.9102 > > 192.168.1.17.54569: . ack 289 win 33304 16163542[|tcp]> 000913 rule 16/0(match): pass out on xl0: > 192.168.1.25.9102 > > 192.168.1.17.54569: P 203:223(20) ack 612 win 33304 16163542[|tcp]> > 000396 rule 16/0(match): pass out on xl0: 192.168.1.25.9102 > > 192.168.1.17.54569: P 223:241(18) ack 643 win 33304 16163543[|tcp]> > 099682 rule 16/0(match): pass out on xl0: 192.168.1.25.9102 > > 192.168.1.17.54569: . ack 699 win 33304 16163643[|tcp]> > > Why is the Bacula file daemon trying to contact the Bacula storage > daemon at port 54569 instead of port 9103? I'm guessing that rule 23 is > responsible for these log entries but am not sure as these entries > points to rule 16 as the matching rule. I am baffled by this as these > entries do not use 127.0.0.1 nor the rl0 interface. See above. I doubt this is a bug in pf. > What should happen is that the Bacula director daemon contacts the > client's Bacula file daemon at port 9102 from port 9101. The file > daemon on the client should contact the Bacula storage daemon at port > 9103 using port 9102 and executes the backup routine. More details at: > > http://bacula.org/en/rel-manual/Dealing_with_Firewalls.html#SECTION0047 >22000 > > The section suggests using port forwarding to redirect packets to port > 9103 but I have been unsuccessful. Please note that there is no > firewall between the client and the server- only that the mailfilter > client runs pf. > > My Bacula config on the server works fine as it can back up LAN clients > that are not using packet filter. From the rules you quote above, I don't see why pf should interfere with ports towards your internal net, but then again you might be having other rules loaded than you think you are - the pflog is a strong indication. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf and SMP and busy wires
On Wednesday 26 March 2008 17:02:03 Nejc Škoberne wrote: > I like pf very much and I was planning to use it as a "central" > firewall at one of the customers like this: > > subnet_3 > > > subnet_1 -- PF_firewall --- subnet_2 > > > internet_gw > > However, since these are subnets with many computers, these would be > gigabit connections. But, I am afraid that this machine would not be > able to process data with gigabit speeds. So my questions are: > > 1. Are there any real-life performance evaluations with PF as > firewall(s) (doing also NAT if possible)? Yes there are, but I don't have a concrete example at hand. NAT isn't all that expensive with pf. In general you can hope for up to 750kpps forwarding performance. If that's enough in your situation depends on the kind of traffic you are looking at. > 2. How efficiently does PF use SMP (FreeBSD 7.0)? Not at all. I have plans to change that, though: http://pf4freebsd.love2party.net/pflock/ N.B. this is a long shot and something for the 8.0 time frame. > 3. How much would I profit if I had a server with two Dual-Core Intel > processors? This means 4 cores, right? I guess this should be able to > process data with gigabit speed in the situation above? While pf is a serialization point, the rest of the processing (ether_input -> ip_input -> forward -> ip_output -> ether_output) and the internet servicing can run in parallel. If you just do forwarding the natural limit for parallelization is the number of interfaces, although you won't likely achieve that kind of parallelism more cores certainly help. If you add other processing - e.g. VPN endpoints - it's even better to have "spare" cores. > 4. How would PF scale if there were 5 or more such subnets instead of 3 > (with gigabit speeds)? The limiting factor for any firewall/packet forwarder are packets per second, not throughput (so much). pf on FreeBSD currently provides ~750kpps (1M has been reported with careful tuning). This is roughly 1Gbps with 1500 Byte packets. > 5. Are there any PF vs Cisco|Juniper|3Com layer3 switches comparisons? Not that I'm aware of, but pf on commodity hardware will always have an edge in the cost/performance column. You have to pay quite a bit to obtain a hardware solution that can really *firewall* 750kpps and this will usually fall short of pf in terms of additional features. Note for example, the possibility to build a redundant firewall with ARP load balancing using CARP and pfsync. > 6. What role does the network cards play when looking at performance? > Are there network cards which do more work by themselves to let CPU to > do other things? YES! Buying good network cards is essential! The general consensus seems to be to stick with Intel server cards. In any case stay away from the low end on-board stuff. The bus interface is also very important! The plain old PCI bus has a limit of ~1Gbps itself, so go for PCI-X or better yet PCIe. Buy a motherboard that offers more than one bus. In the end it very much depends on your traffic patterns and security if pf is the right choice for you. If you should really have steady 1Gbps streams between your subnets it very likely is not. But then again, there are very few alternatives to choose from. If you are only looking at sporadic inter-subnet communication and reliable, secure internet access for all of them (where usually the uplink is the limiting factor) - then FreeBSD and pf can certainly provide what you need. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/117827: [pf] [panic] kernel panic with pf and ng
The following reply was made to PR kern/117827; it has been noted by GNATS. From: Max Laier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/117827: [pf] [panic] kernel panic with pf and ng Date: Sat, 29 Mar 2008 01:56:36 +0100 Here are MFC patches for RELENG_6 and RELENG_7, please test and report back, thanks! http://people.freebsd.org/%7Emlaier/pf.dyn_altq.R6.diff http://people.freebsd.org/%7Emlaier/pf.dyn_altq.R7.diff -- Max ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/106400: [pf] fatal trap 12 at restart of PF with ALTQ if ng0 device has detached
The following reply was made to PR kern/106400; it has been noted by GNATS. From: Max Laier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/106400: [pf] fatal trap 12 at restart of PF with ALTQ if ng0 device has detached Date: Sat, 29 Mar 2008 01:56:46 +0100 Here are MFC patches for RELENG_6 and RELENG_7, please test and report back, thanks! http://people.freebsd.org/%7Emlaier/pf.dyn_altq.R6.diff http://people.freebsd.org/%7Emlaier/pf.dyn_altq.R7.diff -- Max ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pftop 0.7 in ports ?
On Tuesday 01 April 2008 01:27:23 Thomas Rasmussen wrote: > Any plans to update pftop in ports to 0.7 ? > > http://www.eee.metu.edu.tr/~canacar/pftop/ says: > Changes in version 0.7: > This version adds state filtering.. > > It would be very nice to have that on FreeBSD as well. I'll have a go at it, stay tuned. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pftop 0.7 in ports ?
On Tuesday 01 April 2008 14:24:25 Max Laier wrote:
> On Tuesday 01 April 2008 01:27:23 Thomas Rasmussen wrote:
> > Any plans to update pftop in ports to 0.7 ?
> >
> > http://www.eee.metu.edu.tr/~canacar/pftop/ says:
> > Changes in version 0.7:
> > This version adds state filtering..
> >
> > It would be very nice to have that on FreeBSD as well.
>
> I'll have a go at it, stay tuned.
Here you go, please test.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: Makefile
===
RCS file: /usr/store/mlaier/fcvs/ports/sysutils/pftop/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- Makefile 8 Sep 2007 18:14:51 - 1.9
+++ Makefile 1 Apr 2008 13:07:02 -
@@ -6,7 +6,7 @@
#
PORTNAME= pftop
-PORTVERSION= 0.6
+PORTVERSION= 0.7
CATEGORIES= sysutils net
MASTER_SITES= http://www.eee.metu.edu.tr/~canacar/
DISTNAME= ${PORTNAME}-${PORTVERSION}
@@ -45,6 +45,10 @@
post-patch:
@${REINPLACE_CMD} -e 's||"${FILESDIR}/queue.h"|g' \
${WRKSRC}/engine.c
+ @${REINPLACE_CMD} -e 's|__dead|__dead2|g' ${WRKSRC}/sf-gencode.h
+ @${REINPLACE_CMD} -e 's|__dead|__dead2|g' ${WRKSRC}/sf-gencode.c
+ @${REINPLACE_CMD} -e 's|#include ||g' \
+ ${WRKSRC}/sf-gencode.c
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/pftop ${PREFIX}/sbin
Index: distinfo
===
RCS file: /usr/store/mlaier/fcvs/ports/sysutils/pftop/distinfo,v
retrieving revision 1.6
diff -u -r1.6 distinfo
--- distinfo 8 Sep 2007 18:14:51 - 1.6
+++ distinfo 1 Apr 2008 12:31:34 -
@@ -1,3 +1,3 @@
-MD5 (pftop-0.6.tar.gz) = c84fb960d36e9a9271c211c98efae062
-SHA256 (pftop-0.6.tar.gz) = bc6e9f93405b6a941074e4e5454adb56c63e24b3def4660d32c826237a8faaba
-SIZE (pftop-0.6.tar.gz) = 26236
+MD5 (pftop-0.7.tar.gz) = 2fdef1e3fffc38ae40f27aa2dfdcf6fc
+SHA256 (pftop-0.7.tar.gz) = afde859fab77597e4aae1ef6b87f1bb26a5ad8cb2b1d7316a12e5098153492af
+SIZE (pftop-0.7.tar.gz) = 59765
Index: files/patch-ab
===
RCS file: files/patch-ab
diff -N files/patch-ab
--- files/patch-ab 29 Jan 2006 04:44:00 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,29 +0,0 @@
-*** pftop.c.orig Tue Jan 10 21:06:14 2006
pftop.c Sat Jan 21 04:47:06 2006
-***
-*** 2215,2226
- tb_print_fromto(&pr->src, &pr->dst, pr->af, pr->proto);
- #ifdef HAVE_RULE_UGID
- if (pr->uid.op)
- tb_print_ugid(pr->uid.op, pr->uid.uid[0], pr->uid.uid[1],
-! "user", UID_MAX);
- if (pr->gid.op)
- tb_print_ugid(pr->gid.op, pr->gid.gid[0], pr->gid.gid[1],
-! "group", GID_MAX);
- #endif
-
- if (pr->flags || pr->flagset) {
- tbprintf(" flags ");
2215,2226
- tb_print_fromto(&pr->src, &pr->dst, pr->af, pr->proto);
- #ifdef HAVE_RULE_UGID
- if (pr->uid.op)
- tb_print_ugid(pr->uid.op, pr->uid.uid[0], pr->uid.uid[1],
-! "user", UINT_MAX);
- if (pr->gid.op)
- tb_print_ugid(pr->gid.op, pr->gid.gid[0], pr->gid.gid[1],
-! "group", UINT_MAX);
- #endif
-
- if (pr->flags || pr->flagset) {
- tbprintf(" flags ");
Index: files/patch-pftop.c
===
RCS file: files/patch-pftop.c
diff -N files/patch-pftop.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/patch-pftop.c 1 Apr 2008 13:16:05 -
@@ -0,0 +1,40 @@
+*** pftop.c.orig 2007-11-07 07:36:46.0 +0100
+--- pftop.c 2008-04-01 15:14:04.666339681 +0200
+***
+*** 1570,1579
+ #ifdef HAVE_RULE_UGID
+ if (pr->uid.op)
+ tb_print_ugid(pr->uid.op, pr->uid.uid[0], pr->uid.uid[1],
+! "user", UID_MAX);
+ if (pr->gid.op)
+ tb_print_ugid(pr->gid.op, pr->gid.gid[0], pr->gid.gid[1],
+! "group", GID_MAX);
+ #endif
+
+ if (pr->flags || pr->flagset) {
+--- 1570,1579
+ #ifdef HAVE_RULE_UGID
+ if (pr->uid.op)
+ tb_print_ugid(pr->uid.op, pr->uid.uid[0], pr->uid.uid[1],
+! "user", UINT_MAX);
+ if (pr->gid.op)
+ tb_print_ugid(pr->gid.op, pr->gid.gid[0], pr->gid.gid[1],
+! "group", UINT_MAX);
+ #endif
+
+ if (pr->flags || pr->flagset) {
+***
+*** 1765,1771
+--- 1765,1776
+ strerror(errno));
+ return (-1);
+ }
++ #ifdef PFALTQ_FLAG_IF_REMOVED
++ if (pa.altq.qid > 0 &&
++ !(pa.altq.local_flags & PFALTQ_FLAG_IF_REMOVED)) {
++
Re: pftop 0.7 in ports ?
On Tuesday 01 April 2008 17:10:50 Thomas Rasmussen wrote: > When can we expect to see this in ports ? went in seconds before you hit send ;) mlaier 2008-04-01 15:10:35 UTC FreeBSD ports repository (src committer) Modified files: sysutils/pftop Makefile distinfo Added files: sysutils/pftop/files patch-pftop.c patch-sf-scanner.l Removed files: sysutils/pftop/files patch-ab Log: Update to 0.7 - adds state display filters. While here also add a patch to support dynamic ALTQ (by ignoring INACTIVE queues). Approved by:flz -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
