[openbeosnetteam] Re: Network stack question
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Fri, 06 Jul 2007 12:16:38 +0200 CEST
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:
