User comments on ISPs
  >> Other Providers (without dedicated forums)


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | (show all)   Print Thread
Standard User alewis
(experienced) Thu 02-Mar-17 13:16:18
Print Post

BT modem on SSE


[link to this post]
 
As per a previous thread, I suspect my SSE-supplied TG589 router has been compromised. Due to the limitations of the GUI-only interface, its difficult to determine this, but the symptoms seem to point towards this:

Internet activity lights blinking like a bad 70's disco, even when all devices are inactive/off

2.4Ghz wireless enabled but not seen by any device including Insider and netstumbler (this network worked fine for the first few months).

Router shows the 2.4Ghz wifi enabled and with a strong 130mb data rate, no overlapping networks

5Ghz wireless network enabled, works, but only at 54-80MB, devices often lose connectivity/network drops out. Symptomatic of the router working at 100% peak load

Traffic stats show received data at 3.6TB (!), but transmitted data at 3.8 TERRABYTES. WTAF!!! We don't upload anything. We watch a fair bit of streamed video, well, the other half does, but thats from youtube and often at SD resolution. And there is no way that that would generate almost 4TB of ACK packets wink

I'm going to upgrade the firmware with that for the v2 router (its confirmed working), and if that doesn't solve it, a new router from SSE.

But, I'm more than tempted to replace the router with a modem and OPNSense firewall. Question is, which modem? Will the old BT Openreach VDSL Fibre modem work, and which is better, the Huawei or ECI model? ISTR that might depend on the cab, so fwiw my postcode is G20 9QS if anyoen is able to check the cab.

Am impressed with SSE fibre - 18months for £20/month inc line rental, free landline calls, solid 78/20 connection, no caps, no throttling, no issue. Just need to solve the niggles!

All help appreciated!

The views expressed here are mine alone, and do NOT reflect those of my employer, present or previous.
Administrator MrSaffron
(staff) Thu 02-Mar-17 14:25:31
Print Post

Re: BT modem on SSE


[re: alewis] [link to this post]
 
Huawei HG612 is best (cabinet matching is a bit of an old wives tales, the Huawei usually wins)

On next router, double check that no ports are visible on the WAN side, as routers get compromised usually via remote admin options, or a bit of malware running on a PC on the LAN side, so malware detection on PC will help there.

The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
Standard User David_W
(knowledge is power) Thu 02-Mar-17 14:37:50
Print Post

Re: BT modem on SSE


[re: alewis] [link to this post]
 
Assuming you have the correct credentials for your SSE account, OPNsense should work - though I have serious issues with Franco's attitude, also OPNsense have managed to ship some broken code in the past in supposedly stable releases (one stable release had broken VLANs, for example).

I would seriously suggest you consider going for pfSense instead; OPNsense is a fork of pfSense. As both OPNsense and pfSense are free to download and open source licensed, you could download both and see which you prefer.


Both the Openreach modems will work. If you have a jumbo capable NIC on your WAN interface, you can set MTU 1500 on the WAN interface and pfSense will use RFC 4638 (N.B. Intel NICs and possibly other brands only work with jumbo frames with a Gigabit link, so you might need to put a Gigabit switch between the WAN NIC and the modem). IPv6 should be supported if SSE are providing IPv6.



ZeN Unlimited Fibre 2 with native IPv6
thinkbroadband speed test : speedtest.net : thinkbroadband quality monitor IPv4 IPv6

Edited by David_W (Thu 02-Mar-17 14:39:57)


Register (or login) on our website and you will not see this ad.

Standard User alewis
(experienced) Thu 02-Mar-17 16:35:25
Print Post

Re: BT modem on SSE


[re: MrSaffron] [link to this post]
 
A huawei it is then, plenty on ebay.

WAN ports were locked down as soon as it came out of the box, as was the remote admin port. Double checked with ShieldsUP! and various other on-line tools, again re-checked again over the last few days.

If there is something internally, its going to be a PITA as nothing we have here detects anything... as far as I know, Panasonic TV/BD do not "phone home". But again, sticking a box between the LAN and the WAN will enable me to see just what is talking on the network.

Thanks!

The views expressed here are mine alone, and do NOT reflect those of my employer, present or previous.
Standard User alewis
(experienced) Thu 02-Mar-17 16:47:18
Print Post

Re: BT modem on SSE


[re: David_W] [link to this post]
 
