Strange renew unicast - help needed

[Nikolay P]

Good day,

Could someone help me to figure out solution for my problem?

I have ISC DHCP server (isc-dhcpd-4.2.5-P1) running on a Linux machine and allocating IP addresses for 5 VLANs. There is Cisco Layer-3 switch which does inter-VLAN routing. Every VLAN interface has ip-helper address.

There is one client (dhcpcd 6.2.0) which has trouble with renewing IP lease. It successfully receives address when it is done booting (Broadcast via ip-helper).

When it is time to renew the lease it sends unicast DHCPREQUEST to the server. In this request:

IP: 192.168.10.1 (xx:xx:xx:xx:xx:xx) > 192.168.1.1 (yy:yy:yy:yy:yy:yy)
OP: 1 (BOOTREQUEST)
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
OPTION: 50 Request IP address: 192.168.10.1

Server replies:

IP: 192.168.1.1 (yy:yy:yy:yy:yy:yy) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 2 (BOOTREPLY)
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 192.168.10.1
GIADDR: 0.0.0.0
OPTION: 53 DHCP message type 6 (DHCPNAK)
OPTION: 56 Message requested address not available

What I understand from this is that client sends unicast to the server (which does not go thru the ip-helper) thus server receives it directly on interface eth0. It sees both CIADDR and GIADDR are zeros and replies with BROADCAST. Client can not receive it since they are on different VLANs.

At some point T1 expires and client sends BROADCAST which goes to the ip-helper and client finally gets IP from server.

How is this behavior possible? Should not the CIADDR be filled out by client if it sends UNICAST request?

[Peter Rathlev]

Post by Nikolay P
When it is time to renew the lease it sends unicast DHCPREQUEST to the
IP: 192.168.10.1 (xx:xx:xx:xx:xx:xx) > 192.168.1.1 (yy:yy:yy:yy:yy:yy)
OP: 1 (BOOTREQUEST)
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
OPTION: 50 Request IP address: 192.168.10.1

That looks like a malformed request. CIADDR is supposed to contain the
clients current IP address.

[Nikolay P]

----- "Peter Rathlev" <***@rathlev.dk> wrote:

Peter, thank you for reply.

Post by Peter Rathlev
That looks like a malformed request. CIADDR is supposed to contain
the
clients current IP address.

[Peter Rathlev]

When this station was connected with
cable it operated fine. But cable gone bad and I had to temporarily
connect the station with wireless Level 2 bridge. This is the only
change I made. Anyway for the station nothing should really change -
it has Ethernet connection and wireless stuff should be absolutely
transparent to the station. It is connected to the same VLAN as it was
before.
I had problem with DHCP snooping after I connected wireless bridge
(requests from client would be blocked), so I disabled DHCP snooping
entirely.

Have you tried seeing what the client actually sends with e.g. tcpdump
running at the time of renew? Just to make sure it's not some middlebox
that clears CIADDR or something like that. Something that might normally
insert option 82 or the like.

[Hunter Fuller]

Yes, it feels to me like your wireless bridge might be somehow munging the
packet. Try to sniff on one side of the wireless link and also on the
other, and compare the packets ...
--
Hunter Fuller
OIT

Sent from my phone.

Post by Peter Rathlev

When this station was connected with
cable it operated fine. But cable gone bad and I had to temporarily
connect the station with wireless Level 2 bridge. This is the only
change I made. Anyway for the station nothing should really change -
it has Ethernet connection and wireless stuff should be absolutely
transparent to the station. It is connected to the same VLAN as it was
before.
I had problem with DHCP snooping after I connected wireless bridge
(requests from client would be blocked), so I disabled DHCP snooping
entirely.

Have you tried seeing what the client actually sends with e.g. tcpdump
running at the time of renew? Just to make sure it's not some middlebox
that clears CIADDR or something like that. Something that might normally
insert option 82 or the like.
--
Peter
_______________________________________________
dhcp-users mailing list
https://lists.isc.org/mailman/listinfo/dhcp-users

[Nikolay P]

Post by Peter Rathlev
Have you tried seeing what the client actually sends with e.g.
tcpdump
running at the time of renew? Just to make sure it's not some
middlebox
that clears CIADDR or something like that. Something that might
normally
insert option 82 or the like.

Thank you Peter and Hunter.

The client is innocent. I used tcpdump and Wireshark to find that client generates valid unicast renew with CIADDR value set. So now I need to find what device modifies the request - Wi-Fi bridge or access point. To achieve this I need to sniff and decrypt Wi-Fi traffic.

Post by Peter Rathlev
--
Peter
_______________________________________________
dhcp-users mailing list
https://lists.isc.org/mailman/listinfo/dhcp-users

[Hunter Fuller]

Well this is starting to become off topic, but if you can try to swap
out the client or the AP for a different brand entirely, you could
narrow it down that way.

In any case, glad you were able to narrow it down a bit.

--
Hunter Fuller
Network Engineer
VBRH M-9B
[phone]

Office of Information Technology
The University of Alabama in Huntsville
Systems and Infrastructure

I am part of the UAH Safe Zone LGBTQIA support network:
http://www.uah.edu/student-affairs/safe-zone

Post by Nikolay P

Post by Peter Rathlev
Have you tried seeing what the client actually sends with e.g.
tcpdump
running at the time of renew? Just to make sure it's not some
middlebox
that clears CIADDR or something like that. Something that might
normally
insert option 82 or the like.

Thank you Peter and Hunter.
The client is innocent. I used tcpdump and Wireshark to find that client generates valid unicast renew with CIADDR value set. So now I need to find what device modifies the request - Wi-Fi bridge or access point. To achieve this I need to sniff and decrypt Wi-Fi traffic.

Post by Peter Rathlev
--
Peter
_______________________________________________
dhcp-users mailing list
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
https://lists.isc.org/mailman/listinfo/dhcp-users