From owner-freebsd-questions@freebsd.org Mon Sep 14 18:09:28 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8656A3DE8A0 for ; Mon, 14 Sep 2020 18:09:28 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BqvWr2TLWz46LS for ; Mon, 14 Sep 2020 18:09:28 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: by mailman.nyi.freebsd.org (Postfix) id 534433DE89F; Mon, 14 Sep 2020 18:09:28 +0000 (UTC) Delivered-To: questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 530703DE903 for ; Mon, 14 Sep 2020 18:09:28 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4BqvWq1xFpz46WY for ; Mon, 14 Sep 2020 18:09:27 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: from lowell-desk.be-well.ilk.org (router.lan [172.30.250.2]) by be-well.ilk.org (Postfix) with ESMTP id CDB0733C1E; Mon, 14 Sep 2020 14:09:15 -0400 (EDT) Received: by lowell-desk.be-well.ilk.org (Postfix, from userid 1147) id 47CB41632ADF; Mon, 14 Sep 2020 14:09:14 -0400 (EDT) From: Lowell Gilbert To: Kevin Oberman Cc: "freebsd-questions@freebsd.org" Subject: Re: ipfw matching traffic to broadcast (255.255.255.255) References: Reply-To: "freebsd-questions@freebsd.org" Date: Mon, 14 Sep 2020 14:09:13 -0400 In-Reply-To: (Kevin Oberman's message of "Fri, 11 Sep 2020 14:37:31 -0700") Message-ID: <44y2lc2pti.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4BqvWq1xFpz46WY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-questions-local@be-well.ilk.org has no SPF policy when checking 23.30.133.173) smtp.mailfrom=freebsd-questions-local@be-well.ilk.org X-Spamd-Result: default: False [0.82 / 15.00]; HAS_REPLYTO(0.00)[questions@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.35)[-0.353]; NEURAL_SPAM_SHORT(0.03)[0.033]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[ilk.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.14)[0.137]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:23.30.0.0/15, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 18:09:28 -0000 Kevin Oberman 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.