This page updated: 23-July-2013
BE's new network (which started to be rolled out in the summer of 2012) mandates the use of DHCP to obtain the router's IP address, and some members moved onto the new network have found problems with DHCP when using Netgear modem/routers. The most common problem is a brief network outage every 30 minutes whilst the DHCP lease is renewed (BE's new network issues leases which expire after 59 minutes, DHCP clients will attempt to renew the lease at "half time").
BE's old network also used DHCP for those customers with a dynamic
IP address, and there was a well-known problem with the DG834G v4 when
running the later DGTeam firmware versions - the DHCP client simply
failed to work at all, and no IP address could be obtained.
DGTeam was a group
of Italian enthusiasts who modified
Netgear's firmware for some of their modem/routers (mainly the DG834
family). The modified firmware added many useful features, notably the
ability to alter the target SNR margin for the ADSL link and
preserve this alteration over a power cycle. As a result, the DGTeam
firmware became quite popular. DGTeam appear to have disbanded some time
in early 2011.
This page provides modified firmwares which aim to address these problems. The modified firmware might be of interest to users of O2's broadband network with a dynamic address too.
Most of my modification work has been on the DGTeam firmwares for the older Netgear models. However Netgear's own firmware has the "30 minute brief outage" problem on a wide variety of models (the cause isn't something which DGTeam changed, and thus is present on models for which DGTeam never produced firmware). Thus modified firmware is needed for a larger number of Netgear modem/routers than I first imagined.
I suspect that the "DHCP client not working at all" problem can only exist in DGTeam firmwares with version numbers of 1012 and later - the DGTeam changelog shows that in 1012 they replaced the standalone udhcp code with later code incorporated into BusyBox, it's this change which I've partially reversed in these firmwares (I keep the later DHCP server code, but revert to the earlier DHCP client code).
I've also modified the DHCP client support scripts so that renewing the DHCP
lease doesn't reset the WAN uptime. This should make it possible to
see whether the lease is being renewed correctly, as the WAN uptime keeps
increasing if the lease is renewed. With the Netgear and original DGTeam
firmwares it's not possible to distinguish between the existing DHCP lease
being renewed and a new DHCP lease being obtained.
Having done this modification, I noticed in August 2012 that the
Connection Status page on the Netgear web interface didn't show the
correct Lease Expires time - it must use the WAN uptime as part of
its calculation, so it showed (on BE's new network) the lease expiry being
59 minutes after the DHCP lease was first obtained (i.e. it doesn't realise
the lease has been renewed). This gets fixed in version adsb_4, although
it needs quite a bit of work to sort out (e.g. needs a cross-compiler) -
so I'm rather tempted to forget about this modification, and just let the
WAN uptime get reset when the DHCP lease is renewed.
As of version adsb_3, I've modified the DHCP client support scripts so that renewing the DHCP lease doesn't cause the firewall to be restarted. This looked to me like the cause of the brief network outage every 30 minutes, and the reports I've received from users confirms that this change does fix that brief network outage.
These firmware modifications address mainly only DHCP client issues, and are therefore probably of no interest to users of other ISPs - especially if those ISPs don't use DHCP on the WAN interface to assign the user's WAN-side IP address.
In order to avoid making the firmware files too large, I remove the /usr/sbin/pppoe binary (it's about the same size as the replacement /usr/sbin/udhcpc binary). I don't believe BE members have a need for pppoe.
These firmwares are provided free of charge for BE members to try at their own risk. Whilst I take reasonable care to ensure that the firmwares will install OK onto the appropriate Netgear products and function as expected, there is no warranty provided. Neither Netgear nor DGTeam will support these firmwares. I will aim to provide "best effort" support.
I've put together some notes on testing the DHCP client.
Version adsb_4 is probably the one to use, but I've not yet built it for all models - use adsb_3 for the other models. I've received reports that adsb_3 fixes the network outage every 30 minutes on the new BE network.
| adsb_1 | I made a mistake in the syntax of the modified DHCP client support scripts, so this version doesn't work at all. |
|---|---|
| adsb_2 | First working version. Reverts to older DHCP client, DHCP lease renewal doesn't reset WAN uptime. This makes it possible to tell whether the DHCP lease is being renewed (rather than a new lease being obtained). |
| adsb_3 | DHCP client support scripts no longer cause the firewall to be restarted when the DHCP lease is renewed. If nothing else, restarting the firewall resets all the packet/byte counters in the firewall statistics. Restarting the firewall certainly looks to be the cause of the brief network outage. |
| adsb_4 | * DHCP client support scripts write the lease data to a
file, and the Connection Status web page now reads that file - shows when the
lease was first obtained, when it was renewed, and when it expires. The
scripts don't update the default route if it hasn't changed (since removing
and replacing the default route will cause a tiny WAN outage).
* Fixed some problems which caused the DHCP server (for the LAN) to forget all its leases. Added a /usr/sbin/dumpleases command to show the DHCP server's current leases. * In the web pages, renamed SPI Firewall to DoS Protection to more accurately indicate what it's about (Denial of Service Protection). * In the web pages, fixed a Javascript bug which caused valid MAC addresses to be rejected. Affected adding stations to the Wireless Access List and reserving IP addresses in the DHCP server. Some models reject any MAC address which doesn't start "00:", some other models reject any MAC address of the form x1:xx:xx:xx:xx:xx or 1x:xx:xx:xx:xx:xx. * Added a symlink /.ssh pointing at /etc/ssh (which is a writeable directory on the running router). This allows one to place an OpenSSH format authorized_keys file there in order to use public key authentication with ssh. I've automated installing the authorized_keys file and poisoning the password file so I have to use public key authentication to ssh to the router :-) With these modifications, I'm considering making the SSH port on the router visible from the Internet. Email me for details of automating installation of the key file and poisoning the password file. * Sundry spelling/grammar corrections in the English web pages - although where do I stop with this ? (DGTeam were Italians). |
I've been using my firmware images on my DG834GT since the morning of 9th
July 2012, and it's working fine. I have a static IP with BE, and my
exchange was upgraded on 16th August 2012. I've been using the new
network since the morning of 17th August 2012 - I received a DHCP lease
without problem, and it's being renewed OK. So I can report that
(at least for me) there's no DHCP client issue in my images.
DG834GT_DGTeam_1018_eng_adsldrv023o_adsb_2.zip
Based on DG834GT_V1.03.22_DGTeam_1018_eng_adsldrv023o.img
Since 24 August 2012 I've been using a new version (adsb_3) which doesn't
restart the firewall every time the DHCP client's lease is renewed. It
appears that Netgear's own firmwares and the original DGTeam firmwares all
do an internal restart when the DHCP client's lease is renewed, which I
think is the wrong thing to do. This fixes the brief WAN outage every
30 minutes:
DG834GT_DGTeam_1018_eng_adsldrv023o_adsb_3.zip
New for January 2013 is a version (adsb_4) which fixes a few minor
issues (see above):
DG834GT_DGTeam_1018_eng_adsldrv023o_adsb_4.zip
These models have the biggest problem with the later DGTeam firmware - the
DHCP client doesn't work at all, and so don't connect to the new
BE network. I don't have a DG834(G) v4, but I have created new images
for that model. I've received three reports from BE members that this
firmware is working OK for them on the new network, and further report from
another BE member that the firmware has fixed the previous DGTeam DHCP
client issue on the old network, but more reports are welcome - so if you
try it please let me know whether or not it works for you.
DG834G_V4_DGTeam_1018_eng_adsldrv023o_adsb_2.zip
Based on DG834GV4_V5.01.16_DGTeam_1018_all_adsldrv023o.img
In August 2012 I built a new version (adsb_3) which doesn't
restart the firewall every time the DHCP client's lease is renewed. It
appears that Netgear's own firmwares and the original DGTeam firmwares all
do an internal restart when the DHCP client's lease is renewed, which I
think is the wrong thing to do. This fixes the brief WAN outage every
30 minutes:
DG834G_V4_DGTeam_1018_eng_adsldrv023o_adsb_3.zip
New for January 2013 is a version (adsb_4) which fixes a few minor
issues (see above):
DG834G_V4_DGTeam_1018_eng_adsldrv023o_adsb_4.zip
I don't have a DG834PN, but I have created new images for that model.
I've received a couple of reports from BE members that this firmware is
working OK for them on the new network, but more reports are welcome.
DG834PN_DGTeam_1018_eng_adsldrv023o_adsb_2.zip
Based on DG834PN_V1.03.39_DGTeam_1018_eng_adsldrv023o.img
In August 2012 I built a new version (adsb_3) which doesn't
restart the firewall every time the DHCP client's lease is renewed. It
appears that Netgear's own firmwares and the original DGTeam firmwares all
do an internal restart when the DHCP client's lease is renewed, which I
think is the wrong thing to do. This fixes the brief WAN outage every
30 minutes:
DG834PN_DGTeam_1018_eng_adsldrv023o_adsb_3.zip
New for January 2013 is a version (adsb_4) which fixes a few minor
issues (see above, although the DG834PN doesn't have the "rejection of valid
MAC addresses" problem):
DG834PN_DGTeam_1018_eng_adsldrv023o_adsb_4.zip
I don't have a DGN2000, and I initially had a spot of bother with the DGN2000
because my tools to unpack the squashfs filesystem didn't work properly with
this model - the block size is different from that used in the DG834 models,
and large files get corrupted when being unpacked.
However BE member Lee Archard very kindly copied the large files
from his running DGN2000, so I now have what I believe to be a true copy of
the DGTeam filesystem.
I've tried rebuilding the DGTeam 1018 firmware for the DGN2000 (with no changes) but so far I've only produced a build which bricks the router :-( (fortunately the firmware recovery software unbricks it). If I manage to rebuild the DGTeam 1018 firmware, then I'll be able to build a modified version with my changes. If I succeed, it'll be based on DGN2000_V1.1.8.0_DGTeam_1018_eng_adsldrv023o.img
In the meantime, here's a workaround because the /etc directory on the
running router is writeable, and with the DGTeam firmware you can use the
"Custom Setup" web page to execute scripts automatically - so you can put
some code into the "ADSL (re)connection custom script" which gets run
automatically when the ADSL comes up. You can use this to replace the DHCP
client support scripts with modified versions from my web site.
In the Web UI of the DGN2000 running the DGTeam firmware, go to the
"Custom Setup" web page, and enter the following script with the
"Create/Edit Script" button under the "Enable router ADSL (re)connection
custom script execution" section:
cd /etc wget http://www.adsb.co.uk/software/DGTeam/scripts/DGN2000/udhcpc.script wget http://www.adsb.co.uk/software/DGTeam/scripts/DGN2000/udhcpc.fix.script chmod 755 udhcpc*.scriptNow check the tickbox for "Enable router ADSL (re)connection custom script execution", and from now on when the ADSL comes up the DHCP client support scripts will be updated. Of course, if you've done this modification while the ADSL is already up then you'll see no change: you'll have to telnet to the DGN2000 and enter the above commands manually (I know there's an "Execute Script" button, but I've not had much luck with it) - or reboot the router, or unplug the router from the phone line for a short while.
These models (the v1 and v2 take the same firmware) don't have later DGTeam
firmware available, and so don't suffer from the change of DHCP client
firmware. However they have the same DHCP support scripts, and so exhibit
the brief network outage - which this build fixes. As these models have
slower CPUs than later models, the brief network outage might be slightly
longer - and thus more noticeable.
DG834G_V2_DGTeam_0849_adsb_3.zip
Based on DG834V2_V3.01.31_DGTeam_0849.img
These models don't have later DGTeam firmware available, and so don't suffer
from the change of DHCP client firmware. However they have the same DHCP
support scripts, and so exhibit the brief network outage - which this build
fixes. As these models have slower CPUs than later models, the brief
network outage might be slightly longer - and thus more noticeable.
DG834G_V3_DGTeam_0849_adsb_3.zip
Based on DG834V3_V4.01.40_DGTeam_0849.img
Note that in this firmware the WAN uptime is still reset on DHCP lease
renewal - this means that the Connection Status web page shows the right
times for obtaining the lease and the lease expiring, but the WAN uptime
will never (seldom ?) go above 30 minutes.
I was asked to build a modified firmware for this model, but I've not
heard back from that user (oh, perhaps he no longer has a working router :-).
So I have candidate firmware but it's completely untested, so I won't
provide a link to it just yet.
Drop me an email if you have another Netgear model running DGTeam firmware or Netgear's firmware which has DHCP problems with BE. I ought to be able to do the same modification, provided the DGTeam .img file (if using DGTeam firmware) and the Netgear source are freely available.
If one has some Linux/Unix skills, and can telnet to the running Netgear, then there are a couple of quick and dirty fixes for the brief network outage problem. Neither are that great, as they won't survive a power cycle.
The brief network outage is caused because the DHCP client support scripts reset the firewall when the lease is renewed. These scripts are located in the /etc directory on the running router and this directory is writeable - so it's possible to modify the scripts to not reset the firewall. This is what I offer for the DGN2000 (see above). Unfortunately any modification won't survive a power cycle - unless one is running the DGTeam firmware (as that provides the ability to run custom scripts on certain events).
Another fix (which only works if you have a static IP with BE) is to configure the Netgear with a static IP address, netmask, default route, and DNS server(s) - and then run a "dummy" DHCP client on the Netgear to talk to BE's DHCP server. BE then think that you're using DHCP, although this "dummy" DHCP client doesn't configure anything on the Netgear and certainly doesn't reset the firewall. Unfortunately this doesn't survive a power cycle either (unless running the DGTeam firmware).
