[haiku-development] Re: GSoC ICMP implementation
- From: "Alvarez, Alan SPC MIL USA FORSCOM" <alan.alvarez@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 23 Mar 2008 23:48:21 +0300
Hello,
Thanks for the response Axel.
I spent a couple of more hours looking at the code again yesterday and now I
have a really good understanding of how the data gets passed around the
different layers. I have one more questions, and after this I think I'll be
able to start working on it:
It seems that the ipv4 header is being removed from the packet before the
buffer is passed to the other layers. This is from ipv4_receive_data():
gBufferModule->remove_header(buffer, headerLength);
// the header is of variable size and may include IP options
// (that we ignore for now)
I'm not sure if this is the case because I don't really understand how the
BufferModule works internally. Although it has a pretty good interface and
seems easy to use, the inner workings of it seem a little complex. If the IP
header is in fact being removed from the buffer, this would have to be modified
for error-handling purposes. In ICMP, when you send an error back to the
source, for most messages you have to send back the original IP header as part
of the packet. It would then have to be the next protocol's job to dispose of
the IP header too.
Respectfully,
Alan Alvarez
SPC(P), USA
----- Original Message -----
From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
Date: Sunday, March 23, 2008 19:56
Subject: [haiku-development] Re: GSoC ICMP implementation
To: haiku-development@xxxxxxxxxxxxx
> "Alvarez, Alan SPC MIL USA FORSCOM" <alan.alvarez@xxxxxxxxxxx> wrote:
> > > IIRC, these functions were introduced exactly for this purpose.
> > > Axel will probably tell you more.
> > This makes sense and I thought this was the case too, but since
> the
> > idea topics says to
> > "implement an error handling and propagation I though maybe that
> > wasn't necessarily its main
> > purpose.
>
> It was the purpose of introducing these functions, but I didn't put
> much thought into them when I added them; they might be a good way
> to
> solve this issue, but then they could also be not adequate and
> complete.
> I'm not that familiar with the issue anymore right now, but I think
> the
> way I envisioned it was to have the ICMP module register itself as
> error module to the domain (ie. ipv4 in this case), and would then
> automatically be used by the other protocols without a direct
> knowledge
> between the two.
> Of course, this would only then work nicely, if they actually can
> operate more or less independently of each other, which I am not
> entirely sure about right now either. It's been a while, sorry.
> In any case, the implementation should be good enough to be usable
> for
> Path-MTU discovery and of course cover all the needs of the UDP
> protocol.
>
> > Is Axel in this list? or should I direct my questions to the
> > development list?
>
> I'm subscribed to the other list as well, I was just on a vacation
> :-)
>
> > Also, I have one more question, What is the best way to output
> > messages (somewhere) for
> > debugging purposes so that I can verify something I implement is
> > actually working? I've seen
> > a macro DTRACE being used around the code but I'm not sure where
> > exactly this is to be
> > output(d). Should I enable debugging somewhere?
> > From what I can tell the built-in kernel debugger stops the
> system so
> > this wouldn't help much
> > since all I need is to see some simple debug messages.
>
> That depends on your configuration. One way is to use (from the
> kernel
> and kernel modules) dprintf(). It's output is by default send to
> the
> serial output, as well as to the syslog.
> If you develop under VMware or Qemu, or have a second system you
> can
> use as a serial debugging console, this should work well. If you
> only
> have a single Haiku system, you would need to look into the syslog
> for
> the output (under /var/log/syslog).
>
> HTH,
>
> Bye,
> Axel.
>
>
>
Other related posts:
