[haiku-gsoc] Re: Fwd: Re: [HCD08] ICMP error handling & propagation project
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Thu, 07 Aug 2008 13:46:09 +0200 CEST
Hi Yin,
"Yin Qiu" <allenchue@xxxxxxxxx> wrote:
> Thanks for your detailed comments and sorry for my unclear
> statements.
Sorry for the late reply, your mail got buried under a lot of other
ones.
> >> 3. Error handling mechanisms in TCP and UDP protocols are not yet
> >> fully
> >> implemented. However, maybe you can give some advice by reviewing
> > > the
> >> skeleton code in tcp.cpp and udp.cpp.
> > Not sure what advice you are seeking for. Do you mean how the
> > protocol
> > should react on the different errors?
> Yes. Shall I consult relating rfc (maybe rfc793?) for this?
That's what I would do, and also have a look at other implementations.
The standard usually doesn't take a lot of possible violations into
account (like DOS attacks).
> >> 5. Some invocation of error_reply currently lacks additional
> >> parameter, such
> >> as for ICMP type Parameter Problem. This will be resolved soon.
> > Defining different NET_ERROR_* macros should be the way to go, or
> > what
> > do you intend to do about it?
> Actually I was talking about the *errorData pointer value of the
> error_reply hook. Currently all the error_reply's are invoked with
> errorData being zero. Sometimes it may carry some data, e.g., for
> Parameter Problem, it may indicate where the wrong octet is.
Ah, okay.
> My concern was, for instance, how do I send an TIMESTAMP request
> message to a host using current API?
I don't think that there is or has to be a different way to how the
"ping" command does it: build the packet yourself, and send it as raw
packet.
> > as I said, useful NET_ERROR_* macros would be preferred.
> I don't quite understand what you mean by defining NET_ERROR_*
> macros?
> Could you show me an example? Anyway I want to explain my thoughts on
> this.
> Currently error_reply is called with the code argument being
> icmp_encode(icmpType, icmpCode), where: icmp_encode(), defined in
> icmp.h, encodes the ICMP type and code to another integer; icmpType
> and icmpCode represent the ICMP type and code by their names and have
> corresponding macros also defined in icmp.h, like ICMP_TYPE_UNREACH
> and ICMP_CODE_PROTO_UNREACH.
>
> The protocol indeed needs to know both the ICMP type and code. For
> example, TCP should be able to know if an ICMP error is a host
> unreachable message, a port unreachable message, or something else.
> So
> I then decode the error code with icmp_decode() in erorr_received
> hooks.
I think I would just define a NET_ERROR_PORT_UNREACHABLE and a
NET_ERROR_HOST_UNREACHABLE respectively, instead of having the
protocols decipher the ICMP type/codes - the upper layers shouldn't
really be concerned that much about the IP layer. If you think this is
unreasonable, then just leave it the way you've done it - if someone is
unhappy with this, or finds a reason to do so, he can still change it
then :)
> > I also don't see why the ICMP header is defined in public -- is it
> > used
> > anywhere outside the ICMP protocol module?
> I noticed that there was no need for ICMP header struct to go public.
> I'll move it back to icmp.cpp. However, IPv4 header is used inside
> the
> ICMP module, so I have made it public.
I noticed, that's why I only asked for the ICMP header :-)
Bye,
Axel.
Other related posts:
