Bug 123358 - [ipfw] ipfw add 1000 allow IP from any to any doesn't work
Summary: [ipfw] ipfw add 1000 allow IP from any to any doesn't work
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 6.3-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ipfw (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-03 07:40 UTC by edwin
Modified: 2018-05-28 19:47 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description edwin 2008-05-03 07:40:00 UTC
Loading an ipfw rule with "IP" instead of "ip" will enter the rule
properly in the list, but it never gets matched.

How-To-Repeat: 
    [/home/edwin] root@k7>ipfw add 100 allow IP from any to any
    00100 allow ip from any to any
    [/home/edwin] root@k7>ipfw add 100 allow ip from any to any
    00100 allow ip from any to any

    [/home/edwin] root@k7>ipfw -a list
    00100   0      0 allow ip from any to any
    00100 922 168617 allow ip from any to any
    65535 182  20023 deny ip from any to any

The first entry should be increasing, not the second.
Comment 1 Andrey V. Elsukov 2008-05-04 05:39:57 UTC
Edwin Groothuis wrote:
> Loading an ipfw rule with "IP" instead of "ip" will enter the rule
> properly in the list, but it never gets matched.
> 
>> How-To-Repeat:
> 
>     [/home/edwin] root@k7>ipfw add 100 allow IP from any to any
>     00100 allow ip from any to any
>     [/home/edwin] root@k7>ipfw add 100 allow ip from any to any
>     00100 allow ip from any to any
> 
>     [/home/edwin] root@k7>ipfw -a list
>     00100   0      0 allow ip from any to any
>     00100 922 168617 allow ip from any to any
>     65535 182  20023 deny ip from any to any
> 
> The first entry should be increasing, not the second.

Yes. When you are using "ip" or "all" as protocol, then
ipfw(8) doesn't make internal opcode and ipfw(9) matches
any packets. When you are using "IP" (parser is case sensitive),
then ipfw(8) makes a O_PROTO opcode and ipfw(9) matches it
with layer3 protocol number.
I don't know what is the best way to fix this problem.
I see three ways:
1. Don't do anything.
2. Make manual better (sorry, i'm not native english
speaker, so i can't).
3. Add quirk to ipfw(8) ti add_proto0 function, something
similar:
--- src/sbin/ipfw/ipfw2.c       27 Feb 2008 13:52:33 -0000      1.118
+++ src/sbin/ipfw/ipfw2.c       4 May 2008 04:38:24 -0000
@@ -4580,6 +4580,11 @@ add_proto0(ipfw_insn *cmd, char *av, u_c
         if (*ep != '\0' || proto <= 0) {
                 if ((pe = getprotobyname(av)) == NULL)
                         return NULL;
+
+               /* Is it an IP proto? */
+               if (pr->p_proto == 0)
+                       return (0);
+
                 proto = pe->p_proto;
         }

-- 
WBR, Andrey V. Elsukov
Comment 2 Volker Werth freebsd_committer freebsd_triage 2008-05-11 22:30:56 UTC
State Changed
From-To: open->analyzed


Andrey gave a good explanation - issue seems to be clear
Comment 3 andrew 2016-02-06 13:14:14 UTC
I think it is at least crucial to display the IP as IP when showing the command list

    [/home/edwin] root@k7>ipfw -a list
    00100   0      0 allow IP from any to any
    00100 922 168617 allow ip from any to any
    65535 182  20023 deny ip from any to any
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:22 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.