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.