Current problem reports assigned to freebsd-ipfw@FreeBSD.org

[FreeBSD bugmaster]

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o kern/169206  ipfw   [ipfw] ipfw does not flush entries in table
o conf/167822  ipfw   [ipfw] [patch] start script doesn't load firewall_type
o kern/166406  ipfw   [ipfw] ipfw does not set ALTQ identifier for ipv6 traf
o kern/165939  ipfw   [ipw] bug: incomplete firewall rules loaded if tables 
o kern/165190  ipfw   [ipfw] [lo] [patch] loopback interface is not marking 
f kern/163873  ipfw   [ipfw] ipfw fwd does not work with 'via interface' in 
o kern/158066  ipfw   [ipfw] ipfw + netgraph + multicast = multicast packets
o kern/157796  ipfw   [ipfw] IPFW in-kernel NAT nat loopback / Default Route
o kern/157689  ipfw   [ipfw] ipfw nat config does not accept nonexistent int
f kern/155927  ipfw   [ipfw] ipfw stops to check packets for compliance with
o bin/153252   ipfw   [ipfw][patch] ipfw lockdown system in subsequent call 
o kern/153161  ipfw   [ipfw] does not support specifying rules with ICMP cod
o kern/152113  ipfw   [ipfw] page fault on 8.1-RELEASE caused by certain amo
o kern/148827  ipfw   [ipfw] divert broken with in-kernel ipfw
o kern/148689  ipfw   [ipfw] antispoof wrongly triggers on link local IPv6 a
o kern/148430  ipfw   [ipfw] IPFW schedule delete broken.
o kern/148091  ipfw   [ipfw] ipfw ipv6 handling broken.
o kern/143973  ipfw   [ipfw] [panic] ipfw forward option causes kernel reboo
o kern/143621  ipfw   [ipfw] [dummynet] [patch] dummynet and vnet use result
o kern/137346  ipfw   [ipfw] ipfw nat redirect_proto is broken
o kern/137232  ipfw   [ipfw] parser troubles
o kern/135476  ipfw   [ipfw] IPFW table breaks after adding a large number o
o kern/129036  ipfw   [ipfw] 'ipfw fwd' does not change outgoing interface n
p kern/128260  ipfw   [ipfw] [patch] ipfw_divert damages IPv6 packets
o kern/127230  ipfw   [ipfw] [patch] Feature request to add UID and/or GID l
f kern/122963  ipfw   [ipfw] tcpdump does not show packets redirected by 'ip
s kern/121807  ipfw   [request] TCP and UDP port_table in ipfw
o kern/121122  ipfw   [ipfw] [patch] add support to ToS IP PRECEDENCE fields
o kern/116009  ipfw   [ipfw] [patch] Ignore errors when loading ruleset from
o bin/104921   ipfw   [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a
o kern/104682  ipfw   [ipfw] [patch] Some minor language consistency fixes a
o kern/103454  ipfw   [ipfw] [patch] [request] add a facility to modify DF b
o kern/103328  ipfw   [ipfw] [request] sugestions about ipfw table
o kern/102471  ipfw   [ipfw] [patch] add tos and dscp support
o kern/97951   ipfw   [ipfw] [patch] ipfw does not tie interface details to 
o kern/95084   ipfw   [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v
o kern/86957   ipfw   [ipfw] [patch] ipfw mac logging
o bin/83046ipfw   [ipfw] ipfw2 error: "setup" is allowed for icmp, but s
o kern/82724   ipfw   [ipfw] [patch] [request] Add setnexthop and defaultrou
o bin/78785ipfw   [patch] ipfw(8) verbosity locks machine if /etc/rc.fir
o bin/65961ipfw   [ipfw] ipfw2 memory corruption inside add()
o kern/60719   ipfw   [ipfw] Headerless fragments generate cryptic error mes
s kern/55984   ipfw   [ipfw] [patch] time based firewalling support for ipfw
o kern/48172   ipfw   [ipfw] [patch] ipfw does not log size and flags
o kern/46159   ipfw   [ipfw] [patch] [request] ipfw dynamic rules lifetime f
a kern/26534   ipfw   [ipfw] Add an option to ipfw to log gid/uid of who cau

46 problems total.

___
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: Significant network latency when using ipfw and in-kernel NAT

[Soren Dreijer]

> what about the other one ? Also, please disable jumbo_mtu as well.
> On both inside and outside.

As far as I was able to tell, VLAN_HWCSUM cannot be disabled (or I
don't know which command to use):
http://lists.freebsd.org/pipermail/freebsd-net/2004-March/003464.html

I also don't know how to disable JUMBO_MTU and VLAN_MTU.

Disabling VLAN_HWCSUM didn't seem to do anything. Everything still has
just as much latency as before:

ix1: flags=8843 metric 0 mtu 1500
options=a8

Here is the current ruleset:

1  32195  17958479 allow ip from any to any via ix0
2  0 0 allow ip from any to any via gif0
3  14593   1030091 allow ip from any to any via gif1
4  17210  16260592 allow ip from any to any via gif2
5  0 0 allow ip from any to any via gif3
6  0 0 allow ip from any to any via lo0
00015  0 0 deny ip from 192.168.0.0/16 to any in via ix1
00016  0 0 deny ip from 172.16.0.0/12 to any in via ix1
00017  0 0 deny ip from 10.0.0.0/8 to any in via ix1
00018  0 0 deny ip from 127.0.0.0/8 to any in via ix1
00019  0 0 deny ip from 0.0.0.0/8 to any in via ix1
00020  0 0 deny ip from 169.254.0.0/16 to any in via ix1
00021  0 0 deny ip from 192.0.2.0/24 to any in via ix1
00022  0 0 deny ip from 204.152.64.0/23 to any in via ix1
00023  0 0 deny ip from 224.0.0.0/3 to any in via ix1
00025 11  1118 allow icmp from any to any icmptypes 3,11 in recv ix1
00026  6   264 deny icmp from any to any in recv ix1
00040  13121745760 nat 1 ip from any to any in recv ix1
00050  0 0 check-state
00100 17   924 skipto 805 tcp from any to any out xmit ix1
setup keep-state
00202   5903293907 skipto 600 tcp from any to 172.16.1.3 dst-port
443 in via ix1
00203  11289  15948611 skipto 805 tcp from 172.16.1.3 443 to any out xmit ix1
00204   7212451553 skipto 700 tcp from any to 172.16.1.4 dst-port
5222 in via ix1
00205   7377578378 skipto 805 tcp from 172.16.1.4 5222 to any out xmit ix1
00400 11  3564 deny ip from any to any via ix1
00500  0 0 pipe 1 ip from any to any in via ix1
00501  0 0 allow ip from any to any in via ix1
00600   5902293361 pipe 2 ip from any to any in via ix1
00601   5902293361 allow ip from any to any in via ix1
00700   7210451399 pipe 3 ip from any to any in via ix1
00701   7210451399 allow ip from any to any in via ix1
00800  0 0 pipe 4 ip from any to any in via ix1
00801  0 0 allow ip from any to any in via ix1
00805  18672  16520573 nat 1 ip from any to any out xmit ix1
00806  18672  16520573 allow ip from any to any
1  0 0 deny ip from any to any via ix1
65535 865391 867355171 allow ip from any to any

And the pipes:

1:  XX.000 Mbit/s0 ms burst 0
q131073  50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail
 sched 65537 type FIFO flags 0x0 0 buckets 0 active
2:  XX.000 Mbit/s0 ms burst 0
q131074  50 sl. 0 flows (1 buckets) sched 65538 weight 0 lmax 0 pri 0 droptail
 sched 65538 type FIFO flags 0x0 0 buckets 0 active
3: XX.000 Mbit/s0 ms burst 0
q131075  50 sl. 0 flows (1 buckets) sched 65539 weight 0 lmax 0 pri 0 droptail
 sched 65539 type FIFO flags 0x0 0 buckets 0 active
4:  XX.000 Mbit/s0 ms burst 0
q131076  50 sl. 0 flows (1 buckets) sched 65540 weight 0 lmax 0 pri 0 droptail
 sched 65540 type FIFO flags 0x0 0 buckets 0 active

Like I mentioned earlier, one-pass is set to 0 to allow for traffic to
be put back in to ipfw after going through NAT'ing and the pipes. That
couldn't affect negatively, right?

Cheers,
Soren

On Sun, Sep 16, 2012 at 11:21 PM, Luigi Rizzo  wrote:
> On Sun, Sep 16, 2012 at 10:39:36PM -0500, Soren Dreijer wrote:
>> Some more updates:
>>
>> I went ahead and disabled a few options on the ixgbe network interface
>> today (most notably rxcsum and txcsum), which improved ping times to
>> the FreeBSD box. I'm now able to reliably ping it with ~40ms from my
>> house. TCP traffic in general also seems to be slightly "better" as I
>> can actually 'wget google.com' now, although it's still horribly slow
>> and takes maybe 20 seconds or so to download.
>>
>> The ifconfig for the public adapter now looks like this:
>>
>> ix1: flags=8843 metric 0 mtu 1500
>> options=b8
>
> what about the other one ? Also, please disable jumbo_mtu as well.
> On both inside and outside.
>
> Finally, can you send the output of
> "ipfw show" and "ipfw pipe show" (anonymized if you like, but
> please preserve the counters) to see if there is any traffic
> that is looping ?
>
> thanks
> luigi
>
>>
>> I'm running out of ideas of what to do here...
>>
>> / Soren
>>
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@fr