HenriWahl / dhcpy6d

MAC address aware DHCPv6 server written in Python
https://dhcpy6d.de
GNU General Public License v2.0
94 stars 27 forks source link

invalid literal for int() with base 16: '' #25

Closed FelixJacobi closed 4 years ago

FelixJacobi commented 4 years ago

I encountered this error repeatedly in the log of my dhcpy6d instance:

Nov 29 22:51:09 iserv.stsbl.de dhcpy6d[9183]: Traceback (most recent call last):
Nov 29 22:51:09 iserv.stsbl.de dhcpy6d[9183]:   File "/usr/sbin/dhcpy6d", line 1789, in handle
Nov 29 22:51:09 iserv.stsbl.de dhcpy6d[9183]:     Transactions[transaction_id] = Transaction(transaction_id, client_llip, interface, message_type, options)
Nov 29 22:51:09 iserv.stsbl.de dhcpy6d[9183]:   File "/usr/sbin/dhcpy6d", line 1485, in __init__
Nov 29 22:51:09 iserv.stsbl.de dhcpy6d[9183]:     self.DUIDType = int(options[1][0:4], 16)
Nov 29 22:51:09 iserv.stsbl.de dhcpy6d[9183]: ValueError: invalid literal for int() with base 16: ''
Nov 29 22:51:09 iserv.stsbl.de dhcpy6d[9183]: 2019-11-29 22:51:09,529 dhcpy6d ERROR handle(): invalid literal for int() with base 16: '' | Caused by: fe80::215:99ff:fee4:538f%br_lan | Transaction: de0666

I think that client is sending a bad DUID or something like that. If I should collect the exact value, please ping back and I will provide it as soon as possible. The client seems to be a Samsung printer, which possibly sends bad requests as already mentioned on the code position for HP printers...

HenriWahl commented 4 years ago

Yes, the reallife data would be a good source to find out what's happening.

FelixJacobi commented 4 years ago

Hi,

I patched a simple print on options[1]above the line in the trace given:

--- /usr/sbin/dhcpy6d   2018-10-25 14:30:00.000000000 +0200
+++ /root/dhcpy6d   2019-12-09 23:05:08.851545060 +0100
@@ -1482,6 +1482,7 @@
         # 1 Client Identifier Option
         if 1 in options:
             self.DUID = options[1]
+            print '"' + options[1] + '"'
             self.DUIDType = int(options[1][0:4], 16)
             # DUID-EN can be retrieved from DUID
             if self.DUIDType == 2:

It just seems that the dumb printer is just sending an empty DUID:

Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]: "000100011f85bdba0024210b41f6"
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]: "000100011de3a036b827eb31a8c6"
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]: "00010001225773477867d76c5b5b"
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]: "000100012189dfe608606ed5b81b"
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]: "00010001224f5f1c7867d76bea51"
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]: ""
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]: Traceback (most recent call last):
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]:   File "/usr/sbin/dhcpy6d", line 1790, in handle
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]:     Transactions[transaction_id] = Transaction(transaction_id, client_llip, interface, message_type, options)
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]:   File "/usr/sbin/dhcpy6d", line 1486, in __init__
Dez 09 23:02:25 iserv.stsbl.de dhcpy6d[14859]:     self.DUIDType = int(options[1][0:4], 16)
HenriWahl commented 4 years ago

Wow... would be interesting to see a capture in Wireshark to find out if the DUID was really empty or dhcpy6d did something stupid with the DUID. I am not very surprised that the DUID really might be empty... but can you post a small capture just to make sure?

HenriWahl commented 4 years ago

Fixed with 1.0.