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.
I’ll try.
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:
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.
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?
An Error Was Encountered
Uploading failed!!!
Only gif|jpg|png|jpeg|svg files smaller then 1024k are allowed for this time interval. Allowed file size depends on expiration time.
It is not a photo, it is not text, so susepaste does not allow it.
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.
On 2015-06-28 19:56, arvidjaar wrote:
>
> Well, apart from several ARP it shows expected
> Code:
> --------------------
>
> 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 :-?
Client did send requests DHCPDISCOVER and DHCPREQUEST, otherwise server had not sent replies. But client sends both of them as broadcasts.
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.
It is normal IP (not TCP obviously), but client sends them as broadcasts because it does not know anything about server yet. Server may send replies as broadcasts if client tells it to do so.
> It is normal IP (not TCP obviously), but client sends them as broadcasts
> because it does not know anything about server yet. Server may send
> replies as broadcasts if client tells it to do so.
I got a better capture, including all packages, not only those including the router address somewhere.
On 2015-06-30 14:56, lorenzodes wrote:
>
> the DHCP client uses raw sockets, it is not affected by a DROP rule in
> the INPUT / OUTPUT chains of netfilter.
Then please explain why the firewall does report it is dropping or
allowing them… You have the link to the capture data available for
study, if you wish.
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.
