[openbeosnetteam] Re: Network stack question

Axel Dörfler wrote:

Ivo Vachkov <ivo@xxxxxxxxxxx> wrote:

It all starts with ipv4_receive_data(); At the end we see:

    return module->receive_data(buffer);

Well, we can extend it like this:

status_t st = module->receive_data(buffer);

switch (st) {
    case FROM_PROTO_UDP_PORT_UNREACH: {
net_protocol_module_info *m = receiving_protocol(IPPROTO_ICMP);
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 ?
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.
But to improve planning, maybe it helps to list what kind of errors may occur, and how they should be resolved. Also how things like path MTU discovery may be implemented should be part of the planning process. 

I can create a list pretty fast :)

IP:
- net/host unreachable (on receiving -> notify UDP/TCP)
- protocol unreachable
- fragmentation needed (related to PMTU)
- source route failed (does anyone use source routing today ???)
- time exceeded
- parameter problem (not really in use, ip options related)
- source quench (on receiving -> notify UDP/TCP to slow down)
- redirect (on receiving -> modify routing table)

ICMP:
- echo request/reply
- timestamp request/reply
- information request/reply

TCP/UDP:
- port unreachable (TCP RST vs. UDP+ICMP)
About the PMTU - it's kinda challenge to implement that ... I have to search for references in other OSs before I can comment.
BTW, from the code snippet above, I strongly recommend to have a look at our coding style guide before you start coding: http://haiku-os.org/documents/dev/haiku_coding_guidelines :-) When in doubt, copying the style that is used throughout the stack now should help.
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. 


Bye,
   Axel.


/ipv

Other related posts: