Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Oct 2012 17:49:46 +0400
From:      "Alexander V. Chernikov" <melifaro@FreeBSD.org>
To:        Gleb Smirnoff <glebius@FreeBSD.org>
Cc:        net@FreeBSD.org
Subject:   Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9)
Message-ID:  <506EE57A.7040005@FreeBSD.org>
In-Reply-To: <20121005114716.GP34622@FreeBSD.org>
References:  <20121005114716.GP34622@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 05.10.2012 15:47, Gleb Smirnoff wrote:
>    Hello,
>
>    once the pfil(9) API was introduced in FreeBSD, our main packet filter,
> the ipfw(4) worked in host byte order, that's why the pfil(9) API was
> violated: the AF_INET hooks were entered with packet in host byte order.
>
>    Moreover, when we put packets into the NETISR_IP queue, we put them
> in different byte order: those that have M_FASTFWD_OURS flag are in
> host byte order, while all others are in net.

divert and ng_ipfw are another places where we play these games, too.

>
>    Attached patch does the following:
>
>    - all packets in NETISR_IP queue are in net byte order
>    - ip_input() is entered in net byte order and converts packet
>      to host byte order right _after_ processing pfil(9) hooks
>    - ip_output() is entered in host byte order and converts packet
>      to net byte order right _before_ processing pfil(9) hooks
>    - ip_fragment() accepts and emits packet in net byte order
>    - ip_forward(), ip_mloopback() use host byte order (untouched actually)
>    - ip_fastforward() no longer modifies packet at all (except ip_ttl)
>    - swapping of byte order there and back removed from the following modules:
>      pf(4), ipfw(4), enc(4), if_bridge(4)
>    - swapping of byte order added to ipfilter(4), based on __FreeBSD_version
>    - __FreeBSD_version bumped
>    - manual page updated

That's great!
Unified approach for host/network fields in entire kernel will help 
greatly in making/debugging complex (netgraph, pfil or divert) paths.

Additionally, this is a good step to make mbuf entirely r/o (which can 
help in some cases like transparent firewalling, for example).

>
>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>



-- 
WBR, Alexander




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?506EE57A.7040005>