dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-01-20T18:55:34Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/148OMSHELL Fails when using SHA512/256 as the option2022-01-20T18:55:34ZTim McLaughlinOMSHELL Fails when using SHA512/256 as the option---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I compiled the dhcpd 4.4.2 from source on the ISC website and then created a key using dnnsec-keygen, but I can not get omshell to work with a key b...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I compiled the dhcpd 4.4.2 from source on the ISC website and then created a key using dnnsec-keygen, but I can not get omshell to work with a key besides MD5. I have tired this on Redhat 7.9, and CENTOS 8.2 (server with a gui standard installation), but can not get the omshell to accept the configuration, in anything besides MD5, I tried SHA1, SHA256 and SHA512.
I generated keys using dnnsec-keygen, i.e. dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 512 -n USER myomapi_key.
The dhcpd was build using the following using --enable-paranoia --enable-debug.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcp (which daemon? dhcpd, dhcrelay, dhclient?) with the following config 'Using Systemd to run the dhcpd daemon with the following command: /usr/local/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -lf /var/lib/dhcpd/dhcpd.leases -user dhcpd -group dhcpd --no-pid'
2. I log into the omshell, manually (this will be scripted at a later point),
server localhost
port 7911
key-algorithm HMAC-SHA512
key myomapi_key "MYKEYGOESHERE...…"
connect
3. The server allows the connection
dhcpd[19236]: omapi_set_value (type, 13 20ce4fc)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (name, 8 20ce5cc)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (algorithm, 28 20ce6ec)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (op, 3)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (rid, 321157262)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (handle, 1)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (object, authenticator)
dhcpd[19236]: ==> success
4. I then attempt to make a new host using omshell
new host
set name= "Myhostname:
set hardware-address = MAC-ADDRESSS
set hardware-type = 1
set ip-address = 10.0.0.1
create
I then receive the following error:
omapi_set_value (op, 1)
==> success
omapi_set_value (object, dhcpctl-remote)
==> success
omapi_set_value (create, 1)
==> success
omapi_set_value (exclusive, 1)
==> success
omapi_set_value (type, host)
==> success
omapi_set_value (output-authenticator, authenticator)
==> invalid argument
can't open object: invalid argument
**Expected behavior**
The expected behavior is that the omshell command will create the host reservation in the dhcpd.leases file, the same commands work if I switch the key and key algorithm to MD5, just not any other HMAC type.
**Environment:**
- ISC DHCP version: dhcpd --version
isc-dhcpd-4.4.2
- OS: Red Hat Enterprise Linux Server release 7.9 (Maipo), and entOS Linux release 8.2.2004 (Core)
- Which features were compiled in: --enable-paranoia and --enable-debug
**Additional Information**
Config file is
omapi-port 7911;
key myomapi_key {
algorithm hmac-sha512;
secret "MYKEYWASMREMOVEDFROMHERE";
};
omapi-key xcat_key;
shared-network ens3 {
subnet 10.0.0.0 netmask 255.0.0.0 {
authoritative;
max-lease-time 43200;
min-lease-time 43200;
default-lease-time 43200;
option routers 10.0.0.1;
next-server 10.0.0.1;
option log-servers 10.0.0.1;
option ntp-servers 10.0.0.1;
option domain-name "tesbed.dom";
option domain-name-servers 8.8.8.8;
option interface-mtu 1500;
zone testbed.dom. {
primary 8.8.8.8; myomapi_key;
}
range dynamic-bootp 10.0.0.202 10.0.0.251;
} # 10.0.0.0/8 subnet_end
} # virbr1 nic_end
Make sure you anonymize your config files (at the very lease make sure you obfuscate your database
credentials, but you may also replace your actual IP addresses and host names with example.com
and 10.0.0.0/8 or 2001:db8::/32).
**Some initial questions**
- the feature was added in 4.4.2
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? No
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/167omshell returns inconsistent results or segfaults2022-05-10T08:29:46ZBill MacAllisteromshell returns inconsistent results or segfaults---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I have just built a Ubuntu 20.04 server and installed isc-dhcp-server
4.4.1 on it and I am seeing inconsistent returns from omshell.
Initially omsh...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I have just built a Ubuntu 20.04 server and installed isc-dhcp-server
4.4.1 on it and I am seeing inconsistent returns from omshell.
Initially omshell returns data as expected, but when I exit and re-enter
omshell connections fail.
**To Reproduce**
1. Two DHCP servers need to be configured as failover peers.
2. Issue the following commands using omshell
```
# omshell
> server localhost
> port 7911
> key omapi_key <the key>
> connect
Segmentation fault (core dumped)
```
Note, the connect works occasionally after a cold server restart, but
once the failure starts there is no recovery. The connect does not
always result is a segfault. Frequently the connect just hangs.
**Expected behavior**
This is a successful interaction from a version 4.3.5. server.
```
# omshell
> server localhost
> port 7911
> key omapi_key <the key>
> connect
obj: <null>
> new failover-state
obj: failover-state
> set name = "dhcp-failover"
obj: failover-state
name = "dhcp-failover"
> open
obj: failover-state
name = "dhcp-failover"
partner-address = c0:9d:e9:76:e9:55:00:00
partner-port = 00:00:02:07
local-address = 10:9d:e9:76:e9:55:00:00
local-port = 00:00:02:07
max-outstanding-updates = 00:00:00:0a
mclt = 00:00:01:2c
load-balance-max-secs = 00:00:00:03
load-balance-hba =
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
partner-state = 00:00:00:02
local-state = 00:00:00:02
partner-stos = 60:36:d0:68
local-stos = 60:36:8b:3b
hierarchy = 00:00:00:01
last-packet-sent = 00:00:00:00
last-timestamp-received = 00:00:00:00
skew = 00:00:00:00
max-response-delay = 00:00:00:3c
cur-unacked-updates = 00:00:00:00
```
**Environment:**
- ISC DHCP version: This failure happens with both the 4.4.1 build from Ubuntu and 4.4.2 built using ubuntu/debian packaging tools.
- OS: Ubuntu 20.04 (focal)
**Additional Information**
Our current test environment is failover peers, one running Ubuntu 18.04 with isc-dhcp 4.3.5 and one running Ubuntu 20.04 with isc-dhcp 4.4.2. From the 18.04 system the OMAPI failover connects are all successful and the DHCP servers on both systems appear to be working as expected.
**Some initial questions**
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
We have brought up the issued on the user lists and not gotten any response. I have also submitted a bug to Ubuntu without response. https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1916931
**Describe the solution you'd like**
I need to be able to determine the failover state of a DHCP server and to be able to set a server into failover when needed.
**Describe alternatives you've considered**
We have considered moving to the Kea server, but we have an infrastructure built around ISC DHCP LDAP backend functionality. Since that is a big enough change if we cannot get this working we will take a look at what DHCP servers are available in addition to the Kea server.
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs?
We would consider it, but it appears that ISC is not interested in developing ISC DHCP any further.
**Participating in development**
Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code?
Certainly
**Contacting you**
bill@ca-zephyr.org
#isc-dhcp IRC channel on freenode, my id is "iiibill"