https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #95 from Franco Fichtner ---
The mentioned information including commit in comment #58 helps with the
spurious dropping of unsolicited ND advertisements as expected then, for
details see
https://github.com/opnsense/src/issues/2
D Net
Onderwerp: Re: IPFW statefull firewall ruleset - some sites or applications do
not work as expected
Hi, unfortunately that's not the case, as I have onepass to off, meaning that
after every rule, the packet continues to be processed by the next rule (so the
NAT does get reached).
Hi, unfortunately that's not the case, as I have onepass to off, meaning
that after every rule, the packet continues to be processed by the next
rule (so the NAT does get reached).
Op do 14 nov 2024 om 11:17 schreef Ronald Klop :
> Op 02-11-2024 om 16:30 schreef Dries Michiels:
> > Hello,
> >
>
Op 02-11-2024 om 16:30 schreef Dries Michiels:
Hello,
So I have a very basic ruleset, as described in the FreeBSD handbook, see below. I have
"blurred" my open ports as seen in the ruleset below.
Igc0 is my WAN port and in the table "trusted_if" are like my LAN if and some
bridges.
1 reas
Hello,
So I have a very basic ruleset, as described in the FreeBSD handbook, see
below. I have "blurred" my open ports as seen in the ruleset below.
Igc0 is my WAN port and in the table "trusted_if" are like my LAN if and
some bridges.
1 reass ip from any to any in
00010 allow ip from any to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #91 from commit-h...@freebsd.org ---
A commit in branch releng/13.3 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=a16cd5ff50ea2e5954958d90ef6de18e0f1aa4bc
commit a16cd5ff50ea2e5954958d90ef6de18e0f1aa4bc
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #88 from commit-h...@freebsd.org ---
A commit in branch releng/14.0 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=2fd8437daed57e34e50beb50013910b64b456f91
commit 2fd8437daed57e34e50beb50013910b64b456f91
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #93 from commit-h...@freebsd.org ---
A commit in branch releng/13.3 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=7dabb892096e4e3ba7526914b94f97218d9690d3
commit 7dabb892096e4e3ba7526914b94f97218d9690d3
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #92 from commit-h...@freebsd.org ---
A commit in branch releng/13.3 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=f51f7cb8997f2e43047a84e937144c2ac7e84587
commit f51f7cb8997f2e43047a84e937144c2ac7e84587
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #94 from commit-h...@freebsd.org ---
A commit in branch releng/13.3 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=36265a707dc51189843498e059361010ea3c9718
commit 36265a707dc51189843498e059361010ea3c9718
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #89 from commit-h...@freebsd.org ---
A commit in branch releng/14.0 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=d1c4f6decb10c7dc826d4a3a27763dc3f531ffe5
commit d1c4f6decb10c7dc826d4a3a27763dc3f531ffe5
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #90 from commit-h...@freebsd.org ---
A commit in branch releng/14.0 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=9481d7a260822d20d60d582bfff20bdd754c49c5
commit 9481d7a260822d20d60d582bfff20bdd754c49c5
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #87 from commit-h...@freebsd.org ---
A commit in branch releng/14.1 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=fb925cf0a4b38bffc4c9733bae3212f07a481931
commit fb925cf0a4b38bffc4c9733bae3212f07a481931
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #85 from commit-h...@freebsd.org ---
A commit in branch releng/14.1 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=84b57a4c5b848d44ec0918c28d8c27bec948a151
commit 84b57a4c5b848d44ec0918c28d8c27bec948a151
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #86 from commit-h...@freebsd.org ---
A commit in branch releng/14.1 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=fdc0afd4391ef45b5dcba33238b37f135972d71a
commit fdc0afd4391ef45b5dcba33238b37f135972d71a
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Ed Maste changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Ed Maste changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #84 from doktornotor ---
(In reply to Gleb Smirnoff from comment #81)
> Finally, I'd like to remind that the project code of conduct applies not only
> to the developers with a commit access, but to all participants in any
> di
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #83 from Dr. Uwe Meyer-Gruhl ---
Just for reference:
I just created bugs https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281395
and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281397.
--
You are receiving this mail be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #82 from Franco Fichtner ---
Thanks for the response!
Based on this particular resolution in Comment 81, OPNsense will back out the
SA in full effective with the next stable release 24.7.4 and we wish all
involved parties the b
|Closed
--- Comment #81 from Gleb Smirnoff ---
The first and original regression reported with this bug has been resolved and
fixed. The original bug report
> replies to ping initiated from machines on networks behind pf firewall/NAT
> to anything outside the local ne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #80 from doktornotor ---
As for the technical input: here is another *downstream* issue [1] with pf
debug log (i.e., set debug misc) getting flooded (300K+/day) with
> pf: ICMP error message too short (ip6)
from ND (NS/NA) pac
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #79 from commit-h...@freebsd.org ---
A commit in branch releng/13.4 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=d3ee2188686dce00083ba382c1a773d4e293b242
commit d3ee2188686dce00083ba382c1a773d4e293b242
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #78 from doktornotor ---
(In reply to Gleb Smirnoff from comment #77)
Well, until that balanced resolution is reached, here's some reading for the
involved maintainer, as well as for amusement of other FreeBSD users affected
by
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #77 from Gleb Smirnoff ---
FreeBSD Core team is looking at this issue. The parties in the dispute
have a long story of heated conversation, so it will take a few days to
come up with a balanced resolution. I ask everybody to s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Miroslav Lachman <000.f...@quip.cz> changed:
What|Removed |Added
CC||000.f...@quip.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #75 from Franco Fichtner ---
(In reply to Dag-Erling Smørgrav from comment #73)
Dag, you may think this SA makes FreeBSD look good, but I assure you that it
does not. Dunking on reporters while involved individuals are sharing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #74 from doktornotor ---
(In reply to Dr. Uwe Meyer-Gruhl from comment #70)
MFC after: 1 week gets merged in 3 days to stable, all concerns here ignored.
Just great.
> So, as far as communication goes, this is by far the wors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #73 from Dag-Erling Smørgrav ---
Franco, you may think comment 57 makes you look good, but I assure you that it
does not.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #72 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b84344206721ed2803d5da68585289d5880efe3f
commit b84344206721ed2803d5da68585289d5880efe3f
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #71 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0121a4baaca09049d130d830aa9179e3cb9c9e88
commit 0121a4baaca09049d130d830aa9179e3cb9c9e88
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #70 from Dr. Uwe Meyer-Gruhl ---
I am only speaking for me, but from a "downstream user" perspective and I do
not want to sound disrespectful.
I acknowledge and appreciate the hard work that has been put into FreeBSD.
However,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #69 from Franco Fichtner ---
(In reply to Dag-Erling Smørgrav from comment #68)
Thank you for participating. You may want to read comment 57 first.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Dag-Erling Smørgrav changed:
What|Removed |Added
CC||d...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #67 from Franco Fichtner ---
There are some open release engineering questions in this thread, lack of
professionalism discarding a problem that was later fixed without comment
aside. Doing the least bit of rectifying the previo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #66 from doktornotor ---
(In reply to Gordon Tetlow from comment #65)
I'm afraid the point was sort of missed here. What I meant by "more
communication" is that whoever committed the buggy code should not maintain
radio silenc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #65 from Gordon Tetlow ---
In reply to doktornotor from comment #64:
> Not sure about other people here suffering from the regressions, but I'd
> seriously appreciate some form of communication beyond automated
> commit-hook@ me
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #64 from doktornotor ---
Not sure about other people here suffering from the regressions, but I'd
seriously appreciate some form of communication beyond automated commit-hook@
messages.
On another note, perhaps start with comp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #63 from Dirk Meyer ---
Thanks.
As a possible workaround for affected systems
can be an additional rule like this:
pass in quick inet6 proto icmp6 no state
If you are not afraid of icmp echo.
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #62 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=5ab1e5f7e5585558a73b723f07528977a82cee82
commit 5ab1e5f7e5585558a73b723f07528977a82cee82
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #61 from Natalino Picone ---
(In reply to doktornotor from comment #60)
Sorry for the missing details. This is a very long thread, and it's unclear
whether an official FreeBSD patch is now in the base or not to fix the issues
c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #60 from doktornotor ---
(In reply to Natalino Picone from comment #59)
Do you mean the patch posted in comment #58? You can apply that patch to
whichever branch you wish, however it will not fix the regressions, as noted in
th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Natalino Picone changed:
What|Removed |Added
CC||natalino.picone@nozominetwo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #58 from Franco Fichtner ---
I found these inconsistencies in the ported patches from OpenBSD:
diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c
index ef488bad26d..c9180e877d5 100644
--- a/sys/netpfil/pf/pf.c
+++ b/sys/net
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #57 from Franco Fichtner ---
In closing I'd like to add a few things.
It was made known that a proper bug report and steps to reproduce should be
raised. I think that's only fair. This, however, requires the undesired
behaviou
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #56 from doktornotor ---
Created attachment 253088
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253088&action=edit
Packet loss / RTT times (Source: https://github.com/opnsense/src/issues/218)
Perhaps pics work bett
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #55 from doktornotor ---
(In reply to Kristof Provost from comment #54)
Yes, that's the same information what's been posted in Comment #31. That's also
something that should be covered by the testcases but clearly is not.
I am
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #54 from Kristof Provost ---
(In reply to Dr. Uwe Meyer-Gruhl from comment #52)
Oh hey, an actionable bit of information! That's nice.
I'll try that on Monday.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #53 from doktornotor ---
And since it already got to this point, @Kristof - perhaps reviewing Section 13
of the Committer's Guide [1] would benefit you, others contributors and - first
of all - FreeBSD. (Seems last updated in 20
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #52 from Dr. Uwe Meyer-Gruhl ---
If you do not understand and / or believe what is left broken, read the reports
of how ND fails even after applying the patches contained here.
If you want to construct a test setup to cover thi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #51 from doktornotor ---
(In reply to Kristof Provost from comment #49)
Sir, as I already hinted in Comment #11 - your port of code from 2009 is
*incomplete* and buggy. ND states behaviour is broken. Many people took their
time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #50 from Franco Fichtner ---
I don't know why this keeps happening, Kristof. If you don't think it's worth
investigating please don't shrug it off in the name of external entities / bug
reporters. If you don't want bug reports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #49 from Kristof Provost ---
(In reply to Gordon Tetlow from comment #48)
> kp, does the analysis in comment 46 indicate an issue that needs further
> review?
What issue? There's been a lot of conspiracy theorising, but no act
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Gordon Tetlow changed:
What|Removed |Added
Resolution|FIXED |---
Status|Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #47 from Franco Fichtner ---
Also why was this excluded during the port from OpenBSD? Same for
MLD_LISTENER_* BTW.
https://github.com/openbsd/src/blob/master/sys/net/pf.c#L2699-L2704
--
You are receiving this mail because:
Yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #46 from Franco Fichtner ---
Ok here we go:
https://cgit.freebsd.org/src/commit/?id=534ee17e61
This first SA commit adds state tracking to
ND_NEIGHBOR_SOLICIT/ND_NEIGHBOR_ADVERT that wasn't there before. From packet
captures y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #45 from Franco Fichtner ---
> we are not seeing this issue manifest itself in the stock FreeBSD kernel once
> the fixes are applied
I appreciate the whole of FreeBSD insiders sticking together on this.
Though I'd like to ver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Gordon Tetlow changed:
What|Removed |Added
CC||gor...@freebsd.org
--- Comment #44
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #43 from Franco Fichtner ---
> Again: is there any evidence that this problem still manifests on FreeBSD?
Is there any evidence it wouldn't given a single FreeBSD commit? I think what
you are implying is that someone else shoul
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #42 from Dr. Uwe Meyer-Gruhl ---
Sigh, Franco, would a plain vanilla FreeBSD kernel like FreeBSD
post-SA-24:05+corrections underneath OpnSense be feasible?
If the ND problems persisted with that kernel (and I am sure they do, b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #41 from Philip Paeps ---
Problems with how FreeBSD code behaves when merged into a downstream product
are beyond the scope of this bug tracker. As far as FreeBSD is concerned, an
issue is resolved when it no longer manifests o
riginal "security" "issue" has caused zero problems for
15+ years. Something's not responding to pings - yeah, there's a box with a
firewall in place blocking ping. If there was no computer with given address
connected, the evil attacker crafting the packets as per the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #39 from Franco Fichtner ---
The evidence is the original SA patch series which spans hundreds of lines of
code changes and a lack of actual test coverage. The lack of benefit of doubt
is strange in my opinion.
I can revert onl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #38 from Philip Paeps ---
What concrete evidence do you have that the neighbour discovery behaviour you
are observing on opnsense is related to this regression on FreeBSD? Counters
are not helpful here.
Please submit a test ca
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #37 from Franco Fichtner ---
I suspect it's a behavioural change in ICMPv6 state handling introduced WRT the
ND discard observed which is not overly practical in production,
downstream-related or not. I don't think closing this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #36 from Dr. Uwe Meyer-Gruhl ---
Just wanted to note that I see the delayed ND answers and rising counters as
well on OpnSense.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Kristof Provost changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Philip Paeps changed:
What|Removed |Added
Status|New |In Progress
--- Comment #34 from Ph
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #33 from Franco Fichtner ---
There is no significant change with the reverted changes:
igb0
Out6/Block: [ Packets: 11 Bytes: 896]
igb1
Out6/Block: [ Packets: 286
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #32 from Franco Fichtner ---
Another user notes via https://github.com/opnsense/core/issues/7804 that the
following counters seem to be rising while NDs are ignored:
# pfctl -vvsInterfaces | grep -e '^[a-z]' -e Out6/Block
LAN/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #31 from Franco Fichtner ---
According to multiple users the ICMP patch series causes stalls in neighbor
discovery and only a full revert brings back the desired behaviour.
A TCP dump showed that the Cisco is sending ICMP6 neig
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #30 from commit-h...@freebsd.org ---
A commit in branch releng/13.4 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=7d3a0370c8a3dadad0739ed88fc26536649119c5
commit 7d3a0370c8a3dadad0739ed88fc26536649119c5
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #29 from commit-h...@freebsd.org ---
A commit in branch releng/13.4 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=9c67287ccfb7257d140b46c8d8aed7276c94d5f1
commit 9c67287ccfb7257d140b46c8d8aed7276c94d5f1
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #28 from commit-h...@freebsd.org ---
A commit in branch releng/13.4 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=6a7bac2ae79667c2b31169a8d0e91410986336fa
commit 6a7bac2ae79667c2b31169a8d0e91410986336fa
Auth
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #27 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=7024e1066d5aba76dbbc85eb191357da7d32c619
commit 7024e1066d5aba76dbbc85eb191357da7d32c619
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #26 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0d8d4cc3ea47f1ee61d749b22b135eb73c7d33cd
commit 0d8d4cc3ea47f1ee61d749b22b135eb73c7d33cd
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #25 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=5f3f07397a7909e8f9449d1aa0b465159cbf0d60
commit 5f3f07397a7909e8f9449d1aa0b465159cbf0d60
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #24 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=27a1a56b0d2e6ffa6ab1de69ef84fe66b7fd41e0
commit 27a1a56b0d2e6ffa6ab1de69ef84fe66b7fd41e0
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #23 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3455a02b5aed6f24f425b6a4fad4256fe74b13ed
commit 3455a02b5aed6f24f425b6a4fad4256fe74b13ed
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #22 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=46c4fc50d3012ca3c8756df243589add36b70830
commit 46c4fc50d3012ca3c8756df243589add36b70830
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #21 from Franco Fichtner ---
Both extra patches combined look promising. There are some conflicting reports
on whether they fix all edge cases:
1. mtr may still have issues.
2. IPv6 ICMP ping packets appear to be dropped somet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #20 from doktornotor ---
(In reply to commit-hook from comment #19)
Nice, looks good now with both IPv4 and IPv6. Also tried logging of the packets
with pf, seems to work as well.
--
You are receiving this mail because:
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #19 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=89f6723288b0d27d3f14f93e6e83f672fa2b8aca
commit 89f6723288b0d27d3f14f93e6e83f672fa2b8aca
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Philip Paeps changed:
What|Removed |Added
CC||phi...@freebsd.org
--- Comment #18
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #17 from doktornotor ---
(In reply to Philip Paeps from comment #16)
I think it'd be goog to wait for feedback from other users who confirmed the
regression here, since - for me at least - things are still broken with ICMPv6
ev
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #16 from Philip Paeps ---
We will want to issue a revised SA-24:05.pf advisory with a corrected patch.
The revised advisory should also include a patch to fix systems broken by the
previous patch. See
https://www.freebsd.org/s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #15 from doktornotor ---
(In reply to commit-hook from comment #14)
Unfortunately, that fixes IPv4 but is even more broken with ICMPv6, now even
the first hop (the FreeBSD router) is not shown from machines behind the
router.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #14 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=2da98eef1f352c496ffd458b4c68ddee972bb903
commit 2da98eef1f352c496ffd458b4c68ddee972bb903
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #13 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=34063cb714602972b6d985ad747fc8f66a8daae1
commit 34063cb714602972b6d985ad747fc8f66a8daae1
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #12 from Franco Fichtner ---
Going fishing... How about this one? :)
https://github.com/openbsd/src/commit/ef4bccd7509e
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #11 from doktornotor ---
Looks like some code has been missed when forward-porting a 2009 (!!!) OpenBSD
patch. Something between the patch date and OpenBSD 4.8 release.
https://marc.info/?l=openbsd-misc&m=128218328308200&w=2
H
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
--- Comment #10 from Franco Fichtner ---
We did a quick bisect and it's likely caused by a change within
https://cgit.freebsd.org/src/commit/?id=534ee17e61ee094ec
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Oleksandr Kryvulia changed:
What|Removed |Added
CC||shur...@shurik.kiev.ua
--- Co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Artem Viklenko changed:
What|Removed |Added
CC||ar...@viklenko.net
--- Comment #8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
Keywords
I have difficulty filtering one member of a bridge using pf firewall
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 0
Two segments are bridged, segment 'home' and segment ‘safe'. The idea for
segment ’safe’ is to only allow access to the outside world with certain
tstat -dI " to show errors or drops or "sysctl dev.cc
> dev.cxl | grep pause" to show some activity. Can you please double check?
>
After a prior event on a firewall cluster, I started pushing pause frames
and netstat drops/errors to elasticsearch. They remained
check?
Regards,
Navdeep
>
> Usually, the quickest fix is to failover to the backup firewall. At that
> time, the backup firewall behaves normally and interrupt load drops on the
> afflicted firewall device.
>
> I'm stumped. Networking says its these systems. I bel
On 1/15/2020 9:55 AM, John Jasen wrote:
> Executive summary:
>
> Periodically, load will spike on network interrupts on one of our
> firewalls. Latency will quickly climb to the point that things are
> unresponsive, sessions will timeout, and bandwidth will plummet.
A couple of wild stabs... Are t
else like that from the system.
Usually, the quickest fix is to failover to the backup firewall. At that
time, the backup firewall behaves normally and interrupt load drops on the
afflicted firewall device.
I'm stumped. Networking says its these systems. I believe its something on
other side.
1 - 100 of 366 matches
Mail list logo
