Ask Your Question

Machines get IP address but no connectivity - DNS issue?

asked 2020-10-21 11:00:34 +0000

balcee gravatar image

updated 2020-10-21 13:15:44 +0000

Hi team

I hope you can help me with a problem that's beginning to cause me more and more pain over recent days.

We have an office with a subnet of /16.

What's been happening recently is when a laptop joins the network (either LAN connected or WiFi), the devices gets the correct IP assigned through DHCP, but has no network/Internet connection. I'm unable to ping the host from the Data Centre, nor can I see it in the local ARP table. Although it shows up on the DHCP server.

This sounds DNS related but I can't quite put my finger on it.

Would someone be kind enough to look through the Wireshark capture at the following link and tell me if something stands out there please? The IP address of the machine in this case was

Wireshark capture:

Many thanks for your assistance.

edit retag flag offensive close merge delete


How was the capture made? Have you tried capturing on the ethernet interface?

Interface Dropped packets Capture filter Link type Packet size limit \Device\NPF_Loopback 0 (0 %) none NULL/Loopback 262144 bytes

Chuckc gravatar imageChuckc ( 2020-10-21 14:06:34 +0000 )edit

Yes, that capture was created on the ethernet interface.

balcee gravatar imagebalcee ( 2020-10-21 17:15:33 +0000 )edit

Can you verify with Statistics -> Capture File Properties
The capture "Lan not connected" shows Encapsulation and Interface as Loopback.

A capture showing the full DHCP conversation would be nice.

Chuckc gravatar imageChuckc ( 2020-10-21 17:45:16 +0000 )edit

Nope, frame.interface_name says "\Device\NPF_Loopback", and encapsulation is "NULL/Loopback".

But it does provide some interesting information though. Apply this display filter: ip.dst=

You see NBNS packets to the network broadcast address, that is the network part of the IP address completed with all ones. This works out to be That's not right according to your statement that it's supposed to be a /16. So there's something wrong with the address and net mask assignment to this device. DNS does not even come into play in this scenario.

Jaap gravatar imageJaap ( 2020-10-21 17:53:57 +0000 )edit

Since DHCP traffic flows over broadcast messages it is normal that clients get the IP addresses from DHCP Server.

Do have chance to check the connectivity step by step.

  • Connection to the gateway,

  • Connection to the proxy, if exists.

  • You may check routing issues?

  • You may check DHCP configuration to be sure about what IP configuration is sent tothe client.

  • you may try pinging (google dns) if your firewall allows.

  • Do you have local firewalls?

  • What do the outputs of the tracert or pathping like tools.

  • Do you have access intranet sites?

  • Did you have chance to check the connectivity to the port 53 of the DNS server?

Kind regards Gökalp

agergec gravatar imageagergec ( 2020-10-21 20:19:13 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2020-10-26 13:22:03 +0000

SYN-bit gravatar image

Here is another capture. This machine was connected to LAN, no WiFi or any other connectivity:

This PC was on the 6th floor on vlan 1401. The phone on the desk is in vlan 1361. Default gateway for vlan 1401 is & 3 /22 (2 core switches) and default gateway for vlan 1361 is & 3 /22

In the DHCP responses, the gateways address that is provided is and instead of the .2/.3 addresses you are referring to. Then looking at the ARP traffic, there are no repsonses to the ARPs for, so I guess you do only have the gateways at the .2/.3 addresses.

This either means the DHCP server has been configured incorrectly. But I assume you want to use a First-Hop-Redundancy-Protocol like HSRP or VRRP and that the gateway indeed should be the .1 address pointing at the HSRP/VRRP address. Going back to your trace and filtering on "vrrp || hsrp" is indeed showing VRRP packets advertising the .1 addresses. So the DHCP server is configured correctly and the gateways are indeed configured with the virtual addresses and

Then the problem is concentrated on why the (active) gateway is not responding to ARP requests for it's VRRP addresses. Could this be a configuration issue on the gateways?

Interestingly, on this capture, I'm seeing dhcp/bootp errors. How do I resolve these?

What kind of DHCP errors do you see?

edit flag offensive delete link more


Thanks SYN-bit, your analysis is spot on. Here are the errors I'm seeing when I go to Statistics:

11 Ethertype: Bad checksum [should be 0x18309dbf]
3 BOOTP/DHCP: Malformed Packet (Exception occurred)
2 BOOTP/DHCP: length < 5
balcee gravatar imagebalcee ( 2020-10-26 13:52:15 +0000 )edit

Regarding the reported "dhcp/bootp errors", The DHCP replies sent from the server (the DHCP Offers and the DHCP ACKs) are flagged as [Malformed Packet]. Is this more likely to be a DHCP dissector issue than an actual issue with the construction of the DHCP packet? It looks like dissection may start to go off the rails with option 128.

Jim Young gravatar imageJim Young ( 2020-10-26 13:55:49 +0000 )edit

I also meant to add that the DHCP dissector complains about the option 124 sent in the DHCP Discover and DHCP Request packets sent by the client device. The DHCP process apparently completed in spite of these "errors". Vendor specific options in DHCP packets can be mis-dissected.

Jim Young gravatar imageJim Young ( 2020-10-26 14:06:24 +0000 )edit

It's so disappointing when manufacturers don't even adhere to the most basic protocol encoding rules. :/

Jaap gravatar imageJaap ( 2020-10-26 14:49:51 +0000 )edit

For the DHCP malformed messages you can set the DHCP dissector preferences to handle option 125 and 130 in a Mitel specific way, i.e., as string.

Jaap gravatar imageJaap ( 2020-10-26 14:53:45 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-10-21 11:00:34 +0000

Seen: 138 times

Last updated: Oct 26