Closed D33M0N closed 4 years ago
Most likely that's because your DHCP server is not replying.
You can confirm this with tcpdump
or Wireshark.
I think it's possible that if you have another program listening for DHCP replies running, such as dhclient or some network management software such as NetworkManager or systemd-networkd, you won't see a reply in dhcptest either.
can't be it, because DHCP works. I do get address from DHCP server. Need this tool to discover possible rogue DHCP servers (duplicate replies from different sources)
can't be it, because DHCP works. I do get address from DHCP server.
The DHCP server may decide to reply to your PC's actual DHCP client, but not dhcptest
(e.g. due to the random MAC address in the request).
it should make no difference, because it works this way in windows. And even when I use the actual MAC I get no reply:
$ sudo dhcptest --iface enp0s31f6 --mac 98:FA:9B:1A:41:33
dhcptest v0.7 - Created by Vladimir Panteleev
https://github.com/CyberShadow/dhcptest
Run with --help for a list of command-line options.
Listening for DHCP replies on port 68.
Type "d" to broadcast a DHCP discover packet, or "help" for details.
d
Sending packet:
op=BOOTREQUEST chaddr=98:FA:9B:1A:41:33 hops=0 xid=FC5E558F secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=
1 options:
53 (DHCP Message Type): discover
d
Sending packet:
op=BOOTREQUEST chaddr=98:FA:9B:1A:41:33 hops=0 xid=45B52D21 secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=
1 options:
53 (DHCP Message Type): discover
q
not sure I can just kill network manager or anything similar and the network keeps functioning?
dhcpd.service is not running by default when it doesn't need to get new address:
$ systemctl status dhcpcd.service
● dhcpcd.service - dhcpcd on all interfaces
Loaded: loaded (/usr/lib/systemd/system/dhcpcd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
You can confirm this with
tcpdump
or Wireshark.
wireshark confirms I get reply. dhcptest does not show anything about it though.
Frame 2: 343 bytes on wire (2744 bits), 343 bytes captured (2744 bits) on interface enp0s31f6, id 0
Interface id: 0 (enp0s31f6)
Interface name: enp0s31f6
Encapsulation type: Ethernet (1)
Arrival Time: Jun 18, 2020 15:05:44.918571443 EEST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1592481944.918571443 seconds
[Time delta from previous captured frame: 0.000742063 seconds]
[Time delta from previous displayed frame: 0.000742063 seconds]
[Time since reference or first frame: 0.000742063 seconds]
Frame Number: 2
Frame Length: 343 bytes (2744 bits)
Capture Length: 343 bytes (2744 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:dhcp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Cisco_80:4e:d9 (44:d3:ca:80:4e:d9), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Cisco_80:4e:d9 (44:d3:ca:80:4e:d9)
Address: Cisco_80:4e:d9 (44:d3:ca:80:4e:d9)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.100.1, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 329
Identification: 0x00dc (220)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: UDP (17)
Header checksum: 0x951e [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.100.1
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Source Port: 67
Destination Port: 68
Length: 309
Checksum: 0x5f74 [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
[Timestamps]
[Time since first frame: 0.000000000 seconds]
[Time since previous frame: 0.000000000 seconds]
Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x80361a6c
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
1... .... .... .... = Broadcast flag: Broadcast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.100.23
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: LCFCHeFe_1a:41:33 (98:fa:9b:1a:41:33)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Length: 1
DHCP: Offer (2)
Option: (54) DHCP Server Identifier (192.168.100.1)
Length: 4
DHCP Server Identifier: 192.168.100.1
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (86400s) 1 day
Option: (58) Renewal Time Value
Length: 4
Renewal Time Value: (43200s) 12 hours
Option: (59) Rebinding Time Value
Length: 4
Rebinding Time Value: (75600s) 21 hours
Option: (1) Subnet Mask (255.255.255.0)
Length: 4
Subnet Mask: 255.255.255.0
Option: (3) Router
Length: 4
Router: 192.168.100.1
Option: (6) Domain Name Server
Length: 8
Domain Name Server: 1.1.1.1
Domain Name Server: 1.0.0.1
Option: (15) Domain Name
Length: 9
Domain Name: xxx
Option: (255) End
Option End: 255
Then, you need to find the program listening on the DHCP client port (68).
Nothing seems to be:
$ sudo netstat -lnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 858/pihole-FTL
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1486/cupsd
tcp 0 0 0.0.0.0:34375 0.0.0.0:* LISTEN 1655/pcloud
tcp 0 0 127.0.0.1:4711 0.0.0.0:* LISTEN 858/pihole-FTL
tcp6 0 0 :::53 :::* LISTEN 858/pihole-FTL
tcp6 0 0 ::1:631 :::* LISTEN 1486/cupsd
tcp6 0 0 ::1:4711 :::* LISTEN 858/pihole-FTL
udp 0 0 0.0.0.0:53 0.0.0.0:* 858/pihole-FTL
udp 0 0 0.0.0.0:69 0.0.0.0:* 851/in.tftpd
udp 0 0 0.0.0.0:37978 0.0.0.0:* 737/avahi-daemon: r
udp 0 0 0.0.0.0:5353 0.0.0.0:* 737/avahi-daemon: r
udp 0 0 0.0.0.0:42420 0.0.0.0:* 1655/pcloud
udp6 0 0 :::53 :::* 858/pihole-FTL
udp6 0 0 :::69 :::* 851/in.tftpd
udp6 0 0 :::49675 :::* 737/avahi-daemon: r
udp6 0 0 :::5353 :::* 737/avahi-daemon: r
raw6 0 0 :::58 :::* 7 833/NetworkManager
raw6 0 0 :::58 :::* 7 833/NetworkManager
also while wireshark is able to capture the packet, then ... shouldn't dhcptest also? using same method or something?
Packet capturing would make dhcptest
be less like a DHCP client and more like a packet sniffer. It would also make it unportable. As such, it is outside of the scope of this project.
Wait what? Why did you close it? The problem is still here and dhcptest doesn't receive and show the the dhcp reply packet. Sorry for using "packet capture" to name the process, but name it whatever you want and is proper for you, but it doesn't do it.
Found a program from AUR to help with capture (yeah, this one actually uses capture with libpcap), yet it doesn't do the send request part. maybe take a look @ this capture thing. dhcpdump ( http://www.mavetju.org/unix/general.php ):
$ sudo dhcpdump -i enp24s0
TIME: 2020-06-19 04:33:38.155
IP: 192.168.1.11 (70:85:c2:b3:f2:6c) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: c0c86155
SECS: 0
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: f6:ee:29:81:a6:a4:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 1 (DHCPDISCOVER)
---------------------------------------------------------------------------
TIME: 2020-06-19 04:33:38.775
IP: 192.168.1.1 (74:4d:28:8c:70:6b) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: c0c86155
SECS: 0
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 192.168.1.108
SIADDR: 192.168.1.1
GIADDR: 0.0.0.0
CHADDR: f6:ee:29:81:a6:a4:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER)
OPTION: 54 ( 4) Server identifier 192.168.1.1
OPTION: 51 ( 4) IP address leasetime 600 (10m)
---------------------------------------------------------------------------
TIME: 2020-06-19 04:36:09.349
IP: 192.168.1.251 (f0:fe:6b:fe:de:8) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 03000000
SECS: 0
FLAGS: 0
CIADDR: 192.168.1.251
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: f0:fe:6b:fe:de:08:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST)
OPTION: 57 ( 2) Maximum DHCP message size 1500
OPTION: 54 ( 4) Server identifier 192.168.1.1
OPTION: 50 ( 4) Request IP address 192.168.1.251
OPTION: 12 ( 9) Host name HF-LPT220
---------------------------------------------------------------------------
First packet is then the one sent by the dhcptest below. The last packet is even some other device DHCP renewal packet!!! AWESOME! :)
meanwhile in the dhcptest land:
$ sudo dhcptest --iface enp24s0
[sudo] password for deemon:
dhcptest v0.7 - Created by Vladimir Panteleev
https://github.com/CyberShadow/dhcptest
Run with --help for a list of command-line options.
Listening for DHCP replies on port 68.
Type "d" to broadcast a DHCP discover packet, or "help" for details.
d
Sending packet:
op=BOOTREQUEST chaddr=F6:EE:29:81:A6:A4 hops=0 xid=C0C86155 secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=
1 options:
53 (DHCP Message Type): discover
q
In combination of those 2 I finally achieved what I wanted, even though the dhcptest in this case is used for sending out the requests on demand only.
Wait what? Why did you close it?
I can't see a problem in dhcptest. It is acting as it should, by waiting for UDP packets on the specified port. You could confirm this by using a generic UDP client, such as socat.
I don't know why it doesn't see the replies on your machine. I listed some of the common causes known to me, but there may be other reasons.
This page is a mechanism for reporting issues in the software itself. It is not appropriate for requesting technical support for using the software, and definitely not the proper place to request technical support with administrating or configuring your system. I suggest you use your distribution's support channels for assistance on why UDP clients running on your machine do not receive DHCP packets when they should.
it's listening on port 60053?
That looks like a randomly assigned port. (You could confirm by re-running dhcptest
and checking if the port changes.) Could the bind
call have failed in a silent manner somehow?
it's listening on port 60053?
That looks like a randomly assigned port. (You could confirm by re-running
dhcptest
and checking if the port changes.) Could thebind
call have failed in a silent manner somehow?
Nvm, this port 60053 -- was my error. Didn't do it with sudo. When I ran it as sudo, it did listen correctly to UDP port 68. But it didn't fix the problem. The program still did not receive or recognize or parse the packet correctly. Is there any way to debug if the dhcptest actually receives anything from the port (but due to being "wrong" doesn't do anything (eg. print out anything)?) Like can I somehow make dhcptest output raw output what it receives from network -- everything, without trying to parse it first?
Yes, you can try socat
, as I suggested above.
sudo socat UDP4-RECVFROM:68 -
Then run dhcptest
in another window and type d
.
Can't do that. If I run first socat, then running sudo dhcptest gives error: Error while attempting to bind socket: Unable to bind socket: Address already in use Replies will not be visible. Use a packet capture tool to see replies, or try re-running the program with more permissions.
$ sudo netstat -tulnp | grep :68
udp 0 0 0.0.0.0:68 0.0.0.0:* 230248/socat
and when I run first sudo dhcptest, then sudo socat gives error: $ sudo socat UDP4-RECVFROM:68 - 2020/06/19 18:00:04 socat[230384] E bind(5, {AF=2 0.0.0.0:68}, 16): Address already in use
Yes, that's expected. Use dhcptest
only for sending, socat
will do the receiving.
Nope. Nothing comes through... so wtf could be blocking it... but now I have tool to test with. Thanks, will let you know when I manage to figure something out :/
Jebus ... SORRY for wasting your time. Finally figured it out. It was the effing firewalld which for whatever reason didn't allow UDP 68 through even when the DHCP service was allowed (apparently was only allowing server UDP port 67 through) ... and somehow this never prevented the computer network manager ever getting ip address from DHCP server ever before... like network manager somehow ignored firewall? Very weird. SORRY AGAIN :blush:
if I run it without sudo I get error:
which is obvious, but when I run it as sudo I still don't get any reply ever.
$ sudo dhcptest --iface enp0s31f6 [sudo] password for deemon: dhcptest v0.7 - Created by Vladimir Panteleev https://github.com/CyberShadow/dhcptest Run with --help for a list of command-line options.
Listening for DHCP replies on port 68. Type "d" to broadcast a DHCP discover packet, or "help" for details. d Sending packet: op=BOOTREQUEST chaddr=36:60:A7:14:11:2C hops=0 xid=A878818A secs=0 flags=8000 ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file= 1 options: 53 (DHCP Message Type): discover d Sending packet: op=BOOTREQUEST chaddr=36:60:A7:14:11:2C hops=0 xid=4B02BE58 secs=0 flags=8000 ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file= 1 options: 53 (DHCP Message Type): discover d Sending packet: op=BOOTREQUEST chaddr=36:60:A7:14:11:2C hops=0 xid=78E2B844 secs=0 flags=8000 ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file= 1 options: 53 (DHCP Message Type): discover
same thing with --iface enp0s31f6 --raw
Does work fine in windows computer.