0

I have am testing a device on my network which has this lease assigned:

lease 192.168.110.85 {
  starts 3 2022/07/20 16:12:37;
  ends 3 2022/07/20 16:22:37;
  cltt 3 2022/07/20 16:12:37;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet a4:06:e9:10:95:64;
  uid "\001\244\006\351\020\225d";
}

The device is not functioning well on the production network. I am trying get any information I can.

But I cannot decode the UID "\001\244\006\351\020\225d".

According to the DHCP manual this should be a hex string, other sources state it is octal (which it isn't). If it is a hex string, how should I interpret the bytes?

The DHCP server is isc-dhcp running on a linux platform.

Johannes Linkels
  • 307
  • 1
  • 2
  • 7

1 Answers1

2

I don't know if it generally really makes sense to "decode" a UID value sent by a client, as the client may choose a UID that doesn't decode in any meaningful sense.

I do believe you are in luck, though, because the suggestion in the manual (see the uid section) seems to match what you have in your example:

uid client-identifier;

The uid statement records the client identifier used by the client to acquire the lease. Clients are not required to send client identifiers, and this statement only appears if the client did in fact send one. Client identifiers are normally an ARP type (1 for ethernet) followed by the MAC address, just like in the hardware statement, but this is not required.

The client identifier is recorded as a colon-separated hexadecimal list or as a quoted string. If it is recorded as a quoted string and it contains one or more non-printable characters, those characters are represented as octal escapes - a backslash character followed by three octal digits. The format used is determined by the lease-id-format parameter, which defaults to octal.

(emphasis added)

Looking at your value "\001\244\006\351\020\225d", it's clearly the quoted string variation of value, and most bytes are escaped.

input byte hexadecimal comment
\001 01 Ethernet
\244 A4
\006 06
\351 E9
\020 10
\225 95
d 64 (reference your favorite ascii table)

Which perfectly matches hardware ethernet a4:06:e9:10:95:64

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • I think I forgot how to convert octal to hex. And \225d put me on the wrong foot as well. – Johannes Linkels Jul 20 '22 at 18:42
  • I makes perfect sense. The MAC label on the case says 00:D0:12:xx:xx:xx. Which is plain incorrect. In my DHCP lease I see it is something different and the device even identifies itself again with this value. So the manufacturer is messing around – Johannes Linkels Jul 20 '22 at 18:45