Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Oct 2002 17:18:09 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Bill Fenner <fenner@research.att.com>
Cc:        arch@freebsd.org
Subject:   Re: Renumbering IPPROTO_DIVERT
Message-ID:  <Pine.BSF.4.21.0210251716330.7147-100000@InterJet.elischer.org>
In-Reply-To: <200210252327.g9PNRtUw001126@stash.attlabs.att.com>

next in thread | previous in thread | raw e-mail | index | archive | help
hmmm seems fair..

I think though that there should be a "compat" shim that
does the right thing but is VERY NOISY.


On Fri, 25 Oct 2002, Bill Fenner wrote:

> I'd like to move IPPROTO_DIVERT out of the legitimate space of IP protocol
> numbers.  Here's the patch:
> 
> Index: in.h
> ===================================================================
> RCS file: /home/ncvs/src/sys/netinet/in.h,v
> retrieving revision 1.72
> diff -u -r1.72 in.h
> --- in.h	21 Oct 2002 20:40:02 -0000	1.72
> +++ in.h	25 Oct 2002 21:13:20 -0000
> @@ -236,12 +236,12 @@
>  #define	IPPROTO_PIM		103		/* Protocol Independent Mcast */
>  #define	IPPROTO_PGM		113		/* PGM */
>  /* 255: Reserved */
> -/* BSD Private, local use, namespace incursion */
> -#define	IPPROTO_DIVERT		254		/* divert pseudo-protocol */
>  #define	IPPROTO_MAX		256
>  
>  /* last return value of *_input(), meaning "all job for this pkt is done".  */
>  #define	IPPROTO_DONE		257
> +
> +#define	IPPROTO_DIVERT		258		/* divert pseudo-protocol */
>  
>  /*
>   * Local port number conventions:
> 
> 
> Yup, it Just Works.  Even better, with a patch to raw_ip.c, divert-using
> applications can now get an error from their socket() call when DIVERT
> isn't compiled in, as opposed to the current behavior where socket()
> would succeed but provide the normal raw IP semantics.
> 
> Now, the backwards compatability question: applications using the
> old DIVERT interface will now start getting real raw IP sockets
> with protocol 254.  This will generally cause silent failures, or
> possibly unexpected behavior (just like if DIVERT wasn't compiled
> into the kernel).  Should there be e.g. a kernel printf when an
> application uses the old divert number, warning that an application
> is using the old divert interface and needs to be recompiled?  Or
> is it OK to fail silently, as there are few DIVERT consumers and
> it's the same failure mode as if DIVERT isn't present in the kernel?
> 
>   Bill
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0210251716330.7147-100000>