https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228854
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
On 12.06.2018 17:02, Patrick Lamaiziere wrote:
> # setkey -f /etc/ipsec.conf
> # setkey -D
> 129.20.128.149 129.20.128.78
> tcp mode=any spi=106079004(0x0652a31c) reqid=0(0x)
> A: tcp-md5 73656372 6574
> seq=0x replay=0 flags=0x0040 state=mature
> creat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228854
--- Comment #9 from Marek Zarychta ---
(In reply to Andrey V. Elsukov from comment #8)
No additional information is provided, also when kldload is run in verbose
mode.
--
You are receiving this mail because:
You are the assignee for the b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228982
Andrey V. Elsukov changed:
What|Removed |Added
CC||mm...@freebsd.org
As
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228854
--- Comment #10 from Marek Zarychta ---
(In reply to Andrey V. Elsukov from comment #8)
I attempted to load ipsec module through ktrace.
Maybe output from kdump will shed some light on it.
4988 ktrace RET ktrace 0
4988 ktrace CA
When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC
tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte
return packet is silently dropped by the in-kernel NAT, even though it
"matches" the outbound packet from less than 100 ms prior.
All other operations of
On Wed, Jun 13, 2018 at 10:16 AM, Jeff Kletsky wrote:
When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC tunnel
> to the T-Mobile provisioning servers, the reassembled, 4640-byte return
> packet is silently dropped by the in-kernel NAT, even though it "matches"
> the outbound pac
On 6/13/18 10:22 AM, Michael Sierchio wrote:
On Wed, Jun 13, 2018 at 10:16 AM, Jeff Kletsky wrote:
When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC tunnel
to the T-Mobile provisioning servers, the reassembled, 4640-byte return
packet is silently dropped by the in-kernel NAT
I see you have a case of Netgraph. Perhaps Julian will chime in.
On Wed, Jun 13, 2018 at 10:32 AM, Jeff Kletsky wrote:
> On 6/13/18 10:22 AM, Michael Sierchio wrote:
>
> On Wed, Jun 13, 2018 at 10:16 AM, Jeff Kletsky wrote:
>>
>> When a T-Mobile "femto-cell" is trying to establish its IPv4, IPS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228982
Matthew Macy changed:
What|Removed |Added
CC||mm...@nextbsd.org
--- Comment #1 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228982
--- Comment #2 from Andrey V. Elsukov ---
(In reply to Matthew Macy from comment #1)
> This looks a lot more like it's tied to my deferred deletion of multicast
> addresses. Could you test with a kernel prior to my epoch changes? Also,
> co
On 13.06.2018 20:16, Jeff Kletsky wrote:
> When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC
> tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte
> return packet is silently dropped by the in-kernel NAT, even though it
> "matches" the outbound packet from less
On 6/13/18 12:01 PM, Andrey V. Elsukov wrote:
On 13.06.2018 20:16, Jeff Kletsky wrote:
When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC
tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte
return packet is silently dropped by the in-kernel NAT, even though
On 13.06.2018 23:04, Jeff Kletsky wrote:
>> The kernel version of libalias uses m_megapullup() function to make
>> single contiguous buffer. m_megapullup() uses m_get2() function to
>> allocate mbuf of appropriate size. If size of packet greater than 4k it
>> will fail. So, if you use MTU greater t
On 6/13/18 1:28 PM, Andrey V. Elsukov wrote:
On 13.06.2018 23:04, Jeff Kletsky wrote:
The kernel version of libalias uses m_megapullup() function to make
single contiguous buffer. m_megapullup() uses m_get2() function to
allocate mbuf of appropriate size. If size of packet greater than 4k it
w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228852
Eric Joyner changed:
What|Removed |Added
CC||e...@freebsd.org
--- Comment #4 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228412
v...@mpeks.tomsk.su changed:
What|Removed |Added
Resolution|--- |Overcome By Events
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228412
--- Comment #18 from v...@mpeks.tomsk.su ---
I think nobody should waste time fixing the 10 branch, and the workaround is to
upgrade to the 11.1-RELEASE. Therefore I suggest we close this bug.
--
You are receiving this mail because:
You ar
18 matches
Mail list logo
