[haiku-gsoc] Re: Fwd: Re: [HCD08] ICMP error handling & propagation project
- From: "Yin Qiu" <allenchue@xxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Sun, 20 Jul 2008 12:34:48 +0800
Attached is my new diff file for ICMP error handling and propagation. No big
progress really except some minor changes. But I would appreciate if you
help me answer my following (many) questions.
1. I don't quite understand the parameters of the error_reply(net_protocol
*self, net_buffer *causedError, uint32 code, void *errorData) hook. My guess
is that causedError the original received packets, code is the error code
defined by me (as in net_error.h). Is that correct? Then what is the
errorData pointer?
2. As in item 1, the error_reply() hook requires a net_protocol pointer
argument. However, since this function is typically invoked in
receive_data(), in which we can only access the net_buffer parameter, how do
I obtain the net_protocol pointer in order to call error_reply()? Or can I
just get the domain protocol module and then call the error_reply hook with
the first argument being NULL?
3. For the ICMP propagation, how do I handle the errors inside the
error_received() hooks of TCP/UDP protocols? Just return an appropriate
error code?
4. I'm still not clear about how ICMP protocol is utilized to handle the
error. As discussed, a registering mechanism is supposed to exist to allow
ICMP to register itself as the error handler on the domain. For now let's
just leave this mechanism as a later refinement. Then how do I get the icmp
protocol module info in the ipv4 code? Can I use the
sStackModule->get_domain_receiving_protocol(...) function?
5. So icmp_error_reply(...) should generate the response datagram and use
send_data() to reply to the target protocol? What's more, here we face the
IP header missing problem. I want to confirm this: are we going to add an
extra ipv4_header field in the net_buffer struct? And will this bring any
side-effect?
Looking forward to your reviews. Thanks.
On Mon, Jul 14, 2008 at 1:05 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> "Yin Qiu" <allenchue@xxxxxxxxx> wrote:
> > I am notified that I have to subscribe the haiku-gsoc mailing list. I
> > tried
> > and was informed that I am already a subscriber of it, which was
> > supposed to
> > be. It seems that the something went wrong about the mailing list, so
> > I am
> > forwarding the previous mail to you directly.
>
> Bummer; sometimes it makes sense to check in the mailing list history
> if your mail actually showed up when in doubt. In any case, I'm
> answering to you personally and on the list.
>
> > Attached is a diff file and an header file reflecting my current
> > understanding about the project. The code is most just skeleton.
> > Vachkov's
> > work was my primary reference. Please help me by checking the new
> > code and
> > added comments to see if my understanding is correct.
>
> Besides some very minor coding style issues (the comment style is a bit
> inconsistent, some constant naming could be improved (like
> NET_ERROR_FRAG_DF)), I think you are on the right track.
>
> > I also have some additional questions, which might be stupid.
>
> Nope, not this time ;-)
>
> > 1. How does the IPv4 protocol dispatch the error to the target
> > protocol in
> > case of an invocation of error_received()?
>
> It would need to do something similar to what it already does for
> ipv4_receive_data() - determine the target protocol, and forward it to
> that one.
>
> > 2. On the other side, how does the ICMP protocol call the
> > error_received()
> > hook of the IPv4 protocol?
>
> The ICMP protocol would either need to register itself as an error
> handler with the domain (and gains some special functions it could
> use), or it would just directly call the error_received() function on
> the domain.
>
> > 3. Source quench message is supposed to be sent when the host or
> > gateway is
> > receiving datagrams that exceeds its processing capacity. How do we
> > determine the incoming datagrams are actually exceeding or
> > approaching the
> > capacity?
>
> Since we cannot restrict our CPU usage in any way, the only way for
> this to happen would be the lack of memory to create new buffers. So if
> a new buffer cannot be created due to a B_NO_MEMORY error, the source
> quench message could be generated.
> Since this might come too late (both report-wise and layer-wise), you
> might also want to have a look at other operating systems (like Linux
> or FreeBSD) how they handle this, and if they send those messages at
> all.
>
> > 4. As Alan previously pointed out, when the upper protocol like TCP/
> > UDP
> > encounters an error, it should call the error_reply() hook, which in
> > turn
> > generates the ICMP error message. According to RFC 792, this ICMP
> > message
> > should include original IP header, which has been removed prior to
> > propagating the packages to upper protocol. I checked the original
> > thread
> > and it seems that no solution was given. Do you have any clue to
> > solve this
> > problem?
>
> We had a few possible suggestions outlined in that thread. IIRC I
> favored adding the header as an extra field (protected against changes)
> to the net_buffer, so that it can later still be accessed.
> Another way would be to reconstruct that header on the fly if that is
> possible (which might be by storing only a tiny bit more than what the
> net_buffer already has).
> Again, it might be educational to have a look at other platforms; while
> other networking stacks have usually less strictly separated layers,
> the general problem is the same.
>
> HTH, and I'm looking forward for your next questions (and diffs) :-)
>
> Bye,
> Axel.
>
>
--
Yin Qiu
Nanjing University, China
-------------------------------------------
/*
* Copyright 2006-2008, Haiku, Inc. All Rights Reserved.
* Distributed under the terms of the MIT License.
*/
#ifndef NET_ERROR_H
#define NET_ERROR_H
#define NET_ERROR_TIMEEX_IN_TRANSIT 154 // 11*14+0
#define NET_ERROR_TIMEEX_FRAG 155 // 11*14+1
#define NET_ERROR_PARAM_PROBLEM 168 // 12*14+0
#define NET_ERROR_SOURCE_QUENCH 56 // 4*14+0
#define NET_ERROR_NET_UNREACH 42 // 3*14+0
#define NET_ERROR_HOST_UNREACH 43 // 3*14+1
#define NET_ERROR_PROTO_UNREACH 44 // 3*14+2
#define NET_ERROR_PORT_UNREACH 45 // 3*14+3
#define NET_ERROR_FRAG_NEEDED 46 // 3*14+4
#define NET_ERROR_SOURCE_ROUTE_FAIL 47 // 3*14+5
#define NET_ERROR_REDIRECT_NET 70 // 5*14+0
#define NET_ERROR_REDIRECT_HOST 71 // 5*14+1
#define NET_ERROR_REDIRECT_TOS_NET 72 // 5*14+2
#define NET_ERROR_REDIRECT_TOS_HOST 73 // 5*14+3
#endif
Other related posts:
