if_gre, ip_gre and the like (pseudo-interfaces)

[Jerry Toung]

BMS,
please be patient. I guess I am still a little bit confuse as to how a
packet goes from a real NIC (i.e xl0) to the gre pseudo-device.
in if_gre.c, you define a new protocol switch in the inetdomain and
gre_input as the input processing function.
My understanding is that NIC receives a data, device driver unwraps it and
places it in &ipintrq. Then (*inetsw[ip_protox[ip->ip_p]].pr_input) in 
ip_input.c points to gre_input and that's how we land in the gre module.

gre_output on the other hand prepends or insert headers and make a call
to ip_output which I think will transmit the packet to the physical interface 
(i.e xl0).

With all respect, I don't see any call to IF_HANDOFF in the gre code. only in 
if_gif that you also wrote.
which fit the explaination you gave previously. As for /dev/gre, we can ignore 
that statement.
Thanks lot,
Jerry.



On Tuesday 02 September 2003 12:12 pm, Bruce M Simpson wrote:
> On Sun, Aug 31, 2003 at 11:03:40PM -0700, Jerry Toung wrote:
> > My understanding is that gre_input is called by IP everytime it receives
> > a packet with a gre headers which after some processing performs
> > IF_ENQUEUE(ifq,m) to put it back on the IPqueue so that higher protocol
> > such TCP can do their thing. :-)
>
> Not quite correct. This is what my legacy GRE code does. The NetBSD-derived
> if_gre in the tree passes the mbuf to netisr_dispatch(), which in turn
> calls if_handoff(), which does something similar.
>
> >  I don't see how /dev/gre is ever used on receiving or sending, through
> > if_clone_attach??. Somebody educate me on my missing link.
>
> I don't see /dev/gre on my system.
>
> If you're referring to the line 'device gre' in the kernel configuration,
> that is there purely to ensure that the gre driver is statically linked
> into the kernel.
>
> BMS

--