Date: Tue, 3 May 2011 15:44:30 -0500 From: Korodev <korodev@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Table Insertion in C, Dummynet, and an interesting problem. Message-ID: <BANLkTinJOfP0xp%2Bv5yVe4qX5oHkYMKOk=A@mail.gmail.com> In-Reply-To: <20110503194730.GA35032@onelab2.iet.unipi.it> References: <BANLkTi=HXWu=Pix9-kj=B%2B%2BJRq17YbWyPg@mail.gmail.com> <20110503194730.GA35032@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi,
Thanks for your response! I was hoping you would reply. I was in the
middle of writing an update to my testing. Still no avail, but I've
been running some more tests and will include my results inline below:
> I am not aware of any significant delays between the setsockopt
> and the actual insertion in the table. There might be some locks
> involved but it is highly unlikely that it takes 150ms.
Exactly. I totally agree here. I'm doing the same thing on 6.2 (I
know, I know) and it works well. My next step is to try it in 7.4 and
see what happens.
> So, a few things to check
> 1. to test your insertion code, you should check whether the
> =C2=A0 address has ended up into the table, e.g. running
> =C2=A0 =C2=A0 =C2=A0 =C2=A0ipfw table 0 list
> =C2=A0 from the command line.
> =C2=A0 If the address is not there, you could always try and run
> =C2=A0 =C2=A0 =C2=A0 =C2=A0system("ipfw -n table 0 add n.n.n.n");
> =C2=A0 as a temporary workaround.
I've verified the IP does end up in the table via the 'ipfw table 0
list' method, the system("ipfw -n table 0 add *ip*") call, as well as
attempting to re-insert it immediately using setsockopt and confirming
that errno returns EEXIST. So the IP is definitely making it into the
table.
> 2. if the insertion code is correct, you could check if there is a timing
> =C2=A0 issue increasing the delay in the pipe to something larger until
> =C2=A0 the filtering works as you want. But i really doubt the problem
> =C2=A0 is here.
This is what's baffling. I can get it work when I introduce more
latency than I could ever afford, but it's still sporadic. When I have
the pipe set to 500ms, it gets blocked every time. It continually gets
less consistent going down from there., but it's never quite 100%
consistent until it consistently fails at anything under 250ms.
An unsuccessful test will show the IP in table 0 and the follow stats
when using 'ipfw show':
00100 2 168 count icmp from any to any
00300 2 168 pipe icmp from any to any
00400 2 168 count icmp from any to any
00500 0 0 deny log ip from any to any src-ip table(0)
00600 2 168 count icmp from any to any
65535 2873 609427 allow ip from any to any
While a successful test will still show the IP in table 0 and the
following stats. (Note the first packet doesn't make it through, so a
response is never received, which is why we only see 1 instead of 2
like above).
00100 1 84 count icmp from any to any
00300 1 84 pipe icmp from any to any
00400 1 84 count icmp from any to any
00500 1 84 deny log ip from any to any src-ip table(0)
00600 0 0 count icmp from any to any
65535 2873 609427 allow ip from any to any
I'm wondering if IPFW is looking ahead at the table entries and
computing the match before it actually gets to the rule. Please let me
know what other details I can provide.
\\korodev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinJOfP0xp%2Bv5yVe4qX5oHkYMKOk=A>