https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
Eugene Grosbein changed:
What|Removed |Added
Assignee|b...@freebsd.org|eu...@freebsd.org
--
You are re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #12 from Eugene Grosbein ---
Created attachment 252849
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=252849&action=edit
proposed fix
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #11 from Eugene Grosbein ---
I've managed to reproduce the problem and came up with simplier and a bit more
efficient patch.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #10 from Eugene Grosbein ---
(In reply to Peter Much from comment #9)
I'll try. I cannot reliably reproduce the problem in my setup, so it will take
time.
--
You are receiving this mail because:
You are the assignee for the b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
Peter Much changed:
What|Removed |Added
Severity|Affects Only Me |Affects Some People
--- Comment #9 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #8 from Peter Much ---
Created attachment 252840
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=252840&action=edit
workaround/fix
In libalias/alias_db.c:_FindLinkIn() is a search for a temporary
(fully specified) flo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #7 from Eugene Grosbein ---
(In reply to Peter Much from comment #6)
> the logic when and how this happens is unintellegible
In case of ipfw nat:
1) When "ipfw nat" rule processes packets in-kernel, a packet is passed to
ipfw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
Peter Much changed:
What|Removed |Added
CC||don...@freebsd.org
--- Comment #6 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #5 from Peter Much ---
Trying with /sbin/natd gives similar errors.
Also, trying ng_nat gives similar errors.
The latter allows to handle inflow and outflow separately, so with UDP I can
use entirely different nat instances fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #4 from Peter Much ---
Reissuing the "ipfw nat config ..." does not help in my case. Switching from
"redirect_port udp 192.168.xx.xx:5007 5006" to
"redirect_port udp 192.168.xx.xx:5007 yy.yy.yy.yy:5006" has occasionally
helped
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #2 from Peter Much ---
I managed to analyze this a bit further:
With an UDP service (e.g. VPN) portforwarded behind NAT there is no notion of a
connection, and apparently it can happen that libalias creates TWO distinct
records
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #1 from Peter Much ---
Created attachment 248673
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248673&action=edit
DTRACE cmdline
for general amusement and bookkeping - I mean, to observe what libalias adds
and remo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
Bug ID: 269770
Summary: libalias udp redirect_port temporary translation
failure
Product: Base System
Version: 13.1-STABLE
Hardware: amd64
OS: Any
14 matches
Mail list logo
