>Number:         33901
>Category:       kern
>Synopsis:       ipf "express forward" to GRE interface gives byte order problem.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 03 11:25:00 +0000 2006
>Originator:     Lars-Johan Liman
>Release:        NetBSD 3.99.21
>Organization:
Autonomica AB
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.	! E-mail: liman@autonomica.se
# Senior Systems Specialist     ! HTTP  : //www.autonomica.se/
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72
#----------------------------------------------------------------------
>Environment:
System: NetBSD server.liman.net 3.99.21 NetBSD 3.99.21 (GENERIC) #0: Fri Jun  9 01:13:22 UTC 2006  builds@b3.netbsd.org:/home/builds/ab/HEAD/i386/200606080000Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:

	General design:

	i386 box. Inner Ethernet interface (fxp0), outer Ether
	interface (tlp0), GRE tunnel (gre0) over outer interface
	(tlp0).

	Working setup:

	Add normal routing entry that forwards packets for specific
	destination into GRE tunnel. If you just use normal packet
	forwarding everything works fine.

	Non-working setup:

	Add ipf.conf entry that "grabs" the packets from the incoming
	interface and "throws" them onto the GRE tunnel without kernel
	processing.

	pass in on fxp0 to gre0 from 192.168.1.0/24 to any

	(The important part is the "to gre0" above.)

	Now the _INNER_ packets in the outgoing GRE tunnel have the
	"total length" and "header cheksum" fields garbled, obviously
	byte swapped.

>How-To-Repeat:

	See above.

>Fix:

	Have no specific patch, but a wild guess (and it is exactly
	that) that the packet is plugged into the GRE queue in the
	wrong place, and that the GRE tunnel interface code does
	"htons()" on some fields of the packet, because usually the
	packet is stored by the kernel in host byte order. In the non-
	working case above, though, the packet was never
	converted to host byte order, because it was never processed
	by the kernel due to the "express forwarding" by ipf, so the
	GRE code does "convert to network byte order" on something
	that already _is_ in the right byte order.

	If I'm right, this problem should not be visible on BIG_ENDIAN
	machines where netork and host byte orders are the same.