Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Sep 2020 14:09:13 -0400
From:      Lowell Gilbert <freebsd-questions-local@be-well.ilk.org>
To:        Kevin Oberman <rkoberman@gmail.com>
Cc:        "freebsd-questions@freebsd.org" <questions@freebsd.org>
Subject:   Re: ipfw matching traffic to broadcast (255.255.255.255)
Message-ID:  <44y2lc2pti.fsf@be-well.ilk.org>
In-Reply-To: <CAN6yY1uaRUJK9GnpM6jhhs2fauj2063VqGh2VUktP3Z2zVumTA@mail.gmail.com> (Kevin Oberman's message of "Fri, 11 Sep 2020 14:37:31 -0700")
References:  <CAN6yY1uaRUJK9GnpM6jhhs2fauj2063VqGh2VUktP3Z2zVumTA@mail.gmail.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Kevin Oberman <rkoberman@gmail.com> writes:

> I am seeing traffic from my cell phone to the broadcast address that I
> would like to block. I added a rule:
> 3220 deny udp from 192.168.1.18 9050 to any
> It shows no packet ever match even though I see many logged by my catch-all
> rule: 5999 deny log udp from any to any
> ipfw: 5999 Deny UDP 192.168.1.18:9050 255.255.255.255:9050 in via wlan0
>
> Why is the 3220 rule not matching the packets I see logged by 3220?

The second "3220" reference in that question is clearly supposed to
be 5999.

Offhand, I don't see why your 3220 is failing to match. One guess
would be that there could be a "skipto" type rule that jumps
ahead. One way to diagnose this would be to put a rule right after
3220 to see if it gets hit. I think a count rule might help,
(although there are some strange aspects to "count" that I don't
recall offhand). Perhaps even try several such rules; trying to
match it different ways might improve the odds of turning up a
clue. Adding a "log" modifier to 3220 might tell you something as
well, although I wouldn't bet on it.

Something special related to broadcast could be happening here,
because 3220 won't necessarily stop these packets that might be seen
elsewhere -- especially if the host running ipfw isn't the access
point. 

Also note that port 9050 is officially registered, even though
you're probably dealing with an unofficial use.

Good luck.



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?44y2lc2pti.fsf>