Contents > BT v6.1 firmware:
(11 Nov 09): This thread and this thread on BT support forum confirm that v184.108.40.206 is available to BT business users continuing to experience specific VPN issues. The minor version number change suggests it is unlikely BT will have addressed all the issues identified to date.
(8 Mar 10): I've been using a dual SSID hub with v220.127.116.11, and I've witnessed this hub jumping from preconfigured channel 5 to channel 13 as described below. ie. the issue isn't confined to just BT v6 firmware.
Inaccurate Local Network Devices List
(Update 20 Nov 11): This bug can be resolved by also removing enhanced services (content screening, access controls, firewall monitor, link monitor). See here for Adrian C's static route hack.
(Update Oct 11): This bug has been fixed in BT v6.3.x firmwares.
This is a bug which has crept into the v6 firmware. If your working hub was upgraded from v5 to v6 by BT, then you probably will not encounter the issue. However, if you subsequently enable and disable OpenZone functionality, or have a need to perform a factory reset of your v6 hub, you will encounter the issue described below.
A number of readers (Simon, Ian, 'Vader') have witnessed the problem where the Local Network Devices List does not accurately display the exact status of ethernet and wireless devices connected to the hub. My view is it seems like the server process/daemon on the hub which discovers devices on the network and updates the v6 GUI is basically broken - it looks like it is purely cosmetic and hub Firewall and Access Control operations are not affected based on my own observations and tests.
When a brand new device (usually using DHCP) is introduced and connects to the hub for the very first time, the new device will appear as an 'active' device initially. Within a short period of time, the status will suddenly change to 'inactive' status (ie. greyed out). The hub also no longer displays the correct number of active and inactive devices too.
If the device is subsequently switched off and switched back on later, the hub continues to show the device as being 'inactive'. However, the device works perfectly normally through the hub.
Simon also reports if a device joins the Fusion wireless network, it is permanently displayed as 'active' even when the device is switched off.
If the device has a static IP address, it may not appear on the Local Network Devices List at all based on my own early observations of the problem.
Fortunately, as far as the Firewall is concerned, it is still possible to manage the devices regardless of the device's status. The hub maintains a separate database of ALL devices that have ever connected to it in the past and present. ie. a device may not be visible on the Local Network Devices List on the 'Home' page, but it is still visible in the Firewall and Access Control menus so can continue to be managed. (Warning: Using the 'Clear List' button in the Settings > LAN > Statistics menu or within the Resets menu will delete the devices database, and break all device associations defined in the Firewall and Access Control menus)
Unfortunately devices with static IP addresses do not show up in the the Firewall administration menus, but fortunately, you can create new rules for devices with static IP addresses to get around this problem.
For devices that appear to be 'inactive' (greyed out), I can confirm the firewall rules I have set up for said devices appear to function correctly.
However it is a different matter for Enhanced Services such as 'Content Screening' and 'Time of Day Access control'. DHCP-ed Devices can be managed just like with the Firewall, but unlike the Firewall, it is not possible to manage devices with static IP addresses as they are not visible, and you cannot define your own Access Control rules for static IP devices.
I can also confirm that Access Control rules continue to work for devices which are incorrectly reported as 'inactive' in the Local Network Devices List on the 'home' page.
How to fix it?
Thanks to Simon, he has observed if you enable OpenZone functionality, the Local Network Devices List suddenly starts behaving correctly. The Local Network Devices List will even be populated with devices configured with static IP addresses. (Warning: it can occasionally take up to a day or two to enable or disable Openzone in my own experience contrary to the 30 minutes maximum wait time which BT quote)
This is not an ideal solution at all given many hub owners will not want OpenZone hotspot functionality enabled, especially if you have usage allowances/caps.
Soft Reboot & Connect issue
While testing my own generic instructions for setting up a new ISP connection this morning, I could not for the life of me persuade my hub to reconnect to my ISP. Every time the hub came back up after I was prompted to perform a soft reboot via the hub's menus, it just would not connect. After the umpteenth soft reboot, I decided instead to pull the power cord out and plug it back in this time as opposed to performing a soft reboot via the Diagnostics Resets menu. The hub connected straight away upon startup.
OpenZone enabled by default after factory reset
If your hub was 'upgraded' from BT v5 to BT v6 firmware, the OpenZone capability is disabled by default. If however you factory reset the hub, OpenZone is Enabled by default.....
Simon kindly provided this screen dump from his wireless laptop connected to the OpenZone hotspot on his upgraded hub which is connected to his ISP, PlusNet. PlusNet is though owned by BT.
Was this a slip-up by BT by allowing the hotspot to be created ?
We think BT Openzone traffic is tunnelled through your ISP's network back to BT.
A past discussion on Thinkbroadband.com can be found here.
Up to 13 clients can connect, making use of up to 512kb of your broadband bandwidth. On non-BT Business broadband networks, this will affect users who have Usage allowances from their ISPs.
<== Click here for list of service providers which appear in the list box
I've deliberately tried to enable and disable OpenZone on my upgraded hub, which too connects to PlusNet. With my own hub, it can take anything between a few minutes to several days to enable or disable OpenZone. Once enabled, I am able to see the OpenZone login screen as shown above as first reported to me by Simon.
No uPnP Support
After reading a comment on the IDnetters sub-forum dedicated to the 2Wire 2700, it reminded me to report on our findings regarding whether the BT 'v18.104.22.168.1-enh.tm' firmware supports uPnP.
Contrary to earlier unconfirmed reports, we can find no evidence that uPnP is available on this release of firmware. There are no menu settings within the firmware to enable uPnP.
Simon performed a simple test of enabling 'uPnP' on his Sony PS3. The PS3 reported 'uPnP unavailable'.
I have conducted a simple test using uTorrent bittorrent client. I removed any port forwarding rules I had previously defined on the hub. Ensured that uPnP was enabled within uTorrent. While uTorrent is running, then opened a new browser session in IE and visited this URL to test the firewall.
where XXXX is the Port number defined in uTorrent client. The test failed.
Internet Connection Speed Monitor not working?
I notice the Internet Connection Speed Monitor accessed through Settings > Diagnostics > Link Monitor didn't seem to be reporting any activity when I am accessing the internet.
(24 Jun 09): It now transpires that you need to log into the hub for the Link Monitor to display activity. The easiest way of achieving this is to go to Settings > System Info > Password
Once the password has been correctly entered, try the Link Monitor page again and it should now display broadband activity.
Problems with VPN (Updated 11 Nov 09)
There is a thread on BT Business Support forum describing the problem with BT 'v22.214.171.124.enh-tm' firmware. The newer BT 'v126.96.36.199.1-enh.tm' firmware partially addresses the issue. BT v188.8.131.52 is also now available to BT business broadband customers on request. Click here for thread.
Problems with Content Screening with some 'upgraded' hubs
There is a thread on BT Business Support forum. Resetting the hub apparently will not fix the problem. I speculate the only solution is perhaps for BT to offer a replacement hub to the affected business customer.
Settings > Logs (Added 27 Jun 09)
I've observed it typically takes around 14 seconds between clicking on Settings > Logs and the page eventually appearing. 14 seconds feels like an eternity.... The v6 GUI does tend to feel a bit more sluggish than v4 or v5 firmware.
Settings > Broadband > Status page - Bytes Overflow (Added 8 Jul 09)
Ian B. has observed when the traffic count exceeds 7FFFFFFF (2147483647 decimal), the values shown on the Status page appears as a negative number and counts back down to zero. He says it is almost certainly because the software is displaying the value as if it was a signed, rather than an unsigned, 32 bit value. This didn't happen with version 5 firmware.
Spurious LAN Statistics (Added 13 Aug 09)
Ian B. also reports some spurious readings on the LAN Statistics page of his hub.
The packet count for Port 2 Transmit is way to high, and Ports 3 and 4 (with nothing connected) appear to send lots of packets without using any bytes.
Wireless channel number changing syndrome
(8 Mar 09): It had been a day and a half since I last rebooted my hub. I noticed this evening the wireless channel number being used by the hub is not what I had originally configured. The wireless setup menu clearly shows channel 5. The event logs also only show references to channel 5 too. But the Settings > LAN > Statistics page clearly shows I am on channel 13. Confirmed when I use netstumbler on my wireless laptop to scan all wireless networks in the vicinity.
I don't know when the wireless channel number changed, but looking through the event logs, I note there is an unexplained event around 10 hours earlier informing me the wireless channel had been set to channel 5. (The hub has been running for over a day and a half) I do recall I did clear the Devices List around that time.
I've not been able to reproduce the problem by clearing the Devices List.
(9 Mar 09): Simon reports this afternoon his hub suddenly changed its wireless channel from 6 to 13. He became aware of the change when one of his wireless devices appeared to stop working.
One further week later, there has been no repeat of this incident by either Simon or myself. If anyone else has witnessed a one-off wireless channel number change, please let me know.
(3 May 09): A reader wrote in on behalf of a BT Business broadband user, to advise that they had witnessed this changing channels issue very frequently. Every time they tried to set the hub to a low wifi channel number, after a few hours, the hub would decide to eventually jump back to channel 13. They were considering whether to perform a factory reset to see if it would address the problem. This was a particular problem for them as the hub was located in a small hotel and they had guests from the USA who's laptops can only operate on channels 1 to 11.
(3 Jul 09): I've been running my hub with BT v6.1.x firmware for about a week now. This morning, I noticed the wireless channel number was different to the one I had configured. The status page was showing Wireless Channel: 13 (5 (2432 MHz)) ie. configured to use channel 5, but hub is in fact using channel 13....!
Unfortunately I don't know when this change took place. It may have occurred earlier this week. As witnessed back in March when I last used this hub, there is no clue in the logs to suggest why this is happening.
(4 Jul 09): The wireless channel number changed again today. I know very early this morning, the channel number was still set to channel 5 from yesterday. The status page is now showing Wireless Channel: 13 (5 (2432 MHz)) once again.
Simon has previously commented his hub offers an 'Automatic' setting in the wireless channel selection list box. I do not see an 'Automatic' option on my hub.
(19 Jul 09): The wireless channel number changed again some time within the last 12 hours. Nothing stands out in the Systems Log to indicate why this is happening. I've now returned to using my other hub with BT v184.108.40.206 firmware.
(8 Mar 10): I've been using a dual SSID hub with v220.127.116.11, and I've witnessed this hub jumping from preconfigured channel 5 to channel 13!
(11 Jun 10): Also tried using the same dual SSID hub with v18.104.22.168 but configured to use channel 13 since Easter. On two occasions, the hub changed to a lower channel number. An interesting thread on the same subject.
'nodesd: Previous log entry repeated XXXXX times' issue
Perusing the idnetters forum, I came across a posting by 'Arctophile' describing an issue I have witnessed with my own hub running v6.x firmware. The System log is frequently populated with the following messages:
lmd: hostap2: couldn't sync config: No such file or directory
nodesd: unable to sync data: No such file or directory
nodesd: Previous log entry repeated XXXXXX times
Idnetter 'MisterW' offered up possible explanation for these error messages. Partially reproduced as follows:
lmd is 'Link Manager daemon'.
nodesd is 'Network device status daemon'.
I dont know what hostap2 is but hostapd is 'Wireless access point daemon' so my guess is that it could be something to do with the 2nd Wireless ap ( Fusion ). Do you have it enabled ?
'Arctophile' confirmed that both Openzone and Fusion services were disabled, but nevertheless, he re-enabled Fusion SSID and subsequently disabled it again. The above messages previously reported in the System log ceased.
Fwiw, I tried this solution of re-enabling and disabling Fusion services on my own hub running v22.214.171.124.1-enh.tm, but sadly it did not resolve the problem.
(Added 14 Mar 10):
'Arctophile' from the idNetters forum has made some observations regarding the 'hostap2' symptoms described above. He noted like myself that switching BT Fusion services Off and then back On didn't resolve the problem.
However, he did notice that after a variable period, of between two and three weeks of continuous connection, the error rate drops from about 1400 per minute to 8 per minute. He has not been able to identify what triggers this reduction. Despite the high error rate, it does not seem to affect performance.
He also posted the issue on BT business forum
(Added 30 Mar 11):
James P. has observed the following issues with his hub running v126.96.36.199.1-enh.tm. Reproduced below are his comments.
Issue 1 - WiFi Roaming
When wireless is enabled and there exists another AP on the network with the same SSID, WiFi clients will roam between the two APs in the normal way, i.e. maintain a link to the AP with the strongest signal.
When a device is initially connected to the 2700HGV AP and roams then to the secondary AP, this process works as expected.
However when a device roams back to the 2700HGV AP having been previously linked to the other AP, there is a 10 minute delay before any actual network throughput can be achieved, although the WiFi link itself is established fine.
I believe the cause is a bug in the firmware that fails to
invalidate the ARP cache entry for the device when it establishes a
link to the device via the AP. Therefore the existing ARP cache entry
(via a wired port to the secondary AP) remains in place until it
expires, after which it follows that connection can continue.
This issue occurs whether using two 2700HGVs or one 2700GHV and
another type of AP.
Issue 2 - Routes to Internal Networks Don't Work
(Update 3 Nov 11): James P. reports this bug has been fixed in v188.8.131.52-plus.tm running on his 2700HGV.
If there is a router on the internal network, say 192.168.1.250, to other networks, for example 192.168.2.0/24, a static route can be added to the HGV2700 for this via Settings/Broadband/Routing in the usual way. However, two entries are then created in the routing table:
The first, correct route right at the bottom;
A second, incorrect route somewhere above the loop-back route listing itself as the gateway.
The impact of this is that the HGV2700 attempts an ARP lookup for
a device on the second network, say 192.168.2.10, instead of sending
the packets to the gateway to that network, 192.168.1.250 in my
I contacted 2wire support about this issue but was unable to make any headway, instead being told repeatedly to use DHCP which of course is irrelevant.
(Added 30 Sep 11):
Web pages timing out. DNS problem
Redirected to this Troubleshooting page.
Previous Page: BT firmware v184.108.40.206.x information Next Page: Setting up the 2700HGV (BT v6.x firmware)
Use 'Back' button to return to previous page or click here to return to main menu