On 2021-12-17 22:12 +01, Denis Fondras <open...@ledeuns.net> wrote: > Here is an attempt to fix ping(8) and traceroute(8) source selection. > > Currently these tools do not obey route sourceaddr set by the operator. This > leads to frustration at best and erroneous diagnosis at worse on multi-homed > systems.
I did not closely follow route(8)'s sourceaddr feature. Is this only an issue with IPv4 or would ping6 / traceroute6 need a similar fix (which is going to be difficult). > > The "real" fix would be to rework source selection in the kernel stack but > this > is a huge work which not happen overnight nor in the coming days. > > In the mean time, I propose the following diff. > > I removed -R (route recording) in ping(8) because it is not compatible with > sending a full IP header to the rip_output(). It should not impact anyone as > RR > is most of the time ignored by routers. I was toying with removing -R when I was unifying ping and ping6, but then I found a system that did allow it. IIRC one needs to disable pf on OpenBSD, so the utility is indeed very limited. Maybe it's time for it to go. > > Denis > > Index: sbin/ping/ping.c > =================================================================== > RCS file: /cvs/src/sbin/ping/ping.c,v > retrieving revision 1.245 > diff -u -p -r1.245 ping.c > --- sbin/ping/ping.c 12 Jul 2021 15:09:19 -0000 1.245 > +++ sbin/ping/ping.c 17 Dec 2021 20:27:31 -0000 > @@ -143,16 +143,14 @@ int options; > #define F_HOSTNAME 0x0004 > #define F_PINGFILLED 0x0008 > #define F_QUIET 0x0010 > -#define F_RROUTE 0x0020 > -#define F_SO_DEBUG 0x0040 > -#define F_SHOWCHAR 0x0080 > -#define F_VERBOSE 0x0100 > +#define F_SO_DEBUG 0x0020 > +#define F_SHOWCHAR 0x0040 > +#define F_VERBOSE 0x0080 no need for this churn > /* 0x0200 */ you could just add a comment like this ^ > -#define F_HDRINCL 0x0400 > -#define F_TTL 0x0800 > -#define F_TOS 0x1000 > -#define F_AUD_RECV 0x2000 > -#define F_AUD_MISS 0x4000 > +#define F_TTL 0x0100 > +#define F_TOS 0x0200 > +#define F_AUD_RECV 0x0400 > +#define F_AUD_MISS 0x0800 I'm with deraadt@ that the kernel implementation should be finished. -- I'm not entirely sure you are real.
