niccokunzmann/python_dhcp_server

a dhcp server in python

python_dhcp_server's Issues

remove old ip address entries

It may not be useful to hold entries very long. One should be able t always see the most important entries.

• stick them to the top
• sort by time
• add find
• allow removal of old entries

Create a new release 0.4

@greggzj, this can be a new release: https://github.com/niccokunzmann/python_dhcp_server/releases/tag/0.4
What would be nice for windows users, to have the standalone zip file. Are you willing to create this file?

Related: #8 (comment)

can i reserve ipv6 address

can i reserve or renew or get a static ipv6 address with the mac address

Create a new release 0.5

Hello @niccokunzmann , I just create a new release 0.5
https://github.com/niccokunzmann/python_dhcp_server/releases/tag/0.5

Hope it meets your expectation:)

How to run without GUI

I want to run it on a linux server cli without tkinter, how to do it?
Thanks!

Reuse oldest ip addresses

If all 250 addresses were taken then there should not be a random selection but a selection that knows which entry was taken earliest and reassign that, removing the old entry from the database/having a look if the IP is free.

Add ability to bind to a specific IP address

On some computers with multiple network interfaces, it would be nice to have a feature to have the server bind to a specific interface via an IP address.

DHCP offers not being accepted

I have this set up on a pi to which a laptop is connected. The pi has a wifi and a wired interface, and the wired interface is connected directly to a laptop.

The pi is running the python DHCP server, whilst the laptop is requesting an IP

I can see the DHCP discovery messages coming in from the laptop to the Pi, and the Pi responds with an offer

However, the offer is never accepted - there seems to be no REQUEST message sent in response by the laptop - so the logs on the pi show a continuous stream of "DHCPDISCOVER", "DHCPOFFER"

discover:
Message Type: 1
client MAC address: 00:0E:C6:CA:BC:35
client IP address: 0.0.0.0
your IP address: 0.0.0.0
next server IP address: 0.0.0.0
client identifier: 01:00:0E:C6:CA:BC
dhcp message type: DHCPDISCOVER
host name: ben-laptop
maximum dhcp message size: 576
parameter request list: [1, 2, 6, 12, 15, 26, 28, 121, 3, 33, 40, 41, 42, 119, 249, 252, 17]

new ip: 192.168.2.6
add 00:0E:C6:CA:BC:35 192.168.2.6 ben-laptop
broadcasting:
Message Type: 2
client MAC address: 00:0E:C6:CA:BC:35
client IP address: 0.0.0.0
your IP address: 192.168.2.6
next server IP address: 0.0.0.0
broadcast address: 255.255.255.255
client identifier: 00:0E:C6:CA:BC:35
dhcp message type: DHCPOFFER
ip address lease time: 300
subnet mask: 255.255.255.0

Running wireshark on the laptop - the one issuing the DISCOVER messages, I can see the DHCPOFFER, but it seems a REQUEST response is never sent

Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x2eb6bcda
Seconds elapsed: 0
Bootp flags: 0x0001 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.2.6
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: AsixElec_ca:bc:35 (00:0e:c6:ca:bc:35)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (1) Subnet Mask (255.255.255.0)
Length: 4
Subnet Mask: 255.255.255.0
Option: (28) Broadcast Address (192.168.2.255)
Length: 4
Broadcast Address: 192.168.2.255
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (300s) 5 minutes
Option: (53) DHCP Message Type (Offer)
Length: 1
DHCP: Offer (2)
Option: (61) Client identifier
Length: 6
Type: 0
Client Identifier: \016���5
Option: (255) End
Option End: 255

add configuration window

one should be able to replace the configuration using a menu.
Also, replace in the file if possible

Threading/Queue Issue

I have been running into the following error messages while running the DHCP server. I don't understand multithreating enough to know how to resolve the issue. Has anyone seen this issue before? It seems to happen the longer I leave the server running or how many devices I boot up at once.

Traceback (most recent call last):
File "C:\Users\user\Desktop\Python\SSH Tool\IOS PnP\dhcp.py", line 529, in run
self.update(1)
File "C:\Users\user\Desktop\Python\SSH Tool\IOS PnP\dhcp.py", line 448, in update
self.received(packet)
File "C:\Users\user\Desktop\Python\SSH Tool\IOS PnP\dhcp.py", line 455, in received
if not self.transactions[packet.transaction_id].receive(packet):
File "C:\Users\user\Desktop\Python\SSH Tool\IOS PnP\dhcp.py", line 167, in receive
self.received_dhcp_request, (packet,), )
File "C:\Users\user\Desktop\Python\SSH Tool\IOS PnP\dhcp.py", line 139, in do_after
self.queue.put((time.time() + seconds, func, args, kw))
known ip: 192.168.0.79
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\queue.py", line 143, in put
self._put(item)
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\queue.py", line 227, in _put
heappush(self.queue, item)
TypeError: '<' not supported between instances of 'method' and 'method'

Traceback (most recent call last):
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\threading.py", line 916, in _bootstrap_inner
self.run()
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "C:\Users\user\Desktop\Python\SSH Tool\IOS PnP\dhcp.py", line 131, in _delay_response_thread
p = self.queue.get(timeout=1)
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\queue.py", line 174, in get
item = self._get()
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\queue.py", line 230, in _get
return heappop(self.queue)
TypeError: '<' not supported between instances of 'method' and 'method'

Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\threading.py", line 916, in _bootstrap_inner
self.run()
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "C:\Users\user\Desktop\Python\SSH Tool\IOS PnP\dhcp.py", line 131, in _delay_response_thread
p = self.queue.get(timeout=2)
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\queue.py", line 174, in get
item = self._get()
File "C:\Users\user\AppData\Local\Programs\Python\Python36\lib\queue.py", line 230, in _get
return heappop(self.queue)
TypeError: '<' not supported between instances of 'method' and 'method'

DelayWorker keeping server alive

Hello,

I'm using your code to create a dhcp server but I'm running on a problem... It's been a while since you don't change this source code so I don't know if you are going to see this...

but the issue is the following, after creating the server object the DelayWorker is inited and generate a thread with a priority queue to run... but if I try to stop the server calling the .close command, setting the delayworker to closed is not releasing that thread, making the code "locked" on a state that it's only possible by sending and singint to the program (ctrl + c)

Do you have any idea how to fix this?

add slider

you should be able to scroll up and down and know that that is possible

allow 172.16. .... and 10. ... ip address ranges

the address ranges should be fully exploitable

Create a new release

It would be nice to release a new version now that #19 has been fixed.
Here is my suggestion:

• Add a changelog Section and #19 to it
• Tag a new release
• download the old release for Windows and update the files

Show assigned IP addresses even if no reply comes

Some DHCP clients take the IP address but they never tell
-> introduce an "Maybe" entry that shows that.

Client Identifier != mac

When the client_identifier gets parsed it seems to be one byte off.

The client identifier, which gets logged is 01:<mac_byte1>:<mac_byte2>:<mac_byte3>:<mac_byte4>:<mac_byte5>
This is the same value as in packet.named_options['client_identifier']. Also, while responding, the client identifier gets set from mac. This is not as defined in the standard