DHCP listen port forwarding issue

All,
I’m setting up the network health binding using OH2.1 and network binding 2.2.

I went through the documentation and I have the binding working fine in that it will ping devices just fine but the DHCP listen functionality is giving me some issues. I added the port forwarding as is outlined in the documentation by doing the following:

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -p udp --dport 6767 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 67 -j REDIRECT --to-ports 6767

But when I look at the properties of my pingable devices my uses_dhcp_listen property shows “no” and the dhcp_state property says “No access right for port 67. Bound to port 6767 instead. Port forwarding necessary!”.

I checked my iptables and I get this in return:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -p udp -m udp --dport 6767 -j ACCEPT

and if I do a netstat | grep 67 I get:

udp6       0      0 :::6767                 :::*                                2744/java
unix  2      [ ACC ]     STREAM     LISTENING     19967    1/init              /run/snapd.socket
unix  2      [ ACC ]     STREAM     LISTENING     1674     1/init              /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     1678     1/init              /run/systemd/journal/stdout
unix  2      [ ]         DGRAM                    19167    1063/systemd        /run/user/108/systemd/notify
unix  3      [ ]         STREAM     CONNECTED     27867    1/init              /run/systemd/journal/stdout
unix  3      [ ]         STREAM     CONNECTED     22767    941/lightdm
unix  3      [ ]         STREAM     CONNECTED     23767    789/dbus-daemon     /var/run/dbus/system_bus_socket

Is there something I’m missing about getting the port forwarded correctly or is everything set up and I’m interpreting things incorrectly?

Thanks,
Matt

Facing the same issue here

I also can’t make the presence detection work using the DHCP listen function of the network binding.

I redirected also the port 67 to 6767 according to the official documentation (https://docs.openhab.org/addons/bindings/network/readme.html#dhcp-listen):

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -p udp --dport 6767 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 67 -j REDIRECT --to-ports 6767

I also test the correct functionality of the port forwarding by redirecting port 80 to 8080 (tcp). And if I check for IP packets that matches my redirection rule, it should work obviously:

iptables -t nat -L -v

Chain PREROUTING (policy ACCEPT 1781 packets, 218K bytes)
 pkts bytes target     prot opt in     out     source               destination
 1968  256K DEFAULT_PREROUTING  all  --  any    any     anywhere             anywhere

Chain INPUT (policy ACCEPT 896 packets, 179K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 323K packets, 19M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 323K packets, 19M bytes)
 pkts bytes target     prot opt in     out     source               destination
 873K   52M DEFAULT_POSTROUTING  all  --  any    any     anywhere             anywhere

Chain DEFAULT_POSTROUTING (1 references)
 pkts bytes target     prot opt in     out     source               destination
  100  8633 MASQUERADE  all  --  any    any     10.8.0.0/24          anywhere

Chain DEFAULT_PREROUTING (1 references)
 pkts bytes target     prot opt in     out     source               destination
   45 15498 REDIRECT   udp  --  any    any     anywhere             anywhere             udp dpt:bootps redir ports 6767
roo

Netstat says that a java process is listening on port 6767 as well:

netstat -tulpen | grep 6767

udp6       0      0 :::6767                 :::*                                1036      7881633      1544/java

But here I’m not sure whether it is correct that the process is using the IPv6 pendant of udp.

Furthermore there were no entries about incomming DHCP request in the Network Binding log. But the log says:

23:27:53.818 [INFO ] [nternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online

I tried the things above on openHAB version 2.2 and 2.3.

My openHAB instance is running on a Synology NAS (DSM 6.1.5-15254, also tried on 6.1.1), which was installed from the official spk (https://github.com/openhab/openhab-syno-spk). I could imagine that this is the reason.
Btw. the NAS is connected to a LEDE/OpenWrt router…

Can you tell us please, on what (operating) system your openHAB is running?

Does anyone have an idea what the problem is?

same for me…

I never did find a solution. I had attempted installing a LAMP stack on my system which I thought may have been causing issues but I never really dove into the problem, just kind of dealt with it. Then my system crashed and I had to wipe it and build from the ground up. Now DHCP listen works without any issues. So for me the format/reinstall fixed it. So I can’t point to a fix.

I run into the same problem today, setting up my presence detection. In the end I found out that it works perfectly with a slightly different iptables rule:

sudo iptables -I PREROUTING -t nat -p udp --src 0.0.0.0 --dport 67 -j DNAT --to 0.0.0.0:6767

Source:

Now I got presence instantly when my smartphone connects to the wifi.

3 Likes

Yeah I tried different iptables rules but my installation must have been messed up as none of the iptables rules I added would take effect. So that’s what led me to starting over.

It works for me with socat by re-broadcasting the DHCP udp packets received on ports 67 & 68 to port 6767 from another machine on the same lan.

sudo socat UDP4-LISTEN:67,fork UDP4-DATAGRAM:192.168.0.255:6767,broadcast
sudo socat UDP4-LISTEN:68,fork UDP4-DATAGRAM:192.168.0.255:6767,broadcast

You can test your DHCP service was not affected with nmap

sudo apt-get install nmap
sudo nmap --script broadcast-dhcp-discover -e eth0

You can see your DHCP packets on port 6767 arriving on the OH machine like this

sudo apt-get install tcpdump
sudo tcpdump -vvv -i eth0 port 6767

Notes

  • replace my lan broadcast address (192.168.0.255) with yours ( must end by .255 )
  • replace eth0 with the network interface used ( ifconfig to list them )
  • this is a linux solution ( raspberry pi debian )
1 Like

Port forwarding as described did not work for me.
Also the solutions with setcap don’t work (Java won’t work anymore).

But the solution with socat works! To make it autostart, I put the following in /etc/rc.local:

# DHCP-Listening Openhab
(socat UDP4-LISTEN:67,fork UDP4-DATAGRAM:192.168.0.255:6767,broadcast) &
(socat UDP4-LISTEN:68,fork UDP4-DATAGRAM:192.168.0.255:6767,broadcast) &
(socat UDP4-LISTEN:67,fork UDP6-DATAGRAM:192.168.0.255:6767,broadcast) &
(socat UDP4-LISTEN:68,fork UDP6-DATAGRAM:192.168.0.255:6767,broadcast) &

About the last 2 lines I’m not sure if they are necessary.
The property uses_dhcp_listen still shows no, but this is wrong, it’s working immediatly.

On my Debian system i just gave the openhab process the capability to bind to port 67 / privileged ports:

systemctl edit openhab2

[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE

3 Likes

Hi,
I am using openhabian and also set this capability.
Unfortunately, I am still getting “No access right for port 67…”
Also, the suggestion in the binding documentation does no longer work on recent systems:

sudo iptables -A INPUT -p udp --dport 6767 -j ACCEPT
iptables v1.8.2 (nf_tables): unknown option "--dport"

I think this is because it uses nf_tables now…
I also tried iptables-legacy but I get the same message…

sudo iptables-legacy -A INPUT -p udp --dport 6767 -j ACCEPT
iptables v1.8.2 (legacy): unknown option "--dport"

Maybe someone has a solution!

Hi, i don’t know if you’ve found a solution yet, but i was struggling with this a few days ago and got great advise from wolfgan in this thread Can't enable arping nor dhcp listening for Network binding

My problem turned out to be due to something else that a reboot solved, but check out xtables-translate for instance. However, i was not able to get the dhcp listening to work via the portforwarding, but hcp’s answer (providing openhab access to bind to lower ports) above solved it. Next thing is to get arping to work :grinning: