
Category :
0
For any one following my illustrious
blog site I have to apologise as it has been up and down lately and is
causing me considerable headaches.
The root cause, apart from operator
error of course, has been my BT2700HGV router. I have a BT
Business account and BT broadband
has been very stable over the last few years and the router has not been
to bad either. The issue with the router is that it tries to be too intelligent
and makes assumptions and we all know about assumptions mother. The specific
issue is alias network addresses where you have one physical ethernet card
with multiple static address configured. The router can only (seem to)
associate one MAC address with one static address and this leads to very
interesting but complex scenarios. In addition multiple cards on one server
confuses the hell out of the router as well. All other routers I have had
previously simply use IP Addresses to do port forward and that works brilliantly.
Since BT upgraded to 6.1.1.48-enh it has been terrible. The issue seems
to be inconsistency in identifying devices accurately.
What happens is that you assign services
to an IP Address and the router then decides (assumption!) that it should
be on hostname x. When you restart hostname x the second ip address suddenly
but not always becomes the primary address and therefore port forwarding
is screwed. On Tuesday I reinstalled an old Red Hat 5 server with Ubuntu
9.04 and suddenly all port redirections where magically transferred and
thus no more web server or other services! Arghhhhhh is the best way to
describe this. I have been reading a few forums about this issue and was
about to go and buy a Draytek Vigor 2820Vn VOIP & Wireless ADSL/ADSL2+
Router but decided to take one last look at the issue. It seems that my
issue has been identified (kinda) by a few people on the Tripod forum -->
http://bt2700hgv.tripod.com/ir1002700HGV.htm#Using%20a%202700HGV%20as%20a%20wireless%20ethernet%20bridge/WAP
I have included an extract to remind
me of the issues. Simon suggested what seems like an easy fix and that
is to simply activate the OpenZone
feature. This does make sense
as the router will now have to check MAC and IP Addresses carefully as
only 13 users are allowed. If this works then my services will be back
to normal and if not I will be the proud owner of a new Vigor router even
though I know it will cause me support issues with BT but then I could
simple ask for my MAC
code and make like a tree and leave!
Here is an extract of what the forum
members said:
http://bt2700hgv.tripod.com/ir1002700HGV.htm#Using%20a%202700HGV%20as%20a%20wireless%20ethernet%20bridge/WAP
Inaccurate Local Network Devices
List
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.