[haiku-development] Re: Network Issues. Part I. The advice for debugging DHCP problems needed!

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 19 Nov 2009 08:56:17 +0100

Siarzhuk Zharski <zharik@xxxxxx> wrote:
> 192.168.179.1.bootps > 192.168.179.80.bootpc:

I guess this one could be the culprit: your DHCP server does not follow 
the protocol; if the client does not yet know its own address, the 
server should send to the IP broadcast address instead of the client's 
future address.

In line 1590 in src/add-ons/kernel/network/protocols/ipv4/ipv4.cpp 
incoming packets are tested if they contain a local address
Enabling tracing in the ipv4 module should give you the appropriate 
message in syslog, if the packet is thrown away there.
The is_local_address() method of the datalink layer (src/add-
ons/kernel/network/stack/datalink.cpp) does check, however, if the 
client already has an address or not. Maybe the problem is somewhere 
there; either it already has an address, or there is another interface 
that receives the packet (this mechanism does not really look good to 
me).
I think the check should take the hardware address into account to find 
the fallback interface -- but even that would only work if there is no 
address yet. Maybe an empty address is set, and that's what is causing 
the trouble in this case.

> always returns B_TIMED_OUT and -1 as bytesReceived result. Note that 
> tcpdump, working simultaneously catches all packets without problems!

That's because tcpdump has a packet monitor installed at link level 
instead.

> The Question: Unfortunately I'm not familiar with the network stack 
> architecture so I want to ask for some advice - where to insert my 
> debugging tracing entries? :-) I found it not trivial to found where 
> recvfrom is implemented and just want to save some time for my 
> debugging. :-)

Looking at the network stack architecture should definitely help in 
this case.

Bye,
   Axel.


Other related posts: