[openbeosnetteam] Re: Network stack question

Ivo Vachkov <ivo@xxxxxxxxxxx> wrote:
> > I don't think that this is a good solution; you're mixing protocol 
> > depending things into the IP level. Instead, I would prefer if 
> > there 
> > would be a function in the protocol module that you can call for 
> > handling errors - and also one that will be called in case there 
> > were 
> > any errors.
> You'd prefer to do this at protocol level, in an error handling 
> function, right ? Or you have something else in mind ?

Sorry for the delay, but yes, that's what I have in mind.

> I think it is possible to implement what I propose at protocol level, 
> however, there is one problem - since ICMP messages often require 
> full 
> ip header + data any net_protocol_module_info->receive_data() has to 
> be 
> rewritten to take full packet and strip the header for itself, so if 
> an 
> error occur it can pass full ip header to the error handling 
> function.
> 
> A dirty hack would be to replace current receive_data() with a 
> wrapper 
> that strips off the ip header, calls actual receive_data() and takes 
> care of any errors that the actual receive_data() can possibly 
> return.

IMO there are two ways to do that:
1) the dirty version: include ICMPv4 handling into the IPv4 module
2) the clean version: have per protocol options to strip the header or 
not

I guess I would prefer 2) :-)

Looking at the BONE headers, there are the following two functions in 
what would be net_protocol_module_info in our stack (and I copied them 
into our's, too):

        /*
         * interface for error codes (ICMP, etc) to be passed back to 
protocols
         * from the network layer
         */
        status_t (*error)(int32 error_code, bone_data_t *error_data);

        /*
         * interface for error replies (ICMP, etc) to be sent from 
protocols
         * to other sites.  Error codes can be passed, or a data ptr and 
length
         * may be passed.  If error_data is non-0 error_code will be 
assumed to
         * be a length, otherwise a code.
         */
        status_t (*error_reply)(struct bone_proto_node *you, bone_data_t *
caused_error, uint32 error_code, void *error_data);

I'd propose that the ICMPv4 module will call error() on the domain 
protocol (which we could rename to receive_error(), as it's pretty 
similar to what receive_data() does) if it doesn't handle the packet 
itself (ie. like echo).
Then, IPv4 will either handle the error itself, or pass it on to the 
protocols, just like it would do in receive_data() - but of course it 
will also call the protocol's receive_error() method.

On the sending side of things, ICMP should register itself as the error 
handling protocol for the domain (via new stack methods to do that). I 
am not yet sure how to go from there - probably, there has to be a 
stack function send_error() that gets the protocol module as well as 
the data as error_reply() above, and will then call the error handler 
(ie. ICMPv4) to build a reply buffer then is then pushed down the stack 
using error_reply() - which I would then rename to send_error() as 
well. It will probably also need to know where to send the error to - 
either from the error-causing buffer, or from some route that the 
stack's send_error() would then also need to get.

> About the PMTU - it's kinda challenge to implement that ... I have to 
> search for references in other OSs before I can comment.

It's nothing urgent, although the above mentioned architecture should 
not hinder its implementation.

> Sorry, this was more like a pseudo code. I just wanted to plot a 
> concept. Of course, I will stick to the coding style of the project.

I just wanted to mention it before it might have been too late :-)

Bye,
   Axel.

Other related posts: