Current problem reports assigned to freebsd-ipfw@FreeBSD.org
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/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem 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 [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets 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/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f 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/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n 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/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 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/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 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 42 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: ipfw table add problem
On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: On 24.11.2013 19:43, Özkan KIRIK wrote: Hi, I tested patch. This patch solves, ipfw table 1 add 4899 Ok. So I'll commit this fix soon. But, ipfw table 1 add 10.2.3.01 works incorrectly. output is below. # ./ipfw table 1 flush # ./ipfw table 1 add 10.2.3.01 inet_pton() does not recognize this as valid IPv4 address, so it is treated as usigned unteger key. It looks like this behavior is mentioned in STANDARDS section. # ./ipfw table 1 list 0.0.0.10/32 0 I'm wondering if so don't do that is really sufficient to deal with this? If it's not recognised as a valid address, shouldn't it fail to add anything, with a complaint? I don't see how a string containing dots can be seen as a valid unsigned integer? It's still not clear to me that inet_pton() is doing the right thing. Per the rfc cited earlier in the thread, it's not supposed to interpret the digits as octal or hex -- they are specifically declared to be decimal numbers. There's nothing invalid about 01 as a decimal number. The fact that many of us have a C-programming background and tend to think of leading-zero as implying octal doesn't change that. -- Ian ___ 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 table add problem
In message 1385391778.1220.4.ca...@revolution.hippie.lan, Ian Lepore writes: On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: On 24.11.2013 19:43, =D6zkan KIRIK wrote: Hi, = I tested patch. This patch solves, ipfw table 1 add 4899 Ok. So I'll commit this fix soon. = But, ipfw table 1 add 10.2.3.01 works incorrectly. output is below. # ./ipfw table 1 flush # ./ipfw table 1 add 10.2.3.01 inet_pton() does not recognize this as valid IPv4 address, so it is treated as usigned unteger key. It looks like this behavior is mention= ed in STANDARDS section. # ./ipfw table 1 list 0.0.0.10/32 0 = I'm wondering if so don't do that is really sufficient to deal with = this? If it's not recognised as a valid address, shouldn't it fail to = add anything, with a complaint? I don't see how a string containing = dots can be seen as a valid unsigned integer? It's still not clear to me that inet_pton() is doing the right thing. Per the rfc cited earlier in the thread, it's not supposed to interpret the digits as octal or hex -- they are specifically declared to be decimal numbers. There's nothing invalid about 01 as a decimal number. The fact that many of us have a C-programming background and tend to think of leading-zero as implying octal doesn't change that. But it does result in unexpected results when there is code that does treat 070 as 56 not 70. Rejecting ambigious input is a good thing. Part of what inet_pton() was trying to do was to get rid of the ambiguity in address inputs by tightening up the specification. 10.2.3.70 is not ambigious 10.2.3.070 is ambigious Mark -- Ian ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.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
