everybody knows that Netgear Orbi sux badly (and if you don't know, please be informed). It sux so badly that you can't customize the DNS released by its DHCP server on your LAN (and many more nice missing features).
I didn't want to compromise, adding my Pi-hole device in the upstream DNS, nor I wanted to use my Pi-hole device as a DHCP server, because if it fails when I'm not home it could be a problem for the other family users.
This guy here, found a nice way to hack into the Netgear Orbi:
Using this knowledge, I successfully modified the udhcpd daemon configuration to release the DNS I want.
Before starting please be aware of the following:
This is a hack and as such, you can brick your router. I don't take any responsibility should you brick/destroy your router.
The hack takes advantage of a binary executed on boot that resides in a partition that is not overwritten during router startup. This binary (bdcrashd) is likely a daemon collecting crash dumps or dealing with crashes of the bitdefender integrated system. We take its place and we call it back from our script before running our custom hacks.
The hack resists on a reboot because we are using writable partitions not overwritten on reboot. I'm not sure if it resists a factory reset so we should assume that a firmware update will require the hack to be performed again. The reproducibility of this hack on other Netgear systems is linked to the underlying system used (OpenWRT), the partition layout and the presence of the bitdefender system, so I'm not sure it can be used on other devices.
Ok, let's have a look at the procedure! It has been tested on a Netgear Orbi RBK30 system, with firmware 2.3.5.34.
Enable telnet on the debug page:
http://router_ip/debug.htm
Connect through telnet and enter with root and the web interface admin password.
We will hack into the bitdefender system, proxying one of its binary executables:
$ cd /mnt/bitdefender/bin
$ mv bdcrashd bdcrashd.bin
$ touch bdcrashd
$ chmod 777 bdcrashd
$ vim bdcrashd
Paste the following content to the bdcrashd script:
#!/bin/sh
/tmp/mnt/bitdefender/bin/bdcrashd.bin $@ &
until [ -e /mnt/circle/localinit/00-null ]; do
sleep 2
done
find /mnt/circle/localinit/ -type f -exec sh -c "( {} & )" \;
Create our localinit directory that will contain our scripts and create the placeholder:
$ cd /mnt/circle/
$ mkdir localinit
$ cd localinit
$ touch 00-null
$ chmod 777 00-null
$ vim 00-null
Paste the following content into the 00-null placeholder:
#!/bin/sh
exit
We need to hack the udhcpd daemon, so we kill it and replace a line in its configuration file. We create our script first:
$ touch 01-fix_dhcp_dns
$ chmod 777 01-fix_dhcp_dns
$ vim 01-fix_dhcp_dns
Paste the following content to the 01-fix_dhcp_dns script and adjust the DNS variable to your liking:
#!/bin/sh
DNS="192.168.1.6 192.168.1.2"
until [ `pgrep udhcpd` ]; do
sleep 2
done
# From /etc/init.d/net-lan
killall udhcpd
sed -i "s/option dns .*/option dns $DNS/g" /tmp/udhcpd.conf
udhcpd /tmp/udhcpd.conf
exit
We can now restart the router issuing a reboot command. Congratulations.
Welcome to the Pi-hole community, and thank you for this approach to override local DHCP settings for a Netgear Orbi.
As we have quite a mix of users and visitors here, some of them may not have a very technical background.
Would you care to elaborate a bit on the risks involved?
Could you brick your router if you make an error while applying your steps?
Does factory- resetting your router stillI work then, or would user run into the danger of making the device unusable?
If so, an explicit warning would be appreciated.
Also, would you happen to know if this would also be applicable to other Netgear devices?
While this is cool and highly plausible from the looks of it (I have telnet access but my device does not rely on anything Bitdefender related), without actual knowledge of what is happening with the code and with the way the hijack works (if the user doesn't know) , I cannot recommend this procedure as this can render your firmware inoperable.
While there are ways that can restore the functionality, if one does not know what the code above does, one won't be able to do the even more advanced things to restore it.
I guess one can tftp restore it ...
I agree with your statement in bold, but it is currently running on my device, so I can confirm that it's 100% feasible. It's a hack by definition, so you need to compromise somewhere and there are obviously chances to break things, although most likely nothing that couldn't be solved by a factory reset.
Anyway, I just released it because it's a good piece of knowledge. Discussing how the firmware works or how to revert the procedure it's beyond my scope, so there's a disclaimer for this.
I agree. As I said, it does look like it works and it's a brilliant approach.
My warning was related indeed to the slight possibility of stuff going south, where maybe one pastes from a let's say windows notepad or who knows what and carries over encoding that will render the scripts inoperable...
Nothing to do with the code and implementation, but a warning of the increased possibility of something else going wrong (as with pretty much anything that one pokes at without knowing what it does).
I don't think a factory reset will do, as the factory reset only deletes the configuration file(s) stored in /home/
Yeah, /home that is a softlink to /tmp. You are probably right, the involved partitions mounted in /tmp/mnt/bitdefender and /tmp/mnt/circle will likely not be restored by a factory reset but by a firmware restore/upgrade.
Anyway, just for the sake of completeness, the overall procedure can be easily reverted with:
Guys, there's no need for all this.. all you have to do is simply set your WAN DNS to your internal Pihole address and it takes over from there.. Super simple. less risky.
