[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 11:13:03 +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.
> But whole record looks like this:
> 
> 01:00:07.377529 00:00:cb:53:02:40 (oui Unknown) > 00:90:f5:8f:7e:eb 
> (oui
> Unknown), 
> ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl  16, id 0, offset 
> 0,
> flags [none], proto: UDP (17), length: 328) 
> 192.168.179.1.bootps > 192.168.179.80.bootpc: [udp sum ok] 
> BOOTP/DHCP,
> Reply, length 300, xid 0x6a383c, Flags [ none ] (0x0000) 
> 
> I see that first line says that the packet was send directly to this 
> NIC
> MAC address.

The MAC address is not the problem; the IP address might be, though.

> At the moment I'm not familiar with such DHCP details but this
> server (ISC-DHCP one) works well with other network devices and 
> operating
> systems in ym home network. The only problematic combination is Haiku 
> OS
> and my driver in DHCP mode.

Since your driver received the packet, it cannot be the driver's fault 
anymore, but the problem has to be in the higher levels.

> > 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).
> If you meant another network interface - this one is a single. 
> Excluding
> loopback of course.

Which is strange, at least. This mechanism should really work with a 
single interface.

> > That's because tcpdump has a packet monitor installed at link level 
> > instead.
> But can be the tcpdump output a "confirmation" that packet was really
> transferred by the NIC driver and received by hte OS? I have used it 
> to
> check the network traffic and to assure that data was really 
> processed by
> the driver.

It cannot confirm that a packet really has been sent by the driver (ie. 
there is no loop back), but it does, of course, confirm that a packet 
has actually been received by the driver.

> >> 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.
> Of course, but "precise" advice from specialist can save us lot of 
> time in
> browsing sources. :-) Thank you very much for it! 

Sure, asking is perfectly fine, I just wanted give a pointer for further 
debugging; ie. the knowing the stack architecture should ease finding 
the responsible component :-)

Bye,
   Axel.


Other related posts: