https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242677
Kubilay Kocak changed:
What|Removed |Added
Keywords||regression
Summary|mult
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207261
Kubilay Kocak changed:
What|Removed |Added
Flags||mfc-stable12?,
|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242784
Kubilay Kocak changed:
What|Removed |Added
Summary|arp segfault|arp: segfault on service
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242712
Kubilay Kocak changed:
What|Removed |Added
Summary|Networking device detach|Networking device detach
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746
Kubilay Kocak changed:
What|Removed |Added
Keywords|needs-patch, needs-qa |
URL|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746
--- Comment #5 from ghuckri...@blackberry.com ---
A HEAD dev environment was not available, so the patch was tested on a 12.1
based build (which was where this issue was discovered).
The reported leak was gone with the provided patch.
Also
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746
--- Comment #4 from ghuckri...@blackberry.com ---
Sure I'll try it.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://li
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746
--- Comment #3 from Mark Johnston ---
https://reviews.freebsd.org/D22912
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
http
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746
Mark Johnston changed:
What|Removed |Added
Status|Open|In Progress
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746
--- Comment #2 from Mark Johnston ---
Created attachment 210181
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210181&action=edit
patch
This patch fixes the problem in my own testing - would you be willing to try
it?
--
You ar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
Assign
Hi, All!
Sorry if this list is wrong place for questions about IPFilter (didn't found
more appropriate freebsd mailling list and one mentioned in some docs seems to
be dead).
But maybe someone can answer it or point in right direction.
I need to rewrite source and destination IPs on packet sen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242712
Mark Johnston changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242712
--- Comment #4 from commit-h...@freebsd.org ---
A commit references this bug:
Author: markj
Date: Mon Dec 23 16:34:40 UTC 2019
New revision: 356037
URL: https://svnweb.freebsd.org/changeset/base/356037
Log:
MFC r355938:
Fix a memory le
On 23.12.2019 15:12, Eugene Grosbein wrote:
> 23.12.2019 19:00, Andrey V. Elsukov wrote:
>
>> I think the silence from ping is due to IPsec works asynchronously.
>> I.e. when application sends data to the stack, it receives good feedback
>> and thinks that data was send successful then it waits fo
23.12.2019 19:00, Andrey V. Elsukov wrote:
> I think the silence from ping is due to IPsec works asynchronously.
> I.e. when application sends data to the stack, it receives good feedback
> and thinks that data was send successful then it waits for reply.
> But IPsec consumes the data and then enc
Hi all,
> Am 23.12.2019 um 12:28 schrieb Andrey V. Elsukov :
> "If required, IP fragmentation occurs after IPsec processing within an
> IPsec implementation. Thus, transport mode AH or ESP is applied only
> to whole IP datagrams (not to IP fragments)."
>
> This is exactly how it works now. IPsec
On 20.12.2019 18:23, Victor Sudakov wrote:
> Dear Colleagues,
>
> I've set up IPSec in transport mode between two regular FreeBSD hosts,
> for testing. Now TCP sessions between those hosts don't work normally
> any more. For example, scp is stalled almost immediately after starting
> a file transf
On 23.12.2019 14:08, Eugene Grosbein wrote:
>>> Sample patch creates another sysctl but we should do it unconditionally,
>>> don't we?
>>
>> As I said I didn't find that other OSes do this. Linux has enabled by
>> PMTUD by default, strongswan doesn't set SADB_SAFLAGS_NOPMTUDISC flag,
>> OpenBSD ha
23.12.2019 18:00, Andrey V. Elsukov wrote:
> On 23.12.2019 13:55, Eugene Grosbein wrote:
>>> I think the real problem is that PMTUD doesn't work correctly with
>>> IPsec. Linux has special sysctl variabl ip_no_pmtu_disc and flag
>>> SADB_SAFLAGS_NOPMTUDISC for SA that can disable PMTUD for IPv4 an
On 23.12.2019 13:55, Eugene Grosbein wrote:
>> I think the real problem is that PMTUD doesn't work correctly with
>> IPsec. Linux has special sysctl variabl ip_no_pmtu_disc and flag
>> SADB_SAFLAGS_NOPMTUDISC for SA that can disable PMTUD for IPv4 and IP_DF
>> flag will not be set. We can add some
23.12.2019 17:45, Andrey V. Elsukov wrote:
> On 23.12.2019 13:06, Victor Sudakov wrote:
>>> ESP xform for transport mode just replaces protocol in IP header and
>>> adds some info to the end of a packet.
>>
>> It is rather easy to verify your theory. If you are right, then
>> disabling net.inet.tc
On 23.12.2019 13:06, Victor Sudakov wrote:
>> ESP xform for transport mode just replaces protocol in IP header and
>> adds some info to the end of a packet.
>
> It is rather easy to verify your theory. If you are right, then
> disabling net.inet.tcp.path_mtu_discovery globally should remove the DF
Andrey V. Elsukov wrote:
> On 20.12.2019 19:22, Victor Sudakov wrote:
> >> What's the root of the problem? ESP packets cannot get fragmented or
> >> what?
> >
> > Wireshark has shown that the "Don't Fragment" flag is set on all ESP
> > (protocol 50) packets. Who does this, why, and how can I swit
23.12.2019 16:44, Andrey V. Elsukov wrote:
> On 23.12.2019 12:39, Andrey V. Elsukov wrote:
>> On 20.12.2019 19:22, Victor Sudakov wrote:
What's the root of the problem? ESP packets cannot get fragmented or
what?
>>>
>>> Wireshark has shown that the "Don't Fragment" flag is set on all ES
On 23.12.2019 12:39, Andrey V. Elsukov wrote:
> On 20.12.2019 19:22, Victor Sudakov wrote:
>>> What's the root of the problem? ESP packets cannot get fragmented or
>>> what?
>>
>> Wireshark has shown that the "Don't Fragment" flag is set on all ESP
>> (protocol 50) packets. Who does this, why, and
On 20.12.2019 19:22, Victor Sudakov wrote:
>> What's the root of the problem? ESP packets cannot get fragmented or
>> what?
>
> Wireshark has shown that the "Don't Fragment" flag is set on all ESP
> (protocol 50) packets. Who does this, why, and how can I switch it off
> globally?
Hi,
I think t
27 matches
Mail list logo
