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?

Ken