Page 1 of 2
No effective login security with f/w 2.32d.dh14?
Posted: Thu Sep 10, 2015 3:08 pm
by gatekeeper
Since first acquiring and using my 8800NL, which was many months ago now, I've noticed that there's no official logging out required of the router's GUI, and I gather that this is now considered normal with the 8800NL and XL. However, I've recently experienced a spate of 8800NL misbehaviour that suggests that the non-logging-out policy has a serious security implication. I found that, within a constant browser session, it was possible to exit from the router but then get back in without having to log in!!!! Yes, if you quit from the browser and then re-open the browser, you're always forced to re-enter your password in order to log in to the router, but it seems to me that, otherwise, the router's GUI is effectively left open (even though you can't see it) and therefore all the time that you're visiting actual websites that GUI is potentially available to just about anyone with evil intent!
Incidentally, this is with firmware 2.32d.dh14. I've only ever had this login 'funny' show itself on the odd occasion but it seems to me that by Billion specifically not incorporating a proper logging out of the router a big security hole is left in its operation. Normal testing might not reveal this because the flaw shows itself only spuriously and infrequently - or at least that's what I'm finding with mine.
If not a risk from external factions, it's most certainly a risk from unauthorised colleagues or family members.
I can vaguely recall someone else complaining about this some months ago, but unfortunately I've not been able to find the topic here, and therefore determine whether or not it was eventually resolved. But it seems to me that if non-logging out is the policy across all 8800 series routers now, we users may be unwittingly being coaxed into thinking that merely leaving the GUI is sufficient to conserve its security. It clearly isn't.
Whether or not Billion has appreciated this massive flaw - which puts in an appearance only rarely - is unknown. Perhaps it was dealt with in later firmware? Indeed, I've wanted to update to firmware 2.32e but every time I peruse these pages about 2.32e I find that others complain about some other shortcoming.
Surely it's high time - if it hasn't been done already - that logging out should be incorporated?!
Re: No effective login security with f/w 2.32d.dh14?
Posted: Thu Sep 10, 2015 3:19 pm
by billion_fan
gatekeeper wrote:Since first acquiring and using my 8800NL, which was many months ago now, I've noticed that there's no official logging out required of the router's GUI, and I gather that this is now considered normal with the 8800NL and XL. However, I've recently experienced a spate of 8800NL misbehaviour that suggests that the non-logging-out policy has a serious security implication. I found that, within a constant browser session, it was possible to exit from the router but then get back in without having to log in!!!! Yes, if you quit from the browser and then re-open the browser, you're always forced to re-enter your password in order to log in to the router, but it seems to me that, otherwise, the router's GUI is effectively left open (even though you can't see it) and therefore all the time that you're visiting actual websites that GUI is potentially available to just about anyone with evil intent!
Incidentally, this is with firmware 2.32d.dh14. I've only ever had this login 'funny' show itself on the odd occasion but it seems to me that by Billion specifically not incorporating a proper logging out of the router a big security hole is left in its operation. Normal testing might not reveal this because the flaw shows itself only spuriously and infrequently - or at least that's what I'm finding with mine.
If not a risk from external factions, it's most certainly a risk from unauthorised colleagues or family members.
I can vaguely recall someone else complaining about this some months ago, but unfortunately I've not been able to find the topic here, and therefore determine whether or not it was eventually resolved. But it seems to me that if non-logging out is the policy across all 8800 series routers now, we users may be unwittingly being coaxed into thinking that merely leaving the GUI is sufficient to conserve its security. It clearly isn't.
Whether or not Billion has appreciated this massive flaw - which puts in an appearance only rarely - is unknown. Perhaps it was dealt with in later firmware? Indeed, I've wanted to update to firmware 2.32e but every time I peruse these pages about 2.32e I find that others complain about some other shortcoming.
Surely it's high time - if it hasn't been done already - that logging out should be incorporated?!
Email sent to our engineers, to add a logout function to our wishlist

(normally just closing the web browser including tabs should suffice, once you have finished making changes to the web gui)
Re: No effective login security with f/w 2.32d.dh14?
Posted: Thu Sep 10, 2015 4:07 pm
by gatekeeper
Billionfan,
Can you also tell me whether the 2.32d.dh14- or even the slightly newer firmware than that - gave inaccurate stats? I ask because it was while actually investigating Interleave Depth that I observed that merely exiting the GUI still effectively left it open. The Interleave Depth figures shown by the router simply don't agree with what my ISP is telling me that they've just set the line to. My ISP is saying that downstream depth has been set at 16, but my 8800 is showing 64. Similar incongruent figures for the upstream depth.
When on request the ISP changes the ID do they first need to reset the user's profile, or put the depth back to 1 (1=no interleaving)?
Re: No effective login security with f/w 2.32d.dh14?
Posted: Thu Sep 10, 2015 4:22 pm
by billion_fan
gatekeeper wrote:Billionfan,
Can you also tell me whether the 2.32d.dh14- or even the slightly newer firmware than that - gave inaccurate stats? I ask because it was while actually investigating Interleave Depth that I observed that merely exiting the GUI still effectively left it open. The Interleave Depth figures shown by the router simply don't agree with what my ISP is telling me that they've just set the line to. My ISP is saying that downstream depth has been set at 16, but my 8800 is showing 64. Similar incongruent figures for the upstream depth.
When on request the ISP changes the ID do they first need to reset the user's profile, or put the depth back to 1 (1=no interleaving)?
Not sure about how the ISP make changes (as all ISP's are different), as they don't normally tell us what they have done (normally I ask for a reset of the line profile, that normally sorts everything out) interval depth set to 8 or 16 means G.INP is enabled
Regarding the inaccurate stats, I haven't seen any known issues with 2.32d.dh14, but I have attached 2.32d.dh65 which should be fine (most people on this forum are running this firmware)
Re: No effective login security with f/w 2.32d.dh14?
Posted: Thu Sep 10, 2015 4:52 pm
by gatekeeper
Interval Depth? Eh? No, I was talking about Interleave Depth. As far as I'm aware, this is nothing to do with G.INP.
The Interleave Depth is the amount of 'bits-correction' (for want of a better description) performed within packets during the transmission of data between user and exchange, on ADSL. This assists with tolerance to burst noise. Many routers, the 8800 included, copy the Interleave level into their stats. The ID can be changed only via the ISP, though. Values for downstream ID can be 1 (no interleaving), 4, 8, 16, 32, and 64.
Re: No effective login security with f/w 2.32d.dh14?
Posted: Thu Sep 10, 2015 5:25 pm
by billion_fan
gatekeeper wrote:Interval Depth? Eh? No, I was talking about Interleave Depth. As far as I'm aware, this is nothing to do with G.INP.
The Interleave Depth is the amount of 'bits-correction' (for want of a better description) performed within packets during the transmission of data between user and exchange, on ADSL. This assists with tolerance to burst noise. Many routers, the 8800 included, copy the Interleave level into their stats. The ID can be changed only via the ISP, though. Values for downstream ID can be 1 (no interleaving), 4, 8, 16, 32, and 64.
What I was referring to was VDSL settings 8 or 16 with a IMP value of 48 meaning G.INP is enabled
Regarding fast path or interleave for ADSL, your ISP should be able to adjust this (If I remember correctly when I was with Be, I could do this without resetting the profile, obviously a resync will be needed to take effect)
Re: No effective login security with f/w 2.32d.dh14?
Posted: Thu Sep 10, 2015 5:44 pm
by gatekeeper
You mean a re-sync on MY part (as opposed to that of the ISP)?
Re: No effective login security with f/w 2.32d.dh14?
Posted: Fri Sep 11, 2015 9:20 am
by billion_fan
gatekeeper wrote:You mean a re-sync on MY part (as opposed to that of the ISP)?
I normally force a re-sync if the ISP has not done so (just to be sure)
Re: No effective login security with f/w 2.32d.dh14?
Posted: Fri Sep 11, 2015 5:17 pm
by gatekeeper
Yesterday I was given the runaround by my ISP, as they kept saying that they'd set some specific Interleave values for my line but, as I saw it, my router was telling me otherwise. I've no idea what really took place between my ISP and BT but by the end of the afternoon yesterday my profile had flipped and gone to a fixed 2M bps, ie. I had a stuck profile. I remonstrated with my ISP about it but my comments rather fell on deaf ears. However, today my ISP has declared that BT hadn't made the necessary changes after all. When my ISP then firmly submitted for the required 'unsticking' to be done, my line resumed normal operation.
The outcome of all of this was that my requirement for a degree of interleaving was simply not performed - because, it seems, nobody knew how to do it properly. Incidentally, I'm told by a usually reliable source that, in UK ADSL operations, BT may now be using new parameters for Interleave Depth. Instead of numbered values, the values may have been pared down to just three descriptions: Speed, Stable and Super Stable. (Off appears to still be an option too, off being 1). But ISPs, and even some BT engineers, apparently don't know the correspondence between them and the original numbered levels.
So, I'm fortunately 'back in business' again, but am disappointed that, for reasons best known to BT and my ISP, it wasn't possible to add a modicum of interleaving to my connection, to improve the error rate a little.
This might be something worth keeping in mind for those of you who dabble in tweaking. In particular, if interleaving is desirable or necessary and you contact your ISP to get it set to a suitable level, be cautious, as ISPs seem to be getting less and less knowledgeable, and you may end up as I did at one stage, operating at a much lower and stuck speed!
Re: No effective login security with f/w 2.32d.dh14?
Posted: Sat Sep 12, 2015 8:45 am
by nanotm
back when I had an adsl2 connection I found the only thing I could get was a banded profile with a target snrm and either interleaving on or off, granted that was about 3 years ago and some isp's have different offerings but in the main that was it regardless of isp, iirc the dslam sets the line policy so either you have fast path or you have interleaving, the rate (or depth) is managed by the exchange equipment automatically, personally I found it was better to have it fixed on fastpath and have a banded profile so regardless of the number of times some helpful employee disrupted the lines during visits to the exchange equipment each day it always reconnected at the exact same rate.
chances are bt have simplified their exchange profiles as part of the strategy to move everyone onto the newer generation connections (fibre) and reduce the running costs for the network /