change divert socket to use a sockaddr_div struct
Needs ReviewPublic
Actions

Authored by nick.hibma_gmail.com on Mar 5 2020, 4:28 PM.

Details

Reviewers

Group Reviewers

manpages
network

Summary

We would like to use FIBs for routing, but currently cannot because the FIB is lost when the packet goes through a divert socket for processing. I've attached a patch that should fix this situation, and while there fix the limit of 7 characters for the interface name which some people got bitten by. This fix was suggested some time ago by Warner Losh.

I've changed the sockaddr_in to a sockaddr_di struct to pass the FIB number and the complete interface, and other info in and out. But this seems to lead to memory corruption. Perhaps someone who knows the API can tell me where I should look for memory corruption issues, because this patch causes random crashes. I assume it's because of overwriting random memory.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

nick.hibma_gmail.com created this revision.Mar 5 2020, 4:28 PM

Herald added a reviewer: manpages. · View Herald TranscriptMar 5 2020, 4:28 PM

Herald added subscribers: Contributor Reviews (src), melifaro, imp. · View Herald Transcript

melifaro added reviewers: network, ae.Mar 5 2020, 7:58 PM

Thank you for submitting the patch! This is certainly a desired functionality, please see some comments on the implementation.

share/man/man4/divert.4
78	Given we’re changing the format: could you change interface to be ifindex? make rule number u32? think about IPv6?
sys/netinet/ip_divert.c
225	How do we know if the caller supports old or new format? Abi has to be preserved. Probably some setsockopt() or similar is needed..
354	We need to think about compatibility. Can probably distinguish between old/new by the sin_size.
sys/netinet/ip_divert.h
68	umsigned int, to be consistent w/ other places

Thanks for reviewing.

Currently my main concern is the fact that the kernel panics due to probably memory spamming somewhere. Any pointers as to how I could debug this?

Nick Hibma
nick@van-laarhoven.org

Open Source: We stand on the shoulders of giants.

In D23972#527135, @nick.hibma_gmail.com wrote:

Thanks for reviewing.

Currently my main concern is the fact that the kernel panics due to probably memory spamming somewhere. Any pointers as to how I could debug this?

Will take a look tomorrow. Could you share a backtrace?