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.