On Sun, Nov 04, 2007 at 10:21:58AM -0500, Ken Raeburn wrote:
> On Nov 4, 2007, at 09:19, I wrote:
> >called from fr_check, fil.c:2730:
> >
> >		} else if ((fdp->fd_ifp != NULL) &&
> >			   (fdp->fd_ifp != (struct ifnet *)-1)) {
> >			/* this is for to rules: */
> >			(void) fr_fastroute(fin->fin_m, mp, fin, fdp);
> >			m = *mp = NULL;
> >		}
> >
> >So, if I've got it right, fr_fastroute gets a handle on the packet with its 
> >length in host order, sets it to network order for the call to the output 
> >routine, and then sets it back to host order, just in case the caller of 
> >fr_fastroute wants to do something else with the packet (e.g., in the dup-to 
> >case, I assume).  Then the gif soft interrupt handler is invoked, and outputs 
> >on the real network interface an encapsulated packet with its length in the 
> >host's byte order.
> >
> >Is the packet eventually supposed to get its length restored to network order 
> >once again before the soft interrupt for gif can be serviced?  Or should I 
> >look at making a copy of the packet in gif_output, or maybe patch up the 
> >length in gif_intr or in_gif_output?  (I haven't looked to see if IPv6 tunnels 
> >have a similar problem, but I'm just using the routing table to get IPv6 
> >traffic to the right output queue.)
> 
> Okay, I found the bit I overlooked before where the network byte order gets 
> restored, in fr_check_wrapper.  However, it only does so if *mp is non-null, 
> and the above code is setting it to null.  Perhaps when *mp is set to null 
> after a fr_fastroute call, the ip_len field (and ip_off, apparently) should be 
> restored to network order in fr_check?

IIUC, fr_fastroute sets *mp to NULL because fr_fastroute effectively
frees the mbuf and nothing should touch it after.

Pavel