Hello Dave, been almost ten years smile

In reply to a post by David_W:
Assuming you have the correct credentials for your SSE account, OPNsense should work - though I have serious issues with Franco's attitude, also OPNsense have managed to ship some broken code in the past in supposedly stable releases (one stable release had broken VLANs, for example).


SEE credentials are straightforwards, once one works out that which of the two provided passwords is for the broadband, and which is for something else.

Borked code, not good, especially when they claim code is tested - unlike PFSense!

I would seriously suggest you consider going for pfSense instead; OPNsense is a fork of pfSense. As both OPNsense and pfSense are free to download and open source licensed, you could download both and see which you prefer.


I've looked at both, and guessed it was pretty much horses for courses, OPS being a fork. Initially was going with PFSense for reasons not relevant here, but I was taken with the feature set in OPS, particularly its ability to use multi-cores. Whichever I use, it will be running on an old N40L microserver, which only has a dual-core AMD. I know its not the best hardware for the task, but on-board RAID and the 4 drivebays allow me to use some old SATA drives for caching and log-storage, it has two PCI-e slots so I can the additional NIC I need, and if necessary, a third.

Thanks again. BTW, are you still climbing in the Lakes? I moved back up there 5 years ago, then moved again last year... never seem to be able to stay there!

The views expressed here are mine alone, and do NOT reflect those of my employer, present or previous.
Administrator MrSaffron
(staff) Thu 02-Mar-17 20:31:18
Print Post

Re: BT modem on SSE


[re: alewis] [link to this post]
 
Could just be someone doing something that is chewing traffic constantly probing the router. You have tried turning off the Wi-Fi?

The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
Standard User connormill
(member) Thu 02-Mar-17 20:41:39
Print Post

Re: BT modem on SSE


[re: MrSaffron] [link to this post]
 
I'd go with the Huawei too.

I have a Huawei on my SSE line, using a Mikrotik RB2011 as my router and Ubiquiti UniFi AC Lite for wireless
Standard User alewis
(experienced) Fri 03-Mar-17 14:09:49
Print Post

Re: BT modem on SSE


[re: MrSaffron] [link to this post]
 
Have a couple more tests to complete before I take the nuke option, disabling wifi is one of them (as is adding a separate AP so SWMBO can still access her daily dose of daily politics when I do so)

But, longer term I want to add border management / firewall anyway; with the number of tablets, phones, watches, devices, etc it will be interesting to see what is 'phoning home' - I knew I was right to buy Panny and not Samsung TV, for example.

The views expressed here are mine alone, and do NOT reflect those of my employer, present or previous.
Standard User hypertony
(experienced) Fri 03-Mar-17 17:04:12
Print Post

Re: BT modem on SSE


[re: alewis] [link to this post]
 
In reply to a post by alewis:
A huawei it is then, plenty on ebay!


Don't be tempted to pay too much - max £20 should do it! I got mine for £19.99 BIN

- Tony Sutton
- Check out my Ford Focus ST170 site | View my Car's Dashcam Videos
Standard User Banger
(eat-sleep-adslguide) Fri 03-Mar-17 23:20:10
Print Post

Re: BT modem on SSE


[re: hypertony] [link to this post]
 
Got mine for £15. Still on the lookout for a spare but don't really want to pay more than £15-20. Some asking silly prices because they are unlocked.

Tim
www.xilo.net & freenetname
Billion 7800 on 24 Meg LLU
http://www.thinkbroadband.com/speedtest/results.html...
Standard User legume
(experienced) Sat 04-Mar-17 11:15:43
Print Post

Re: BT modem on SSE


[re: David_W] [link to this post]
 
In reply to a post by David_W:
Both the Openreach modems will work. If you have a jumbo capable NIC on your WAN interface, you can set MTU 1500 on the WAN interface and pfSense will use RFC 4638 (N.B. Intel NICs and possibly other brands only work with jumbo frames with a Gigabit link, so you might need to put a Gigabit switch between the WAN NIC and the modem). IPv6 should be supported if SSE are providing IPv6.


Your modem will eat any multicast, reducing upstream bandwidth if you don't isolate it from the LAN. Not so much of an issue if you don't have any bulk multicast around. If you were to have an ISP with a multicast TV product, there is a warning in the SINS that suggest isolating WAN/LAN with igmpproxy as some cabs have limited mac learning so there could be issues changing/channels starting streams if lots of devices are seen.

