DHCP client issue - interface isn't picking address from DHCP

Bugs
, , , ,
1

Hi guys,

I’ve got a small lab deployment with Hyper-V 2012 R2 where I use VyOS as a router to connect to external networks.

My setup:

  • eth0 is connecter to my vSwitch which is bridged to my wlan adapter in hyper-v
  • standard network adapter (it didn’t work with legacy one at all)
  • configured to receive its address via DHCP

With my home router and my phone working as a hot spot it works just fine receiving its address. But when I connect to my lab switch, which is HP 5500 EI switch, using wireless access point - it’s not working:
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description

eth0 - u/u Internet
eth1 192.168.100.1/24 u/u Management
eth2 192.168.101.1/24 u/u Wireless
eth3 192.168.102.1/24 u/u Client
lo 127.0.0.1/8 u/u

I have a DHCP server running on my switch which is used for access points and other stuff. All devices are getting their IP addresses with no issues.

But:

  • connectivity works fine if I assign a static IP address to eth0;
  • if I connect a Win10 VM to the same vSwitch - it gets an IP address from 5500 EI, no issues;
  • if instead of my Internet vSwitch I connect it to my internal VM Network vSwitch where I’ve got another DHCP server running - no issues with getting IP address.

If I capture what’s happening on the interface:
vyos@vyos:~$ monitor interfaces ethernet eth0 traffic
Capturing traffic on eth0 …
0.000000 0.0.0.0 → 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x5560052d
2.572138 192.168.10.1 → 255.255.255.255 DHCP DHCP Offer - Transaction ID 0x5560052d
4.200164 0.0.0.0 → 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x5560052d
13.260000 0.0.0.0 → 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x5560052d
13.264215 192.168.10.1 → 255.255.255.255 DHCP DHCP Offer - Transaction ID 0x5560052d
23.728753 00:15:5d:64:0a:0f → 01:80:c2:00:00:0e LLDP Chassis Id = 00:15:5d:64:0a:0f Port Id = eth0 TTL = 120
27.460089 0.0.0.0 → 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x5560052d
27.464470 192.168.10.1 → 255.255.255.255 DHCP DHCP Offer - Transaction ID 0x5560052d
47.390230 0.0.0.0 → 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x5560052d
47.394774 192.168.10.1 → 255.255.255.255 DHCP DHCP Offer - Transaction ID 0x5560052d
53.778496 00:15:5d:64:0a:0f → 01:80:c2:00:00:0e LLDP Chassis Id = 00:15:5d:64:0a:0f Port Id = eth0 TTL = 120

No DHCP request, no DHCP Acknowledgement…

This is how it looks like when I connect eth0 to my VM Network vSwitch:
149.448706 0.0.0.0 → 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x3ad44515
149.449926 192.168.102.1 → 192.168.102.3 DHCP DHCP Offer - Transaction ID 0x3ad44515
149.450121 00:15:5d:64:0a:15 → ff:ff:ff:ff:ff:ff ARP Who has 192.168.102.3? Tell 192.168.102.1
149.450195 0.0.0.0 → 255.255.255.255 DHCP DHCP Request - Transaction ID 0x3ad44515
149.451258 192.168.102.1 → 192.168.102.3 DHCP DHCP ACK - Transaction ID 0x3ad44515

Any ideas what could be causing the issue?

2

At least, you’re halfway dora…
Does dhclient do any logging? You might be able to run dhclient in foreground, viewing all its messages

3

Moreover, do you have WAN_LOCAL rules in place, that might block incoming DHCP responses?

4

My current configuration is attached.
Where I can see the log you mentioned?

5

Compare DHCP offers.
use:
sudo tcpdump -i eth0 -n -vvv udp port 67 or 68
You can even use “-s 0 -w dhcp.pcap” to log to file which can be opened in wireshark.

As already can be seen , one is in IP unicast, the other a IP broadcast
192.168.10.1 → 255.255.255.255 DHCP DHCP Offer
192.168.102.1 → 192.168.102.3 DHCP DHCP Offer
See also:

6

Thanks for that.

UDP checksum issue…

tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 byte s
08:36:22.533394 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP ( 17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:15 :5d:64:0a:0f, length 300, xid 0xe912b63b, secs 46, Flags [none] (0x0000)
Client-Ethernet-Address 00:15:5d:64:0a:0f
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 4: “vyos”
Parameter-Request Option 55, length 5:
Subnet-Mask, BR, Default-Gateway, Domain-Name-Server
MTU
END Option 255, length 0
PAD Option 0, length 0, occurs 43
08:36:22.591077 IP (tos 0xe0, ttl 255, id 53213, offset 0, flags [none], proto U DP (17), length 336)
192.168.10.1.67 > 255.255.255.255.68: [bad udp cksum ab76!] BOOTP/DHCP, Repl y, length 308, xid 0xe912b63b, Flags [Broadcast] (0x8000)
Your-IP 192.168.10.116
Client-Ethernet-Address 00:15:5d:64:0a:0f
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.10.1
Lease-Time Option 51, length 4: 7200
RN Option 58, length 4: 3600
RB Option 59, length 4: 6300
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.10.1
Domain-Name-Server Option 6, length 4: 8.8.8.8
Domain-Name Option 15, length 10: “XXXXX”
END Option 255, length 0
PAD Option 0, length 0, occurs 10

It may be related to how it’s offloaded… I doesn’t look like it’s happening in VyOS:
vyos@vyos:~$ sudo ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

To it may be somewhere in Hyper-V. Need to dig in this direction.

7

Disabled all offloading features in Hyper-V - no changes…
Windows machines being connected to the same vSwitch can easily get ip adresses from the DHCP…

8

We are having a very strange problem , that is we have a lan with 16 vlans and all the vlans have different DHCP for each vlan in the coreswitch (Cisco 6509) and all the clients in the 16 vlans are windows 7 clients , now the problem is that some machines are not getting IP Addresses , but if we see the registry settings in those machines we see that there is an ip address given by the dhcp server in the following key of registery

1 Like