NetBSD Problem Report #33901

From  Mon Jul  3 11:20:36 2006
Return-Path: <>
Received: from ( [])
	by (Postfix) with ESMTP id 5F3F163B8C5
	for <>; Mon,  3 Jul 2006 11:20:36 +0000 (UTC)
Message-Id: <>
Date: Mon, 3 Jul 2006 11:53:22 +0200 (MEST)
From: Lars-Johan Liman <>
Subject: ipf "express forward" to GRE interface gives byte order problem.
X-Send-Pr-Version: 3.95

>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
Autonomica AB
# Lars-Johan Liman, M.Sc.	! E-mail:
# Senior Systems Specialist     ! HTTP  : //
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72
System: NetBSD 3.99.21 NetBSD 3.99.21 (GENERIC) #0: Fri Jun  9 01:13:22 UTC 2006 i386
Architecture: i386
Machine: i386

	General design:

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

	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

	pass in on fxp0 to gre0 from 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.


	See above.


	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.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.