How i fix a bug in cnPilot routing (and asking your help to fix the same bug in ePMP1000 firmware)

On October 12, 2016 17:13 I've open a support ticket asking Cambium Networks to patch cnPilot's firmware to allow assing /32 address to it, the same issue affect also ePMP1000's firmware.

Following i transcript the ticket with the suggested solution that Cambium Networks accepted and implemented 

--- BEGIN ---

Hi, i'm in the need to use assign to cnPilot IP with a /32 netmask. IPs are assigned by a dhcp-server running on our
MikroTik core routers, there's no problem using linux or MikroTik clients. I've some R200 routers running 4.0-R2(201508071420): Product Information Hardware Version V1.3 Loader Version V3.05(Apr 29 2015 18:41:37) Firmware Version 4.0-R2(201508071420) and some upgraded to latest firmware version 4.2.3-R4(201606031245): Product Information Hardware Version V1.3 Loader Version V3.07(Aug 20 2015 17:38:07) Firmware Version
4.2.3-R4(201606031245) all of them are affected to these issue.

On 4.0-R2 fortunately there's a telnet daemon running so I was able to investigate the issue and solve it, on newer version seems that telnet was taken away and so i cannot do nothing (please reenable telnet daemon or better ssh daemon on cnPilot, I'll open a request or that). busybox's udhcpd has a bug (see and for a better explanation) prevent him to configure gateway if netmask is /32 (, adding 3 line on /sbin/ solve the issue (see at the end).

What i did

Connecting via telnet to cnPilot I discovered that manually adding gateway all work as expected:

# ip addr ls dev eth2.1
14: eth2.1@eth2: mtu 1500 qdisc noqueue state UP
link/ether 00:04:56:04:19:71 brd ff:ff:ff:ff:ff:ff
inet brd scope global eth2.1
inet6 fe80::204:56ff:fe04:1971/64 scope link
valid_lft forever preferred_lft forever

ip route ls dev br0 scope link

# is a router connected to the default gateway

traceroute -n

traceroute: can’t find interface

# Add default route manually

ip route add dev eth2.1

ip route add default via

ip route ls dev br0 scope link dev eth2.1 scope link default via dev eth2.1

traceroute -n

traceroute to (, 30 hops max, 38 byte packets
1 0.546 ms 0.321 ms 0.289 ms
2 0.755 ms 0.453 ms 0.384 ms

but trying to add route via web interface (Network -> Routing) (that’s the only way possible with newer firmware)
nothing happend, trying on a 4.0-R2 I can see that adding route via web interface (Network -> Routing) as following:

Web interface says that: Current Routing table in the system
No. Destination Mask Gateway Flags Metric Ref Use Interface Comment
1 0 0 0 0 INTERNET(eth2.1)
2 0 0 0 0 INTERNET(eth2.1)

all seems ok, but no traffic flow on wan, checking via telnet no route was added:

# ip route ls dev br0 scope link


I've copied /sbin/ in /tmp, edited it, just before:

echo "route add default gw $i dev $interface metric $metric"
route add default gw $i dev $interface metric $metric

i've added:

if [ "$NETMASK" == "netmask" ]; then
echo ip route add $i dev $interface
ip route add $i dev $interface

and manually launch udhcpd as:

# udhcpc -s /tmp/ -i eth2.1

solve the issue:

# ip route dev br0 scope link dev eth2.1 scope link 
default via dev eth2.1 metric 1

traceroute -n

traceroute to (, 30 hops max, 38 byte packets
1 0.477 ms 0.346 ms 0.290 ms
2 0.818 ms 0.498 ms 0.422 ms

so please release a firmware that configure routing to default gateway if netmask is /32 and reenable telnet or ssh access to cnPilot
— END —

Help request

Same very issue, surpresely, is also present on ePMP1000 and as reported from Cambium Networks' support also on  PMP450 and PMP650 equipments (I don't have a PMP* to check myself) and seems no one notice that before me.

On ePMP1000 ssh/telnet access is enable but it doesn't lauch busybox' shell so I cannot investigate like done for cnPilot and solve to myself the issue, but I'm pretty sure that it's not different from cnPilot one: it doesn't add route to default gateway on the device before adding route to resulting in error. Combium Networks ask me to share to you what I did to fix cnPilot's bug saying that if more people ask to fix the same issue on ePMP1000s they'll do it, so, please, help me asking to solve the issue!

Many thanks for your help, Micky


I follow this topic !

1 Like

I have forwarded this to our product team.

1 Like

More than 2 years passed. today I tried the 4.4.1 version but still the problem was not solved,  we need to be able to assign to clients /32 IP, please fix that bug, if you let me to see ePMP1000 filesystem I'll be more than happy to help you fixing the bug.

Thanks, Micky