Saying that I currently use this setup as I am too stingy to get a second nic for my Linux router box.

I guess BSD is different from Linux for baby jumbos - my pppd won't try to use them unless the mtu on the nic associated with the pppoe is >= 1508. Easy if it it's a gig nic, may need hack for old nics. I used to use a 17 year old PIII box and managed to hack the driver so both onboard nic and a dual port ancient compaq PCI nic would work with 1508.
Standard User David_W
(knowledge is power) Sun 05-Mar-17 10:29:49
Print Post

Re: BT modem on SSE


[re: legume] [link to this post]
 
In reply to a post by legume:
In reply to a post by David_W:
Both the Openreach modems will work. If you have a jumbo capable NIC on your WAN interface, you can set MTU 1500 on the WAN interface and pfSense will use RFC 4638 (N.B. Intel NICs and possibly other brands only work with jumbo frames with a Gigabit link, so you might need to put a Gigabit switch between the WAN NIC and the modem). IPv6 should be supported if SSE are providing IPv6.
Your modem will eat any multicast, reducing upstream bandwidth if you don't isolate it from the LAN. Not so much of an issue if you don't have any bulk multicast around. If you were to have an ISP with a multicast TV product, there is a warning in the SINS that suggest isolating WAN/LAN with igmpproxy as some cabs have limited mac learning so there could be issues changing/channels starting streams if lots of devices are seen.
The link between the pfSense box and the VDSL2 bridge uses a dedicated VLAN in my system, completely isolating that traffic from the rest of the network. Moreover, my switches use IGMP (for IPv4) and MLD (for IPv6) snooping, so multicast traffic is only sent to the port(s) that have joined the relevant multicast group. This stops a lot of pointless multicast traffic being sent over Wi-Fi. I don't have multicast television anyway.

In reply to a post by legume:
I guess BSD is different from Linux for baby jumbos - my pppd won't try to use them unless the mtu on the nic associated with the pppoe is >= 1508. Easy if it it's a gig nic, may need hack for old nics. I used to use a 17 year old PIII box and managed to hack the driver so both onboard nic and a dual port ancient compaq PCI nic would work with 1508.
FreeBSD is exactly the same as Linux - you have to set the MTU of the parent interface of the PPPoE connection to at least 1508 (1500 plus 8 for the PPPoE overhead) before you can use a 1500 byte MTU for the PPPoE connection. However, pfSense handles this complexity automatically - I know, because I wrote the code!



ZeN Unlimited Fibre 2 with native IPv6
thinkbroadband speed test : speedtest.net : thinkbroadband quality monitor IPv4 IPv6
Standard User Zadeks
(experienced) Sun 05-Mar-17 11:03:18
Print Post

Re: BT modem on SSE


[re: alewis] [link to this post]
 
Sounds more like traffic is hitting your router from the WAN + borderline faulty router.

Over what period of time did it send and receive the data?
Standard User legume
(experienced) Sun 05-Mar-17 11:13:30
Print Post

Re: BT modem on SSE


[re: David_W] [link to this post]
 
In reply to a post by David_W:
In reply to a post by legume:
In reply to a post by David_W:
Both the Openreach modems will work. If you have a jumbo capable NIC on your WAN interface, you can set MTU 1500 on the WAN interface and pfSense will use RFC 4638 (N.B. Intel NICs and possibly other brands only work with jumbo frames with a Gigabit link, so you might need to put a Gigabit switch between the WAN NIC and the modem). IPv6 should be supported if SSE are providing IPv6.
Your modem will eat any multicast, reducing upstream bandwidth if you don't isolate it from the LAN. Not so much of an issue if you don't have any bulk multicast around. If you were to have an ISP with a multicast TV product, there is a warning in the SINS that suggest isolating WAN/LAN with igmpproxy as some cabs have limited mac learning so there could be issues changing/channels starting streams if lots of devices are seen.
The link between the pfSense box and the VDSL2 bridge uses a dedicated VLAN in my system, completely isolating that traffic from the rest of the network. Moreover, my switches use IGMP (for IPv4) and MLD (for IPv6) snooping, so multicast traffic is only sent to the port(s) that have joined the relevant multicast group. This stops a lot of pointless multicast traffic being sent over Wi-Fi. I don't have multicast television anyway.


