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 -- _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
