Chances are that you have been suffering the same issue that i have, for more than a year now… and that has been driving me a bit mad!
I have had an issue for more than a year, that’s been driving me a bit mad…
This issue is that current versions of the AXIS WebOS user interface interact badly with Safari, such that Safari keeps popping up a login window over and over (and over and over). You can hit ‘cancel’ to dismiss the login box, but it keeps on coming back, and back and back. Its infuriating.
When I asked AXIS support for help, they didn’t (help) me at all. They just told me to use another browser (which works, but I don’t want to use another browser).
I have finally found the fix, and I wanted to write it down in case it helps others. I found the fix today on an AXIS web page, in reference to a specific camera and IOS, but it turns out that the fix works in general with all AXIS cameras and with Safari on MacOS X as well as on IOS. Yay!
To fix this issue on IOS:
To use AXIS OS web interface with iOS 15 or iPadOS 15, go to Settings > Safari > Advanced > Experimental Features and disable NSURLSession Websocket.
To fix this issue on MacOS X:
If the ‘Develop’ menu is not visible in Safari on the Mac, first make it appear by doing this:
Go to Safari > Preferences, click Advanced, then select “Show Develop menu in menu bar”
Now, turn off the same ‘Experimental Feature’ (NSURLSession Websocket) by finding it and un-checking it under the Develop > Experimental Features menu.
Subtitle: “Ubiquiti Auto-Optimise Breaks stuff again” (it is also responsible for this).
The Scenario
I have been having persistent, annoying and sustained issues with older Sonos devices dropping off of my WiFi network after a while. This is on a network driven entirely with Ubiquiti UniFI products (switches and access points connected to a UDM-Pro).
The older Sonos products would disappear regularly from view from the Sonos Apps.
Power cycle them and they return, but then any time from a few minutes to a few hours later… they’re gone again. Power cycle yet again. Rinse and Repeat. Grrr.
The Problem
The Ubiquiti ‘auto-optimize’ function strikes again – and breaks stuff. Hmmm.
The ‘optimize’ fuction modifies the minimum data rate for 2.4Ghz ‘beacon’ frames to a rate above the 802.11b default. Doing this breaks WiFi connectivity for devices that can only use 802.11b. The older Sonos models use 802.11b. So … this breaks them.
The Fix
(1) Turn off ‘auto-optimize’ (under Advanced settings in the Network settings page).
(2) Turn off the checkbox “2G Data Rate Control” on the Wireless Network page for your WiFi SSID concerned (see images below) to restore working 802.11b WiFi connectivity
The Details (if you need or want them)
I have Sonos One devices and (older) Sonos Play:5 devices. Its the Play:5’s that kept going away.
Importantly the older Sonos units are 2.4Ghz 802.11b only units devices… they can’t talk on 5Ghz (but the UniFi AP’s can bridge them to control devices running on newer devices and newer bands).
After a lot of head scratching, I realised that ‘something’ had changed a critical setting on my UDM-Pro.
The setting that was changed was the one (in the Wireless Network page) called “2G data rate control”.
This had been turned on (by the ‘auto optimizer’) and set to 5.5Mb/s minimum:
This is a minimum beacon rate that (as it says on the page) causes “Limited range and limited connectivity for 802.11b devices”
The older Sonos devices are 802.11b 2.4Ghz only devices! Hence this setting is guaranteed to break Sonos Network access – and to keep breaking it. Argh.
So: The fix is to set that minimum data rate back down to 1Mb/s, at which point the on-screen text changes to “Full Device Compatibility and Range”:
Fixed! Yay!
It is simpler (and more direct) to just disable the rate changing function entirely (by un-checking the box ‘Enable Minimum data rate control’.
However, I wanted to point out the changes in that explanatory text with the screen images above. These underscore that the optimiser (which is on by default) really does make changes that break older WiFi device access (and without warning the user that this is what will happen).
Note that on the UDM (vs the UDM-Pro), there are different checkboxes to restore 802.11b connectivity. On that platform, you (again) turn off the optimiser and then under your WiFi network configuration page you’ll find a switch hiding in the “Advanced” section “Enable Legacy Support”. This switch is explained with the text ‘Enable legacy device support (i.e. 11b)’. Duh. So turn that on (i.e. do enable the legacy device support).
I’m sure this is breaking connectivity for other devices too – there are going to be lots of little gadgets in people’s networks that are older or simpler and that only support 802.11b. If you want those to work… you’ll want to enable that legacy support.
Update: We have some wall mounted underfloor heating controllers (with WiFi) in the house… that were unreliable and just couldn’t hold a WiFi connection. You know where this is going … now they work just fine.
I’m writing this down in the hope that someone else trying to solve this issue via some random ‘Googling’ may find this article and that it may save them some time… compared to how long it took me to solve this!
I run a moderately sized UniFi based network consisting of a UDM-Pro, 10 UniFi switches on a fibre ring, and 19 UniFI Wireless LAN access points.
I turned on automatic software updates on the UDM-Pro a while ago, and I am presuming that the issue that has occurred here is as a result of the latest software that got auto-installed (UniFi UDM Pro Version 1.10.4 and ‘Network’ version 6.5.53).
It took me a few days to figure out that the UniFi network was the cause of broken printer operation and also the cause of our on-site Sonos audio devices all ceasing to work.
The way the ‘breakage’ occurs is subtle – some, but not all, peer to peer IP traffic over the wireless LAN was being silently dropped. Broken things included Multicast based protocols (such as AirPrint) and also initial connection establishment (with the ARP protocol’s broadcast frames apparently being filtered as well)
This impacted some network nodes but not to all of them.
The way this first manifested was that our printer stopped working. It didn’t work wireless-to-wireless, and it didn’t work when I tried cabling it into a switch and accessing it via wireless on my laptop.
The failure to work even on a wired connection convinced me the printer was just… b0rked, and that it was time to replace it.
In a similar timeframe, the Sonos audio devices in our house also stopped working. I didn’t initially register the timing coincidence with the printer fault because, frankly, Sonos network communication sometimes get flakey ‘all by itself’…and I had shelved that issue to figure out ‘later’.
In the meantime, we actually went and bought a new printer! When I fired that up, it failed to work as well (!). Ah hah… ‘lightbulb moment’. It wasn’t the printer. It was something far more fundamental about the network. It had to be.
I started digging deeper, with that new data point (that it wasn’t actually the printer at fault). Eventually, via various network diagnostic steps, I figured out that a strange network failure mode was the real issue.
Since it seemed to be impacting broadcast and multicast frames, I started looking for, and adjusting settings related to that functionality in the UDM-Pro.
Eventually I landed on the fix:
Turn OFF the ‘AUTO OPTIMIZE NETWORK’ setting under the Settings->Site menu. This is necessary in order to unlock the ability to change the next setting
Turn OFF the checkbox called “Block LAN to WLAN Multicast and Broadcast Traffic” on the Settings->Wireless Networks-> [ Your network name here ] -> EDIT WIRELESS NETWORK page
Turn this off to fix the fault
Ii is that latter setting that is doing the damage. When on, it is literally blocking things as fundamental as ARP broadcast packets so that IP connections can’t even be established reliably between hosts on the local network. Hosts can all talk to ‘the wider Internet’ just fine, but they can’t talk to each other.
I didn’t take any manual action to break the network – all I did was leave automatic OS updates turned on and a few days ago – these mysterious faults appeared.
See the screen shots below to help you find where those settings located on the UniFi Web console interface.
As soon as I took the steps above, the UDP-Pro re-provisioned all my UniFI WiFi access points and everything started working again – printer started working perfectly, Sonos started working fine. I proved this is the issue by turning the setting back on and – bingo – instant network faults. Off again…and it all works again.
I hope this helps someone else!
I’ve reported it to Ubiquiti because I think they need to urgently make a further update to fix this pretty fundamental bug, and hopefully they’ll indeed fix it.
In the meantime, I hope this post helps someone else avoid the head scratching (and/or throwing out perfectly good printers and/or Sonos units!).
This is where the ‘AUTO-OPTIMISE’ switch is (turn off to unlock the following setting change)Turn off the checkbox at the bottom of this screen to fix the WLAN network fault
Update-1:
12 Dec 2021: The ‘Network’ version has been incremented to 6.5.54 as at 12 December 2021.
Some good has been done in this incremental release: It has been kindly pointed out to me that a workaround is in there now for small sites, so at least small sites (less than 10 APs) won’t suffer this issue any longer.
The following comment has been added to the release notes for 6.5.54 (from here):
Enable multicast block if Auto-optimize is enabled, and there are more than 10 APs assigned to SSID.
My site does have more than 10 APs assigned to the SSID concerned. So, for me, 6.5.54 still shows the issue (which explains why, in my testing, the fault wasn’t fixed in 6.5.54).
This is a good thing – sites with less than 10 APs will now no longer see this bug.
However: The bug still exists and this workaround is just hiding it until it leaps out and bites sites in the tail when they expand to 10 or more APs (on the same SSID). Argh.
This feature (when enabled) is breaking fundamental aspects of TCP/IP network operation on a routine basis.
There are two issues here.
The first is that it is quite possible for two hosts to be associated to two different APs while being in the same physical location. Picture a printer on a desk and a user of that printer who has walked in from the AP next door (and is still associated with the AP next door).
Or picture a location that happens to just be at the intersection of two roughly equidistant APs (which is going to happen all the time on a network with more than 10 APs)
When this happens, the outcome for users in terms of Multicast/Broadcast activity is going to become intermittent – sometimes it’ll block packets, and sometimes (if host hosts do happen to both be on the same AP) it might work…for a while. And then stop again mysteriously later.
This intermittency was evident in my initial testing (and now I appreciate why).
As people make their networks larger (and of course for anyone who already was running a large network and who has auto-updated), they will see this mysterious problem happen both without warning and without explanation.
I actually think that’s worse… because now its a fault that unexpectedly occurs when the network expands beyond a certain point. Pity the IT guy who has to figure that one out, with the sole clue being that one line in the Network 6.5.54 release notes.
The signature example of the seriousness of this problem is something completely fundamental to working TCP/IP networks:
This feature blocks ARP packets
As a result, the establishment of working unicast connections between hosts in the local network (e.g. as fundamental as connecting to a printer and using it) will not work reliably (or in many cases, will not work at all)… which is where we came in.
It also means, for instance, that if you try to ‘ping’ another host on your local IP range, that ping might work, or it might not, depending on where the other host is, across your network (or on whether it has roamed to another AP that is reachable in the same physical location).
Debugging that sort of thing could drive people a bit crazy.
Without consideration of this, the functionality of the feature in general is pretty broken.
I get the point, and in implementing this, Ubiquiti means well, but it has not been fully thought out and it is going to be the cause of nasty (and worse, subtle) network faults on a continuing basis until more effort is put in to how this feature works (and to allowing the operator to select Broadcast and MultiCast packet types to continue to forward!).
I’ve noticed that when turned on, this feature allows for the addition of hosts by MAC address that are still able to be visible network wide:
You can add HOSTS to exclude from blocking but you can’t add PROTOCOLS (such as ARP) to exclude!
That is a tacit admission of how this feature breaks stuff.
Adding hosts to the exclude-from-blocking list by MAC address is well meaning, but network operators will be perpetually chasing their own tails as people add printers or audio devices (or replace busted ones). Maintaining a MAC address block list is just a ‘make work’ activity that no network administrator (or their users) needs. Not ever.
Ubiquiti has implemented extensive device ‘fingerprinting’ of devices over time. This meansthey can figure out what things are. If this feature is going to exist (and be silently turned on without warning!!) at all, then it has to be configurable in terms of device types and/or broadcast/multicast protocols that can be whitelisted, not hosts.
Again the issue here is that there are protocols (like ARP – argh) that you just can’t block between APs at all, without breaking fundamental aspects of how TCP/IP networks work.
This isn’t good, and until it is further improved, the underlying problem remains. The change in .54 does help a bit, for most people… but for the people it doesn’t help, it has made the real problem (that the feature itself is un-tenable as it stands) both harder to find (and hence harder to fix).
I’ve recently received my first SpaceX Starlink connection kit and fired it up in the wilds of Adelaide, South Australia. I’ve been figuring out how it all works and commencing some efforts toward a mid term project of deploying another Starlink service in a remote wilderness site in the future.
When I fired up my service, I had an initial issue wth it that really had me scratching my head, so I felt there was merit in documenting what happened and how to fix it.
Despite the warnings in the user documentation about potential issues if the cable length is extended, I had initially tested the service by sitting Dishy on the back lawn and plugging the (long!) ethernet/data cable into an RJ45 socket that I already had on the outside of my house (intended for an outdoor PoE WiFI access point). The other end of that RJ45 socket emerges on a patch panel in my study, where I plugged in the Starlink power brick and WiFi adaptor.
Dishy in the backyard on the lawn for initial testing
I tried that, and it worked really nicely. Immediate acquisition of signal and 300M/35M average speeds (!), with short term peak speeds above 400/40 (!!)… wow. I mean seriously… wow.
Having done that test, I got my friendly local sparky to install Dishy on the roof in a suitable location, and to run my ethernet cable into the roof space, and out into the study directly, as the permanent installation. I tried really hard to ‘do it right’, following the instructions about not cutting or extending the ethernet cable.
Dishy on the roof
When I plugged it all back together (no cable connections, using only the original cable run back into the power brick), the service didn’t work.
What I saw on the Starlink app was a fault indication… ‘Poor Ethernet Connection’
Starlink: Poor Ethernet Connection fault report
This fault showed up despite the connection being directly into the power brick, in accordance wth the instructions…
The Poor Ethernet Fault appeared despite no intermediate patching
Worse, the word ‘poor’ was an understatement.
Despite the Starlink App being able to see and control the dish, with Dishy visible in statistical terms on the app, there was in fact zero data flow.
No Internets For Me.
The physical connection from the RJ45 cable into the power brick was not 100% tight, but it didn’t seem terrible, and no amount of jiggling it made any difference to the total lack of service.
A visit from my sparky to re-check for the absence of any cable damage in the installation (and there was none) left us both scratching our heads, until I had one of those counter-intuitive ideas:
The service worked when I had an intermediate set of cable paths and patch points in the data path (and quite long ones). What if I put those back in?
Well, I did that – and – it worked perfectly again(!).
Ah hah.
So that very slightly loose RJ45 connection might just be the issue. Dishy (according to things I’d read online) uses PoE but needs a lot of power (90+ watts), and hence it would need a pretty much perfect RJ45 connection to make this work.
Next, i tried the smallest possible workaround to that slightly loose RJ45 connection on the original equipment…a very short patch lead and an RJ45 joiner:
How to fix a Starlink “Poor Ethernet Connection” – by adding an additional ethernet connection (!)
Bingo – perfect working connection, and it has kept working brilliantly ever since.
If I remove that little patch segment, it fails again. Oh well, it can stay there.
I hope this helps someone else with similar issues…!
This is a really easy fix, and hardly worth getting the hardware replaced by SpaceX when the self-service resolution is so simple, but it is somewhat counter-intuitive (given all the admonishment in the documentation against adding extra ethernet segments).
Update: I reported the issue to Starlink via the support path in the app. I got sent an example photo of what looks like a ‘known’ issue and got asked to check and photograph my own RJ45 plug and socket on the system.
This is what I found on my Dishy plug end when I looked hard at it (and took a careful photo):
Bent pin guide on Dishy’s RJ45 plug end
Well, that’s obviously ‘it’. That’s all it takes.
In response to my photo of that bent RJ45 connector pin, SpaceX are immediately forward-shipping me me an entire new Starlink kit and they have sent return instructions / vouchers for the existing kit.
Not withstanding that I could, in practice, just re-terminate the cable with a new plug, that’d likely void the warranty, so I am happy enough to swap the whole thing out for that reason (to keep the setup entirely ‘supported’).
I’ll have to get my sparky to pull the existing Dishy+cable and install the new one, when that new kit turns up, but – well – I can’t fault the customer service in this case. No arguments, just ‘have a new one’.
Interesting process, and interesting resolution. I wonder if they’ll send me a shiny new square dish this time?
If something is worth doing … it is worth overdoing 🙂
Last night I noticed that my suburb had been upgraded by NBNCo and that Aussie Broadband could now offer me a 1000 megabit per second Internet via NBN HFC at home (The previous NBNCo HFC ‘limit’ at my house was 250 Megabits per second).
Deeper, I was delighted to discover that the Aussie Broadband app allows you to implement a plan/speed change ‘in app’ and has the option to do it ‘right now’.
So I did it ‘right now’ – and – a minute or two later – this:
Wow. Thanks Very Much
Well strap my face to a pig and roll me in the mud…
…that is a really, really pleasant Internet speed to have at home 🙂
I’ve had gigabit fibre Internet at the office for years, but having it right in your house is pretty darn cool. Finally feel like we’re starting to catch up with some other countries.
I don’t think I expected it to take quite that long to get to my house, frankly – but – its here now.
That SpeedTest result is on a wired network port… on an 802.11ac wireless connection to an iMac in another room, I’m maxing out at a lazy 300 megabits or so right now. Finally my WiFi is the speed constraint, and nothing else is getting in the way. WiFi speeds fall off very sharply with distance, which is why I tend to put ethernet ports into any buildings I’m doing any sort of work on. You just can’t beat the speed of a wired connection.
The outcome (even via WiFi) is materially snappier compared to even the 250 Megabit per second service. Its like my office has been for years – click on something and (if it is well connected), then ‘blink’ and it has updated the page completely an instant.
The one bummer is that ‘mere’ 50 megabit per second upload speed – for which I still can’t quite countenance why NBNCo insist on that level of artificial throttling. Speed limiting just to make your ‘business’ products more valuable is the sort of evil tactic we used to complain about Telstra engaging in.
That said, 50 megabits per second upload is still ‘substantial’ and it is the increased upload seed that is actually the major factor in the above-mentioned improved ‘snappiness’ of updates. The extent to which upload speed is a real-world constraint to download performance is still a widely un-appreciated thing.
If this inspires you to move to Aussie Broadband as well, just remember you can type in the magic referral code 4549606 when you sign up, to save yourself (and me!) $50 in the process 🙂
The Ubiquiti UDM-Pro is a wonderful beast – everything you’d rationally want in a great, secure, high performance, feature-rich network router with a truly corporate grade feature set. In combination with Ubiquiti UniFI Switches and UniFI Access Points, the result is a capability to set up and run a network with something remarkably close to ‘the greatest of ease’.
The servers and services it makes available used to require days of head-scratching and a Unix command line. Instead, with this equipment, it takes a few hours and an iPhone App (for initial super-easy UDM-Pro configuration) and includes an excellent web interface (with secure remote access also available) for ongoing management.
For sites with lots of access points, it just doesn’t get easier than this – and the performance is excellent.
One thing I wanted to do with my (so far) two sites running this combination of equipment (UDM-Pro, UniFI switches and UniFI wireless Access Points) is to have a solid and seamless 4G 4G/LTE backup (Failover) path configured in and operating, for those times when the primary network connection is down.
Over time, I have cranked through quite a list of brands of both ethernet-to-4G gadgets, and (for a regional site I run), I had also cranked through lots of 4G diversity antennas, trying to find a good one.
In the hope of saving others the same expenditure of time, money, and experimentation, I am documenting the combination that is working (really well!) for me.
The barriers to a good experience in this regard are twofold. When it comes to a 4G-Ethernet ‘modem’, you need one that is fast, reliable, supports external diversity antennas, and (critically) supports ‘bridging’ of the 4G connection through to the ethernet port.
I’ve gone through a lot of (in hindsight) rubbish antennas before I found a good one, and I’ve also gone through a number of 4G/Ethernet routers that are either a bit rubbish and/or that insist on inserting their own layer 3 routing table into the data path, adding other /24 network range, more complexity, and becoming a barrier to direct end-to-end-access from the UDM-Pro to the 4G/LTE network provider.
The Parts List
Here are the devices that have worked (really well!) for me… after a trying a lot that did not work well or (in most cases) just did not work at all!
This model is available at Officeworks for A$249 (though I found you ‘had to ask’ – it was behind the front counter, not on the in-store shelving – perhaps because it is a relatively expensive and yet relatively small, hence steal-able box).
The unit has exactly what you need and nothing you don’t. There’s a LAN ethernet port (and a WAN one we don’t need to use for this application), and there is no WiFi (not needed, and just a distraction in practice to have it in there and to have to turn it off).
This unit takes a standard 4G/LTE SIM directly. This goes into little socket arrangement in the base of the unit is a touch non-obvious in terms of how to load and lock-in the SIM. That said, there is a little cardboard guide sheet stuck in the SIM slot to help you to work it out. You open the sliding cover, lay the SIM down on the pins in the box, close the cover and slide it up to lock it.
How to Insert a SIM into the LB 2120
I configured it at first with my Mac, using a USB-Ethernet dongle cabled directly to the unit with a (supplied) patch lead.
In terms of configuration: With a Telstra SIM installed, it was 100% instant plug-and-play, coming up initially on 192.168.5.1 and logged in using the password printed on the back of the box.
I did a firmware update (on general principles) – downloading via the LTE network to do it.
Then I simply switched the unit from router mode to ‘bridge’ mode. This is the key to a very simple life!
After rebooting into Bridge mode, the unit came up on my Mac with the Telstra 4G IP address attached directly to my Mac, fully automatically – exactly what I wanted to see. Zero configuration, and 192.168.x.x network is gone (so it is not, in any sense, ‘in the way’).
Ubiquiti SFP Ethernet Transceiver Module (for the WAN2 port)
When connecting the UDM-Pro to an Internet link, the primary port (designated “WAN(1)” must to be physical port #9. It cannot be any other port on the device (at least, not without behind-the-scenes internal configuration hackery I didn’t want or need to undertake).
Port 9 is a Gig-E port, so that is easily used to connect to (in my case) an Aussie Broadband NBN based Internet service.
In one site, I’m using an Aussie Broadband HFC connection which is direct plug-and-play – literally plug in a patch lead between port 9 on the UDM-Pro and the back of the Arris HFC modem supplied by NBNCo, and the Internet link ‘just works’… zero setup, zero complication. Just instant Internet. Win!
The WAN2 port (failover) port on the UDM-Pro is also a locked-in thing – it has to be Port 10.
As it happens, Port 10 is an SFP socket, not a Gig-E port.
What you need to buy to deal with that is a “Ubiquiti RJ45 – SFP Transceiver Module , SFP to RJ45 1G”
This module, available for $27 from Wireless4Now, plugs into the SFP socket on the UDM-Pro and turns that SFP socket into a standard RJ45 Gig-E port.
High Performance Outdoor 4G / LTE MIMO Antenna Set (optional)
In one site, in a city location, no external 4G antenna was needed with the LB2120 for entirely acceptable performance (30 megabits per second plus – entirely good enough for a failover link!)
In another (regional) site I’ve deployed this equipment into, however, the 4G tower site is several kilometres away (and the networking gear is in an outdoor metal cabinet). There is good line of sight, but at this sort of distance a simple omni-directional antenna doesn’t cut the mustard to get decent performance – its time to bring out the big guns.
After many false starts, I have found a specific antenna and cable combination that rocks. It is not cheap, but… boy does it work. It took my 4G site performance from 1 bar to 5 bars. It took the real world performance up from around 8-10 megabits per second into the 60-70 Megabit per second range (!).
4G MIMO Antenna
4G MIMO Antenna
The antenna kit that did the trick for me is a properly aligned (2 x 45 degree offset) pair of serious Yagi antennas, a suitable mount to achieve that alignment, a backhaul cable, and a 2 x TS9 adaptor tail set to suit the NetGear LB 2120’s on-board TS-9 sockets.
This setup is not cheap – running to a bit more than $600, from RFShop in Adelaide.
It is, however, absolutely worth it if you want to maximise your regional link performance, and the outcome, for me, was a dramatic improvement. This was achieved after multiple attempts with less ‘serious’ antenna sets (that either did nothing for me, or in some cases actually made the performance substantially worse)
The one other item that was helpful in mounting that Yagi combination (which is quite heavy) was a short ‘TV’ antenna mounting bracket, that turned out to be perfect for the job, for another A$27 from Bunnings Aerospace 🙂
Configuration
Configuration of the failover path was trivial – due to using equipment that ‘just works’ 🙂
Indeed, it was totally plug-and-play. I just inserted the SFP module, plugged the Netgear device in (after first testing on my Mac as noted above), and that was it.
On the UniFI web interface, I selected the UDM-Pro and checked the characteristics for WAN2… bingo, already up and running!
Testing?
That is as simple as unplugging the primary (NBN) cable, observing that the Internet keeps right on going, and doing some speed tests to compare-and-contrast. When done, plug the NBN cable back in.
While nothing special in some other countries (like… New Zealand… let alone the USA), a better-than-100-Megabit Internet service at home has been an unattainable goal for me in the wilds of Adelaide, South Australia until now.
I have long had access to much faster speeds at the office, via path diverse gigabit fibre links that were installed back when I owned an Internet company, but not at home.
The companies who are giving the NBN a run for their money using fixed wireless services couldn’t help me, because I live in one of those leafy streets full of those tall things that leaves grow on. Our house has no radio line-of-sight to anywhere and no way to ‘fix’ that without the use of chainsaws. Not doing that.
At least, that’s how I felt about it before I’d done it.
I have since found that there are some genuine benefits beyond mere geek bragging rights.
Our home is in the HFC network footprint. Back in December 2013 (!) I penned a blog post about how HFC (while definitely not as good as pure fibre) was still capable of speeds well over 100 Megabits per second, and definitely a dramatic improvement over (sigh) FTTN.
I don’t think I was expecting it to be a seven year wait (!) but at last, here in 2020, I have finally got there, via the very same HFC box pictured in that 2013 blog post.
To my great chagrin, I’ve not been able to obtain those > 100 Meg speeds with the ISP I founded, Internode. It seems that Internode is a prisoner of the the TPG group’s apparent disinterest in keeping up with state-of-the-art NBN home Internet speeds.
The TPG group have ignored higher speed options on fixed-wireless for more than two years so far (and yes, I have asked – repeatedly), so I have little optimism for the group to return to the forefront in fixed line speeds on the NBN in general any time soon.
Time to change providers. This was a decision I was sad about because, well, I did start Internode!
The changeover process on the NBN fixed line network is incredibly smooth and simple – such a contrast to the complicated realm that Internode and others had to navigate when it came to switching between ADSL2+ DSLAM networks.
Online signup took just a few minutes. A little later the same day I got an SMS to say that I had a 250 Megabit Internet service running with Aussie Broadband.
There was no physical change to anything. I simply got an SMS message to say it was done, and without even resetting or logging into the router, the world got…faster.
In fact, I was a bit shocked at how fast it was:
Over-achieving on a ‘250’ megabit Aussie Broadband service
I’m used to real-world download speeds being lower than the ‘advertised’ line rate, because that advertised raw data rate typically includes TCP/IP packet overheads. By contrast, this service is achieving noticeably more than the advertised speed(!).
It is also amazingly consistent. At 8pm I tried again and instead of a 274 megabit per second speedtest result, I managed a ‘mere’ 273 Megabits per second. Indeed I am yet to see a speedtest result below 250.
“Nice upstream speed, kid…gonna miss it after the upgrade?”
One thing I am a bit sad about, and it is not Aussie Broadband’s fault, is the NBNCo decision to speed constrain the upstream direction on the NBN ‘250’ services to a mere 25 megabits per second. The NBNCo 100M service has a 40M upstream, and the loss of that faster upstream (and that’s what I used to have) real does peeve me a bit.
In my view, constraining the upload speed artificially is akin to a gangster charging ‘protection money’. This level of asymmetry (10:1) is a bit unreasonable when all of the underlying backhaul/CVC/etc links are full duplex (i.e. same-speed-both-ways) data paths, so the upstream pipes are mostly full of ‘air’. At the same ratio as the 100M NBNCo service, there really should be a 100M uplink speed on this service.
Anyway – it is what it is, and in this regard I am merely a paying customer.
(My Aussie Broadband Refer-A-Friend Code is 4549606 if you feel like doing the same thing and if you’d like a $50 credit when you sign up 🙂 )
Does it matter – can you tell the difference?
It turns out that you can.
Web browsing of even content-rich sites is now visibly ‘snappier’, which isn’t earth-shattering, but it is very nice.
It is (of course) in the downloading of large chunks of data that the speed difference really comes to the fore.
I found myself downloading the latest Mac OS X release, Catalina, that weighs in at around 12.5 Gigabytes (!). I hit the ‘Download’ button on the Mac App Store and went off to make a cup of coffee, being used to this sort of thing taking a fair old while, even on a 100M link.
I came back to the Mac a little over 5 minutes later and it was fully downloaded and waiting for me to hit the ‘start’ button to do the upgrade. I had to get the calculator out to decide if that was even possible…and it is. The speeds I am achieving equate to more than 2 Gigabytes per minute of achieved payload data rate. Mercy Sakes that is quick.
Another few hundred gigabytes of Dropbox folders needed to be synchronised over the Internet link into that same Mac. Sure, that took a few hours, but again it was way faster than it had ever happened before. A few hundred gigabytes.
Overall – I’m really loving this.
There is just no sense of conflict in usage by different household members, even when a few household members are are streaming high bandwidth 4K HDR content at the same time (and…they really do).
Even while that Mac was chugging away in a corner, re-synchronising hundreds of Gigabytes of Dropbox folders onto its onboard SSD, the Internet service remained just lightning-fast for everyday tasks.
The Weakest Link
Back in the ADSL2+ days at Internode, we would often have to chase down apparent Internet link speed issues that really turned out to be local (in-house) issues with WiFi base stations or other in-house network issues – even at a mere 10-20 megabits per second. The state of the art in routers and wifi at the time was a lot worse than it is today.
By contrast, the 270 megabit per second down speed test results I am consistently obtaining with my shiny new Aussie Broadband service are being achieved to a laptop over WiFi on the kitchen table – not even using a wired network port (!).
I have tried again on a wired port, just to see if it was different and it was exactly the same. Somewhere between my glass-half-full blog post about HFC in 2013 and now, the rest of the home network technology concerned has comprehensively ‘caught up’.
For interest, the on-site data path is:
A Ubiquiti EdgeRouter-X. This router is more than up to the speed task, rock solid and reliable, has automatic backup link failover, and the 5 port model I have at home comes in at under A$90. Incredible. This is a disruptive, excellent value device that is worthy of a separate review in its own right.
An old TP-Link rack-mount gigabit switch.
Multiple trusty Apple Airport Extreme base stations spread around the house, all connected on wired ethernet back to the central switch. Also well up to the task, but Apple don’t make ’em any more.
My (now) 3.5 year old MacBook Pro.
I’m intending to swap it all that out in a little while for a new set of Ubiquiti ‘UniFi’ series hardware (UDM-Pro, UniFi PoE switches and UniFi PoE Wireless Access Points).
I do not expect that change to create a speed gain. However, I deployed that full product set on our farm recently across a six site single mode fibre ring and – wow. That product set achieves everything on a complex site that used to take days of head-scratching with a Unix command line, and it turns it all into 10 minutes of point-and-click with a web browser. Again well deserving of a separate review sometime.
Conclusion
I am just loving the new 250 Megabit per second Internet service at home. Having spent most of my business career involved in the engineering of local, national and international many-gigabit-per-second networks, its nice to have something at home that – at last – feels like it is decently quick.
I’m hanging out for the full Gigabit service, though, on the happy day when NBNCo manage to get fibre down my street. Bring that on !
Today I experienced an ironic example of an Internet Service Provider (ISP) successfully avoiding any consideration of a well meaning (and simple!) suggestion to improve their offerings. It is ironic because the ISP concerned is Internode, the company I founded in 1991.
I meant well in trying to help them to improve their service offering, but all I wound up doing was falling down a funny / sad rabbit hole in terms of where those efforts landed me, as you will see.
I used what appeared to be the appropriate email address (found on this page):
This is what I sent (very lightly edited for additional clarity):
From: Simon Hackett
Subject: The absence of support for Fixed Wireless Plus is a strange
and unfortunate deficiencyDate: 17 October 2020 at 1:21:38 pm ACDT
To: customer-relations@internode.com.au
Hi guys,
I have a 25 Megabit fixed wireless service in Tasmania.
This is the fastest Fixed Wireless offering available from
Internode/iiNet/TPG.
Fully appreciate this sheets home to TPG decisions on how the NBN
Fixed Wireless service is operated - but - NBNCo introduced a new,
higher speed/best effort (up to 75/10) Fixed Wireless service a
long time ago (December 2018!).
I have tried repeatedly since to get my service upgraded to
support those higher speeds, but I have confirmed (on multiple
occasions) with the sales team that there is no plan to have
Internode able to offer those higher speeds… which is just crazy,
frankly.
I think I’ve given Internode at least a year to fix this - and it
isn’t getting fixed - that much is clear.
So - I’ve now given up and signed up with Aussie Broadband and as
of yesterday, I am indeed enjoying > 60 megabit per second
speeds on the same site with the same hardware and the performance
change is dramatic.
I will call the accounts team on Monday to cancel down the old
Internode services at the site concerned (snbs client ID is
<REDACTED>, for reference).
As the person who founded Internode, I have found it hugely
disappointing - indeed actually upsetting - to have had to do
this… but (sincerely) this ball (in terms of supporting fixed
wireless customers) has been comprehensively dropped on a long
term basis by the TPG group. Supporting the now-current Fixed
Wireless service offering and rolling existing customers over to
it would be trivial.
It beggars belief that this is not being done - but - well -
obviously it is not.
For the sake of not losing customers in Fixed Wireless over time
in this entirely avoidable manner, I would challenge you to
actually fix this. It won’t help me, any longer, but it would help
YOU (and your existing and future customers).
Yours sincerely,
Simon Hackett
Founder, Internode
I got an email reply promptly back from iiNet (note: not from Internode), which said:
Hi Simon
Would you mind providing your account number or mobile number for us to
assist you further.
Kind Regards
<REDACTED>
Case Manager
iiNet Customer Relations
I pointed out in reply that I had in fact already provided this information.
What floored me is what came back next:
Hello Simon,
Thank you for your email and I do apologize for the delayed response.
Please contact internode directly via the following link:
https://www.internode.on.net/contact/?dep=support
Their contact details are via the above website.
Warm Regards,
Customer Service Representative
iiNet Support
iiNet Limited, Locked bag 16, Cloisters Square WA 6850
ph: 13 22 58 fax: 1300 785 632
email:support@iinet.net.auweb:www.iinet.net.au
Um… excuse me?
Here’s the bottom line – I tried, but – having been taken on a complete runaround for my trouble, well, I’m outta there…
…and wondering why I gave them more than year to fail to address my original issue (as per my email above) before I left. Loyalty, I guess.
My Aussie Broadband ‘Refer-a-Friend’ code is 4549606 if you’re considering the same move, and it will get you (and me!) a $50 credit if you use it.
Thus far I’ve been highly impressed with the outcome, and I’ll have more to say about that later.
(Full Disclosure: I have also purchased some ASX:ABB shares after their recent IPO)
I installed an Internode NBN HFC service in an apartment a few months ago. It comes with a Huawei HG659 router, attached to the NBN standard issue Arris HFC cable modem.
I really don’t like that router. Its got some negative characteristics – including it having a DHCP server that can get itself confused and conspire to keep handing out a conflicting IP address on the active network. I also much prefer using Apple Airport Extreme base stations for WiFi networking rather than the built in stuff in routers of that ilk (lets call them ‘low cost and cheerful’) – especially when I’m running multiple WiFi base stations (as is the case in the site concerned).
I’ve had great success in another site using Internode NBN via Fixed Wireless by just configuring the PPPoE client into the Airport Extreme and plugging that straight into the incoming connection from the Fixed Wireless NTD. That worked like a charm, and eliminated a similarly ‘cheerful’ router in that circumstance. However this simple approach just didn’t work on the NBN HFC connection – configuring the PPPoE client in the Airport Extreme and plugging it into the Arris HFC cable modem directly lead to no joy.
Each NBN ISP has some choice over how the HFC based NBN connection gets deployed to their customers. Some digging turned up the data point that the Internode service delivered via the NBN-Arris HFC modem is implemented as two ethernet VLANs, with VLAN 1 delivering the bundled VoIP fixed line phone service and with the Internet service delivered over VLAN 2.
There is no way to configure the use of an upstream VLAN in the Airport Extreme – it expects the PPPoE frames to turn up natively (with no VLAN tagging).
Some more digging and the solution emerged, namely to keep the Huawei HG659 in the picture but use it merely as an ethernet VLAN decoder. In that role, its job is so simple that it can do it without losing the plot.
and… it works (yay!)… but there are – of course – wrinkles 🙂
The steps involved should have been this simple:
Configure the HG659 using its wizard to ‘connect with another modem’. This is what the HG659 uses as its description for bridging the incoming VLAN to the local LAN ports.
Keep the HG659 WAN port connected to the Arris HFC modem (obviously)
Cable the Airport Extreme WAN port into one of the LAN ports of the HG659
Using the Airport Utility on a Mac, configure your PPPoE account details into the Extreme (Internet tab, select PPPoE and then fill in the username and password, leave the ‘Service Name’ blank)
However, this is what I also had to do (all in the Airport Utility)…
The DHCP IP range configured into the Airport Extreme needed to be changed (at least, I needed to change it, to make things work – YMMV). I switched it from its default of the 10.x range, and instead set it to use NAT on the 172.16 range (Network tab, Network Options button, IP v4 DHCP Range drop-down)
I had to turn off IPv6 entirely to avoid an ‘IPv6 Relay’ error coming up (Internet tab, Internet Options button, Configure IPv6 drop-down set to ‘Link Local Only’).
Turn off ‘Setup over WAN’ to avoid an alert coming up on the Airport Utility and the base station light flashing amber (Base Station Tab, clear the “Allow Setup over WAN’ check box). The point here is to explicitly disable the capacity for the Airport Extreme to be accessed (by the Airport Utility) over the WAN path. That’s definitely something I want disabled. My only issue here is that I’m surprised this checkbox is actually on by default in the first place!
One more bit of collateral damage here is that I probably can’t access the free VoIP phone service delivered over HFC VLAN 1 and out via the analog port on the HG659. I don’t care, I wasn’t interested in using it in the first place. It may well be the case that some cunning manual configuration of the HG659 could make that work (too) – but I really don’t care about it – so I just haven’t tried.
The one silly thing left out of all of this is that I didn’t get rid of any physical devices in the process, so I have this conga line of three hardware devices between the cable modem wall plate and the user devices in the site – the Arris HFC modem, the HG659 (now as a VLAN 2 decoder box only) and the Airport Extreme (as the site router plus central ethernet switch to some downstream Airport devices).
Speed tests are just as good as they were already, with downstream rates testing reliably in the mid 90’s and upstream in the high 30’s – pretty darned good (especially through that crazy hardware conga line) on a 100/40 Internode connection. Importantly the issues I had with the HG659 router and DHCP are gone.
Other notes:
The Internode NBN HFC service is in fact deployed on TPG infrastructure, so the above should apply equally to a ‘native’ TPG NBN service too. This also explains why the IPv6 doesn’t work (sniff).
The VoIP service should be capable of still being used, perhaps with some custom configuration of the HG659, and I may try to find a way to make that work just for the sake of the challenge
A router such as a FritzBox which is capable of VLAN decoding on the WAN port should be able to be used to deliver the Internet service directly via the Arris HFC modem without using the HG650 at all (eliminating one device). Its also possible the FritzBox may be smart enough to support logging in to the voice service via WAN VLAN 1 as well … and that is something to try out another day…!
Arris HFC Modem
Huawei HG659
Apple Airport Extreme
Postscript: There is another approach to the removal of the Huawei device from the critical path that has been pointed out to me on another blog – here. This won’t work with the Airport but it is a way to allow a Fritzbox or a high end Billion or another router with WAN port VLAN support to be used for the Internet path instead of the HG659, leaving the HG659 functional as well – in parallel – to provide the voice port service that is bundled in with the Internode NBN HFC service. The benefit here is for people who do want to use that bundled voice service while also removing the HG659 from the critical path in Internet access terms. While it does need yet more hardware (an ethernet switch) – its a really creative and effective answer that might be very helpful to others to know about!
In October this year I had the pleasure of having an in depth conversation about how the new energy grid and the new Internet grid is starting to evolve – and about the interesting similarities and overlaps that are evolving between the two.
A key thrust of the conversation related to the way that scalable energy storage is the transformative physical component driving changes in how the energy grids of the world will work in the future.
That conversation was undertaken between myself and Larry Smarr.
Larry was the perfect partner for this conversation. He is someone I have had the pleasure to have known in various contexts for some years now, and (as you will see in the video), we share some similar views on the topics concerned. I had a great time riffing with him on these topics.
The video of this conversation is available for your viewing pleasure here.
It is a 15 minute video that was excerpted from a half hour session at the Future In Review conference held in Park City, Utah in October 2015.
The Future In Review conference is pretty amazing – I’ve been a part of it for many years. This year I was (of course) wearing my Redflow hat loudly and proudly at the event 🙂
iiNet Limited, Locked bag 16, Cloisters Square WA 6850
ph: 13 22 58 fax: 1300 785 632
email: 
Simon Hackett 
You must be logged in to post a comment.