Ahh, fair enough, you have a "proper" setup with a clever switch. The OP may have had a dumb switch so getting the "eats multicast" issue out was still worth while.

On not having multicast TV - I don't have it either. but my ISP = Plusnet do sell it. I don't know if that's relevant or if this applies to anyone with a BTW ISP. I can get multicast TV to hit the wan eg, this promo channel is unencrypted.

rtp://234.81.130.4:5802
In reply to a post by David_W:
In reply to a post by legume:
I guess BSD is different from Linux for baby jumbos - my pppd won't try to use them unless the mtu on the nic associated with the pppoe is >= 1508. Easy if it it's a gig nic, may need hack for old nics. I used to use a 17 year old PIII box and managed to hack the driver so both onboard nic and a dual port ancient compaq PCI nic would work with 1508.
FreeBSD is exactly the same as Linux - you have to set the MTU of the parent interface of the PPPoE connection to at least 1508 (1500 plus 8 for the PPPoE overhead) before you can use a 1500 byte MTU for the PPPoE connection. However, pfSense handles this complexity automatically - I know, because I wrote the code!


Nice. Strange Intel gig nics don't play - surely there's a hack just waiting to happen there. I don't have a gig intel so can't say what its like on Linux.

All three (100mbit) nics on my old setup used intel e100.c and the hack was surprisingly easy - just added 8 in a few places throughout the code. Of course it was just for me and I fully expected it may crash and burn - but it didn't.
Standard User David_W
(knowledge is power) Sun 05-Mar-17 12:54:50
Print Post

Re: BT modem on SSE


[re: alewis] [link to this post]
 
In reply to a post by alewis:
In reply to a post by David_W:
Assuming you have the correct credentials for your SSE account, OPNsense should work - though I have serious issues with Franco's attitude, also OPNsense have managed to ship some broken code in the past in supposedly stable releases (one stable release had broken VLANs, for example).
SEE credentials are straightforwards, once one works out that which of the two provided passwords is for the broadband, and which is for something else.
That helps considerably. I'm with Zen, who put the user name and password for PPP on your customer portal pages.

In reply to a post by alewis:
Borked code, not good, especially when they claim code is tested - unlike PFSense!
pfSense release engineering seems to be pretty good; the release process is pretty exhaustive, snapshot builds are made available leading up to a release, the bug tracker is open to the public, the main repository is on GitHub with sensible pull requests being welcomed and Netgate's in house testing seems to be pretty robust. Minor regressions are almost inevitable in a product like pfSense that interacts with such a wide range of external environments, but these tend to get addressed fairly quickly.

It helps that pfSense has been fairly extensively modernised in the past few years and a lot of technical debt eliminated. The distribution is now modular using FreeBSD's pkg package manager and is based on up-to-date components (pfSense 2.3.3 is based on FreeBSD 10.3, the upcoming pfSense 2.4 is based on FreeBSD 11.0 - in both cases using recent ports for external binaries). The horrendous old build system from pfSense 2.2 and early has been retired to great rejoicing from those like me who had the misfortune to have had to wrestle with it. The pfSense team have made some tough decisions to modernise the platform including replacing the GUI from pfSense 2.3 onwards and eliminating both i386 (32 bit) and NanoBSD builds (the build designed to run from a memory card) from pfSense 2.4 onwards. The ideal platform for pfSense 2.4 onwards is a 64 bit single board computer with a small SSD or a supported ARM board.


The architecture of both pfSense and OPNsense suffer from the original m0n0wall decision to use PHP without clear separation between the user interface and back end; you have code that responds to a web GUI submission by directly manipulating the internal configuration in a single security context. Best practice would be that any code running in the web server does not have that level of privilege over the system as a whole. Whilst there are ways that the internal security can and has been improved in both systems over the years, pfSense has not dealt with this issue and I don't believe OPNsense have completely eliminated it either, despite setting it as a project goal.

This sort of issue is typical of long-evolved code. After all, pfSense and OPNsense are very different today to the original m0n0wall releases, which had to run on much more constrained hardware than we have today. The best way to get away from this design flaw and the numerous other burdens of legacy code is total reimplementation. The pfSense core team have hinted at the possibility of pfSense 3 being a total reimplementation in Python using privilege separated user interface and back end; possibly using a RESTful API between the two.

