On 2015-06-27 13:26, arvidjaar wrote:
> And what is 192.168.1.129? Is it server from which you post logs?
Oops, I forgot to say. Yes, it is the machine where I see the logs (and
gets the packets). And the 192.168.1.1 is the router.
Only that it is a laptop, and certainly doesn’t boot from network.
Unless… unless the BIOS (it is a Compaq) has that option and queries
the network on boot. But I get the firewall hit somewhat later than that.
I booted at 09:58:55, and the hit was 10:16:01. That’s about the time
the cron jobs would run, this is a 13.1 machine.
Ports 67 and 68 are used by BOOTP and DHCP and the first application is to obtain IP address and other information; it does not mean client wants to boot from network. As this is directed packet it should be reply from server to some client request. I am not sure whether DHCP server sends any unsolicited packet to client on its own. Sniffing traffic could probably tell more.
On 2015-06-27 14:06, arvidjaar wrote:
> robin_listas;2717083 Wrote:
>> certainly doesn’t boot from network.
> Ports 67 and 68 are used by BOOTP and DHCP and the first application is
> to obtain IP address and other information; it does not mean client
> wants to boot from network. As this is directed packet it should be
> reply from server to some client request. I am not sure whether DHCP
> server sends any unsolicited packet to client on its own. Sniffing
> traffic could probably tell more.
It can not be dhcp, as the firewall blocks it, yet dhcp works.
However, you are certainly in the right track, as the message log shows corresponding events:
On 2015-06-27 21:06, arvidjaar wrote:
> robin_listas;2717116 Wrote:
>> By the timestamp, it has to be “dhcp discover”
> DHCPDISCOVER is broadcast by client and here is unicast from server to
> client. If anything, it seems to be rather DHCPOFFER. But packet trace
> would be interesting.
I now have a wireshark capture. I have marked the packages, so I guess I
could save just that block. What would be the best format for pasting here?
On 2015-06-28 19:56, arvidjaar wrote:
> Well, apart from several ARP it shows expected
> 3 293.390138 192.168.1.1 → 192.168.1.129 DHCP 342 DHCP Offer - Transaction ID 0xa902c778
> 6 299.411448 192.168.1.1 → 192.168.1.129 DHCP 342 DHCP ACK - Transaction ID 0xa902c778
> That’s all. What’s interesting, there is no response from client (I
> expect DHCPREQUEST from client, and there is no initial DHCPDISCOVER as
> well). May be it is due to wireshark filters you used.
> So it looks like normal DHCP transaction. Why it gets logged, and more
> interestingly - how client gets these packets if they are apparently
> dropped by firewall - I do not know.
Well, I could open the firewall to them; then I’d guess the client would
send the response. Unless there is another response that is not a tcp/ip
package at all, because at the start the client doesn’t have an IP to use.
Yes, the router is sending ARPs to the entire IP range, one by one, and
loop again. What I posted was the section of the event as seen in the
logs, and filtering capture by IP=router_IP.
I don’t know if it is viable to capture half an hour of everything
without limiting the capture filter :-?
There’s nothing to study, it’s well known, the ISC dhcp client uses raw sockets. This is why DHCP works. This is why, from logs, you can see inbound packets (i.e. from server to client) and not outbound packets.
Raw sockets bypass the TCP/IP stack and thus netfilter.