Re: ipfw NAT, igb and hardware checksums

[Adrian Chadd]

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: layer2 ipfw 'fwd' support

[Adrian Chadd]

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

[Adrian Chadd]

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 d...@yan.com.br:
 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 d...@yan.com.br:


 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

[Adrian Chadd]

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 d...@yan.com.br:
 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