In reply to a post by alewis:
In reply to a post by David_W:
I would seriously suggest you consider going for pfSense instead; OPNsense is a fork of pfSense. As both OPNsense and pfSense are free to download and open source licensed, you could download both and see which you prefer.
I've looked at both, and guessed it was pretty much horses for courses, OPS being a fork. Initially was going with PFSense for reasons not relevant here, but I was taken with the feature set in OPS, particularly its ability to use multi-cores. Whichever I use, it will be running on an old N40L microserver, which only has a dual-core AMD. I know its not the best hardware for the task, but on-board RAID and the 4 drivebays allow me to use some old SATA drives for caching and log-storage, it has two PCI-e slots so I can the additional NIC I need, and if necessary, a third.
The reason for the fork is significant - and I only have an outsider's imperfect understanding. I believe Deciso, the company behind OPNsense, used to be the European dealer for branded pfSense hardware. There was some sort of disagreement between Deciso and Netgate (the company behind pfSense), which led, in part, to Netgate asserting its rights to the pfSense trademarks in a much more robust way than it had done before, also to the build system for pfSense up to and including version 2.2 being moved to closed source with access available to those who signed a licence agreement. Deciso chose to fork OPNsense from the last open source version of pfSense and continue their business along their own track.

I may have some or all of that incorrect. Those who know the history will understandably not speak openly about it. It's "water under the bridge" anyway now. Current versions of pfSense Community Edition are fully open source again using the Apache 2.0 licence. The only restrictions are on the use of the pfSense trademark, which is understandable, as Netgate have to have ways of recovering the significant investment they continue to put into pfSense through commercial exploitation of the brand. Netgate have contributed quite a few improvements to the FreeBSD networking code, not least by working with some FreeBSD source contributors. Deciso do work with some FreeBSD contributors, but my impression is that their level of investment in FreeBSD is not at the same level as Netgate's. If you look at the commit log for the pf code in FreeBSD (which is a part of the operating system where pfSense and OPNsense developers have a particular interest), you will see much more work originating from and/or sponsored by the pfSense developers than the OPNsense developers.

OPNsense have chosen to go in a different direction to pfSense - for example, they chose a different GUI framework to pfSense. There seems little prospect of the forks ever coming back together and I don't believe OPNsense have made any attempt to ensure ongoing compatibility of pfSense configuration files with OPNsense.


I don't think there's any reason to expect OPNsense to perform significantly better on a dual core machine than pfSense does these days. I can't remember if OPNsense managed to ship a FreeBSD 10 based release before pfSense. FreeBSD 10 has significantly better pf performance on a multi core machine than earlier versions. pfSense got stuck on FreeBSD 8 for a long time as moving to FreeBSD 9 proved sub-optimal and once FreeBSD 10 was available, there was a lot of work required to produce a release. The OPNsense fork happened in the run-up to the release of pfSense 2.2, the first FreeBSD 10 based version.

I used pfSense before the fork and felt no reason to switch. I happen to get on pretty well with the pfSense developers and have contributed some code to pfSense, including support for RFC 4638 (PPPoE MTU greater than 1492) and some PPP and IPv6 related fixes. My involvement with Franco has been abrasive, as I noted in the FreeBSD bug relating to RFC 4638 support in mpd5 (the daemon used for PPP).

I don't make any money out of pfSense, nor have I ever contributed a penny to them. I run the free Community Edition on my personal router, which uses non-Netgate hardware (an old Dell server). Your N40L isn't a bad machine for pfSense - it has amd64 support, so if you choose pfSense, install the amd64 version now and you won't have any problems upgrading to pfSense 2.4 when it is released, likely at some point in the next few months. The only issue with using old server hardware is that it tends to be power hungry for the performance level offered; there comes a point where it's cheaper to replace older hardware with new, more energy efficient hardware.

In reply to a post by alewis:
Thanks again. BTW, are you still climbing in the Lakes? I moved back up there 5 years ago, then moved again last year... never seem to be able to stay there!
You must have mixed me up with someone else there. I wish I could go walking, but I've been a powerchair user since 1997 due to a neuromuscular condition. Nevertheless, I hope that whoever you mixed me up with is still enjoying the great outdoors, also that you get back to the Lakes sometime.



ZeN Unlimited Fibre 2 with native IPv6
thinkbroadband speed test : speedtest.net : thinkbroadband quality monitor IPv4 IPv6
Pages in this thread: 1 | 2 | (show all)   Print Thread

Jump to