Page MenuHomeFreeBSD

setkey(8): NAT-T manual configuration support
ClosedPublic

Authored by kib on May 27 2023, 6:10 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 11, 10:15 PM
Unknown Object (File)
Mon, Dec 9, 3:47 AM
Unknown Object (File)
Oct 26 2024, 4:37 AM
Unknown Object (File)
Oct 17 2024, 10:21 AM
Unknown Object (File)
Oct 16 2024, 7:05 PM
Unknown Object (File)
Oct 16 2024, 7:05 PM
Unknown Object (File)
Oct 16 2024, 7:05 PM
Unknown Object (File)
Oct 16 2024, 7:05 PM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.May 27 2023, 6:10 AM

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

sbin/setkey/parse.y
813

Please also hide IPv4. Way more important to be able to phase it out than hiding IPv6 these days ;-) I know the code doesn't always do it but when we move it we could clean that up.

1167

Those probably should be resolved or removed?

sbin/setkey/setkey.8
32

.Dd update before commit

kib marked 3 inline comments as done.May 27 2023, 9:45 PM
In D40300#917678, @bz wrote:

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

This is needed to properly test IPSEC+NAT-T hardware offload. (I do not think that mentioning this in commit message is too useful).

In D40300#917683, @kib wrote:
In D40300#917678, @bz wrote:

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

This is needed to properly test IPSEC+NAT-T hardware offload. (I do not think that mentioning this in commit message is too useful).

I think the reason WHY a change is done is super useful in a commit message. And thanks for explaining as "testing" was literally the only thing I could think off why this change could be needed. I'll try and see if I can do a more thorough review if noone else beats me to it.

In general I am fine adding the functionality.

LGTM. Do you plan to implement NAT_T_FRAG in kernel somehow?

This revision is now accepted and ready to land.May 29 2023, 7:19 AM
In D40300#917875, @ae wrote:

LGTM. Do you plan to implement NAT_T_FRAG in kernel somehow?

Somehow, might be. So far it was a possibility that we need this for our offload work, so I implemented it in advance.