Re: ipfw NAT, igb and hardware checksums
This looks mostly sensible. hm! -a On 13 January 2016 at 11:55, Karim Fodil-Lemelin wrote: > Hi, > > I've hit a very interesting problem with ipfw-nat and local TCP traffic that > has enough TCP options to hit a special case in m_megapullup(). Here is the > story: > > I am using the following NIC: > > igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086 > rev=0x01 hdr=0x00 > > And when I do ipfw nat to locally emitted packets I see packets not being > processed in the igb driver for HW checksum. Now a quick search for m_pullup > in the igb driver code will show that our igb driver expects a contiguous > ethernet + ip header in igb_tx_ctx_setup(). Now the friendly m_megapullup() > in alias.c doesn't reserve any space before the ip header for the ethernet > header after its call to m_getcl like tcp_output.c (see m->m_data += > max_linkhdr in tcp_output.c). > > So the call to M_PREPEND() in ether_output() is forced to prepend a new mbuf > for the ethernet header, leading to a non contiguous ether + ip. This in > turn leads to a failure to properly read the IP protocol in the igb driver > and apply the proper HW checksum function. Particularly this call in > igb_tcp_ctx_setup(): ip = (struct ip *)(mp->m_data + ehdrlen); > > To reproduce the issue I simply create a NAT rule for an igb interface and > initiate a TCP connection locally going out through that interface (it > should go through NAT obviously) something like: > > ipfw nat 1 config igb0 reset > ipfw add 10 nat 1 via igb0 > > Although you need to make sure you fill enough of the SYN packet to trigger > the allocation of new memory in m_megapullup. You can do this by using > enough TCP options so its filling up almost all of the 256 mbuf or make > RESERVE something like 300 bytes in alias.c. > > The fix I propose is very simple and faster for all drivers, including the > ones that do perform a check for ether + ip to be contiguous upon accessing > the IP header. If the leading space is available it doesn't allocate any > extra space (as it should for most cases) but if for some reason the mbuf > used doesn't have 100 bytes (RESERVE in megapullup) of free space it will > reserve some at the front too. If the leading space isn't necessary then it > won't cause any harm. > > > -Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c > +Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c-dirty > diff --git a/freebsd/sys/netinet/libalias/alias.c > b/freebsd/sys/netinet/libalias/alias.c > index 876e958..dc424a6 100644 > --- a/freebsd/sys/netinet/libalias/alias.c > +++ b/freebsd/sys/netinet/libalias/alias.c > @@ -1757,7 +1757,8 @@ m_megapullup(struct mbuf *m, int len) { > * writable and has some extra space for expansion. > * XXX: Constant 100bytes is completely empirical. */ > #defineRESERVE 100 > - if (m->m_next == NULL && M_WRITABLE(m) && M_TRAILINGSPACE(m) >= RESERVE) > + if (m->m_next == NULL && M_WRITABLE(m) && > + M_TRAILINGSPACE(m) >= RESERVE && M_LEADINGSPACE(m) >= > max_linkhdr) > return (m); > > if (len <= MCLBYTES - RESERVE) { > @@ -1779,6 +1780,7 @@ m_megapullup(struct mbuf *m, int len) { > goto bad; > > m_move_pkthdr(mcl, m); > + mcl->m_data += max_linkhdr; > m_copydata(m, 0, len, mtod(mcl, caddr_t)); > mcl->m_len = mcl->m_pkthdr.len = len; > m_freem(m); > > It would be nice if some FBSD comitter could review and hopefully add this > patch to FBSD. > > Thank you, > > Karim. > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Firewall Profiling.
.. the idea was just to take the rules and generate a kld to load. There's no need to overly complicate things! Adrian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Firewall Profiling.
On 27 December 2011 22:32, Juli Mallett wrote: > Reloading of mbufs into DMA descriptors? mbuf allocator overhead > itself? Interrupts. Context switches under constant heavy load. > Some indirection in the network stack. Keeping caches primed? Not doing lots of very-deep-stack stuff for each packet, which is the bane of all current kernel-space UNIX implementations of frame forwarding? :) Adrian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: Firewall Profiling.
I can't help but remember when "someone" wrote an ipfw rule compiler - ie, take ipfw ruleset, generate C code. Maybe someone should write one and open source it this time.. :) Adrian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: layer2 ipfw 'fwd' support
On Mon, Oct 04, 2010, Julian Elischer wrote: >>> -Brandon >> Yes, its still required since ipfw fwd ignores layer2 frames. >> >> The application is the very same: squid. I mean, Lusca in fact (squid fork). >> >> Thank you for your interest. > > Cisco/Ironport have a patch that does this.. > I had permission to bring it back when I worked there but never got it > committed. > > Adrian, was it part of the set I gave you? I don't recall; but I'm happy to look at merging it into -head. I was more after L3 interception than L2 interception. Adrian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW MAX RULES COUNT PERFORMANCE
You may want to investigate using pf; i'm not sure whether they handle this better. Me, I'd investigate writing a "tree" ipfw rule type. Ie, instead of having a list of rules, all evaluated one at a time, I'd create a rule implementing a subrule match on ip/netmask with some kind of action (allow, deny, count, pipe, etc) rather than having it all be evaluated O(n) style. 2c, Adrian 2009/4/28 Daniel Dias Gonçalves : > Going to another example. > If I wanted that each authentication (username and password) in captive > portal, set up rules limiting the speed of the user's IP, as I do? I can > create two rules for the in / out for each user associated with a pipe? When > simulating this with a script adding hundreds of rules, the latency also > increases, as resolve this ? > > Adrian Chadd escreveu: >> >> You'd almost certainly be better off hacking up an extension to ipfw >> which lets you count a /24 in one rule. >> >> As in, the count rule would match on the subnet/netmask, have 256 32 >> (or 64 bit) integers allocated to record traffic in, and then do an >> O(1) operation using the last octet of the v4 address to map it into >> this 256 slot array to update counters for. >> >> It'd require a little tool hackery to extend ipfw in userland/kernel >> space to do it but it would work and be (very almost) just as fast as >> a single rule. >> >> 2c, >> >> >> >> Adrian >> >> 2009/4/23 Daniel Dias Gonçalves : >> >>> >>> Hi, >>> >>> My system is a FreeBSD 7.1R. >>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>> interfaces >>> increases the latency, causing large delays in the network, when I delete >>> COUNT rules, everything returns to normal, which can be ? >>> >>> My script: >>> >>> ipcount.php >>> -- CUT -- >>> >> $c=0; >>> $a=50100; >>> for($x=0;$x<=0;$x++) { >>> for($y=1;$y<=254;$y++) { >>> $ip = "192.168.$x.$y"; >>> system("/sbin/ipfw -q add $a count { tcp or udp } from any >>> to >>> $ip/32"); >>> system("/sbin/ipfw -q add $a count { tcp or udp } from >>> $ip/32 >>> to any"); >>> #system("/sbin/ipfw delete $a"); >>> $c++; >>> $a++; >>> } >>> } >>> echo "\n\nTotal: $c\n"; >>> ?> >>> -- CUT -- >>> >>> net.inet.ip.fw.dyn_keepalive: 1 >>> net.inet.ip.fw.dyn_short_lifetime: 5 >>> net.inet.ip.fw.dyn_udp_lifetime: 10 >>> net.inet.ip.fw.dyn_rst_lifetime: 1 >>> net.inet.ip.fw.dyn_fin_lifetime: 1 >>> net.inet.ip.fw.dyn_syn_lifetime: 20 >>> net.inet.ip.fw.dyn_ack_lifetime: 300 >>> net.inet.ip.fw.static_count: 262 >>> net.inet.ip.fw.dyn_max: 1 >>> net.inet.ip.fw.dyn_count: 0 >>> net.inet.ip.fw.curr_dyn_buckets: 256 >>> net.inet.ip.fw.dyn_buckets: 1 >>> net.inet.ip.fw.default_rule: 65535 >>> net.inet.ip.fw.verbose_limit: 0 >>> net.inet.ip.fw.verbose: 1 >>> net.inet.ip.fw.debug: 0 >>> net.inet.ip.fw.one_pass: 1 >>> net.inet.ip.fw.autoinc_step: 100 >>> net.inet.ip.fw.enable: 1 >>> net.link.ether.ipfw: 1 >>> net.link.bridge.ipfw: 0 >>> net.link.bridge.ipfw_arp: 0 >>> >>> Thanks, >>> >>> Daniel >>> ___ >>> freebsd-...@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >>> >> >> ___ >> freebsd-...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> >> >> > > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: IPFW MAX RULES COUNT PERFORMANCE
You'd almost certainly be better off hacking up an extension to ipfw which lets you count a /24 in one rule. As in, the count rule would match on the subnet/netmask, have 256 32 (or 64 bit) integers allocated to record traffic in, and then do an O(1) operation using the last octet of the v4 address to map it into this 256 slot array to update counters for. It'd require a little tool hackery to extend ipfw in userland/kernel space to do it but it would work and be (very almost) just as fast as a single rule. 2c, Adrian 2009/4/23 Daniel Dias Gonçalves : > Hi, > > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces > increases the latency, causing large delays in the network, when I delete > COUNT rules, everything returns to normal, which can be ? > > My script: > > ipcount.php > -- CUT -- > $c=0; > $a=50100; > for($x=0;$x<=0;$x++) { > for($y=1;$y<=254;$y++) { > $ip = "192.168.$x.$y"; > system("/sbin/ipfw -q add $a count { tcp or udp } from any to > $ip/32"); > system("/sbin/ipfw -q add $a count { tcp or udp } from $ip/32 > to any"); > #system("/sbin/ipfw delete $a"); > $c++; > $a++; > } > } > echo "\n\nTotal: $c\n"; > ?> > -- CUT -- > > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 262 > net.inet.ip.fw.dyn_max: 1 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 1 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 1 > net.inet.ip.fw.debug: 0 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > net.link.ether.ipfw: 1 > net.link.bridge.ipfw: 0 > net.link.bridge.ipfw_arp: 0 > > Thanks, > > Daniel > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"