• There are no new features in this release.

• Channel shutdown/disconnect has not been clean for a while. We suspect that this could have lead to system crashes. In less-fatal situations it gave you SSL errors on disconnect, or had channels time out for up to 5 seconds instead of cleanly disconnecting right away.
• On certain products (310, 2620, 2030, 5000, 5010) the hardware crypto engine could crash during channel disconnects. We believe that  this bug is the reason why customers running routers under high stress (Satellite connections, ships, vehicles with lots of reconnects) are seeing devices reboot, while others don't. 
• Fixed stacking slaves having a calculated MTU < 1500 not getting that MTU used. This fixed slave channels on a 500 stacking slave (or anything that uses PPP) not getting used.  
• Fixed automatic connect to the License Server, which did not work before (you had to manually connect to received updated licenses)
• Reverting back to not dialing directly for LTE modules, but instead modifying to profile to trigger call. This means that those customers complained about problems with private APNs prior to the current stable release now will have these problems again, but they can use the custom WWAN profile feature to work around. We had to revert this because with the new way of dialing Verizon in the US did not work at all anymore, and also problems have been reported from the UK.
• Fixed demo and project routers not being able to use stacking slave channels. Please note that you have to re-select the remote WAN module inside the channel after updating to this fixed firmware.
• Fixed popup message on demo routers to not say that the demo runs only 14 days, but correctly state that it is 90 days.
• Re-factored the way statistics about flow source and destinations host are managed. Before a DDoS attack using spoofed IP addresses could eat up all the RAM and a lot of performance. The system now no longer can be put out of service flooding it with spoofed IP addresses, and in generally also performs better in scenarios where a huge amount (1000+) of LAN devices are using a Viprinet router.
• In case of certain kind of DoS attacks, the routingcore thread potentially could have gone stuck, causing the router to reboot about 90 seconds.
• In case a DDoS attack is detected as likely, messages on this are logged, at the maximum once per minute.
• A bug in memory handling of IP packets has been corrected. This bug could cause both a small memory leak accumulate over time, but also could cause crashes under certain circumstances.
• Setting an IPv6 address as main LAN IP address (instead of adding the V6 address as an Alias) wasn't supported but not prevented, which could result in the router becoming unreachable from the network. It's no longer possible to set an IPv6 address as the main LAN interface address.
• The retransmission manager used for QoS classes having "Guaranteed delivery" enabled had a bug which first of all was leaking memory, but also could have resulted in half of the retransmissions not taking place. This  means that a flow going through the tunnel could have seen packet loss even with Guaranteed delivery on. This could have dramatic consequences: TCP/IP header compression used builds on the guarantee that there never are lost packets. This means that if a flow used guaranteed delivery and then a channel had packet loss, the flow could get stuck.
• Fixed log output of TCP Sequence numbers (the numbers could be logged negative).  Also lowered log level of very common TCP violations caused by broken scanners, no longer claiming that you are under attack.
• Make sure stuck stream downloads are aborted. This bug could have resulted in download tests doing in the webinterface eating 99% CPU if they get stuck.
• The routing core could get stuck on the receiving side of flows. Very rare, depending on timing. You could be running without a stuck routing core for weeks, and then suddenly have it getting stuck all the time. 
• Individual high-load guaranteed delivery flow receivers could get stuck after a tunnel reconnect, and while doing so could eat up memory.
• The receive-side timeouts for non-guaranteed flows that make sure that we wait long enough (but not longer than) for all fragments to arrive is based on the assumed bonding latency of the combination of channels used. The filters used weren't fine-tuned, and not suitable at all for satellite connections. These non-tuned values could cause packets getting dropped receive-side (because the router would not wait long enough for all fragments of that packet to arrive). This could result in the receiver being at fault for not being able to use the full tunnel speed downloading from/through the tunnel. The filters have been completely rewritten. 
• The "Average latency is ... ms, maximum allowed is ... ms, no alternatives, keeping channel." message is gone, as is the underlying idea: It does not make sense to keep the last channel with a latency higher than the maximum allowed one. If the last channel drops out for a moment, the tunnel layer will do the buffering.

There are no new features in this release.

• Starting December 1st, 2016, all previous releases started to display an annoying pop-up when logging into the web interface, claiming the firmware to be out of date and out of support. This even was the case with the most recent firmware release from October 28, which is perfectly fine and covered by support. The popup has been removed. We apologize for any inconveniences.
• This releases fixes an encoding bug that caused VPN Clients connected to RuggedVPN Hubs to be unable to display Downstream and Latency graphs in the Monitor tab.

• Dynamic routing with BGP and OSPF is now fully supported on both Hubs and Nodes.
• LTE modules may now send and receive SMS. There also are auto responders which you can configure to automatically reply to incoming SMS. Using this feature you can now use our products with LTE providers that offer data-plans where you can add data packages by sending an SMS. For example Vodafone Germany will send you an SMS "Your high-speed data has been used up, reply with "5" to book another 5GB". With the auto responder feature you could create a filter on "high-speed data has been used up", and have the router reply "5" in this case to automatically book a data package. Please note that this feature due to chipset limitations sadly does not work on the LTE 450 and 4G Europe II modules.
• Viprinet Virtual Hub config is now compatible with hardware hubs, which means you can copy a config file from or to a hardware router and use it.
• Internal improvements in RAM management reduce the amount of RAM and address space used a lot. Memory usage on a heavily used Hub should increase much slower than before.

• New improved behavior for disabled tunnels on VPN Hubs: Instead of letting tunnels, clients or channels connect and then have them disconnected again if disabled (or the VVH identity not being ready), we now reject them directly while  they are trying to connect. Also added some throttling.
• Viprinet Virtual Hub: Improved startup system to make sure the VVH is not flooding with incoming Tunnel connections before being ready to accept them
• Viprinet Virtual Hub: If the DNS was unreachable on VVH startup, it would take up to 5 minutes until the identity server's hostname could be resolved again.
• Viprinet Virtual Hub: Users can no long acquire a new device identity unless the device is marked to be a "Copy"
• Fixed SFTP support
• In the WAN module info of LTE modules you could sometimes see garbage text behind "Country:"
• Fixed the web interface sometimes not showing the summary list of all items when selecting a list object.
• Fixed stacking slaves not having their channels used after restart
• Removed lots of JS debug output lines in web interface
• Fixes an unsynchronized access inside the web interface Ajax message system. This could cause routers to get stuck and/or the Object tree would no longer being accessible in the web interface, and other errors. This most often appeared when executing "Contact license server" manually from the web interface, or when disabling a Tunnel on the VVH.
• Now reports an error in case a license de-activation has failed
• Fix for ADSL/VDSL modules sometimes no longer being usable if they get assigned a new IP in a 24h reconnect without the interface going down/up during that reconnect.
• Made sure that expired licenses/subscriptions are not counted as valid tunnel licenses on the VVH.
• Drastically improved upstream autotuning results on RuggedVPN VPN Client by a factor of 10+.
• As our routers, the RuggedVPN VPN Client will now also tune the TCP sendbuffers. We've seen this stuck at 8k for Windows, so this gives a HUGE performance improvement over high-latency links.
• The HTTPS download test tool would accept SSL certificates that are valid, but expired
• If on the Hub no DNS was configured to be assigned to VPN Clients, the VPN Client would block during connect for 10 seconds. This delay no longer exists, speeding up VPN Client connection time dramatically.
• Routes pointing to invalid targets could not be deleted.
• 2620 routers believed their Bandwidth Capacity to be 200 Mbit/s instead of the 400 MBit/s they can do. They also reported a wrong capacity over the tunnel to the remote device. In practice that should not mean much, but under certain circumstances / loads from LAN this could have limited the total throughput the router can do, and it also would cause the Hub to use a wrong assumption on total capacity for bandwidth auto-tuning.
• Made sure HTTPS web server is disabled for the VPN Client
• Added log prefix for HTTPS errors showing the remote IP that caused this error
• Improved identity handling of Viprinet Virtual Hubs. In case a VVH gets flagged as clone you can now resolve this by shutting down the clones. After a while the one remaining ex-clone then is flagged as verified again.

• Internal transfer network for virtual hubs must not be changed.
• Dynamic routing tries to handle VLANs and segmentation as good as possible, but not all setups may work. There are no separate routing tables.
• To configure the SMS features on a 510, a SIM has to be present for the module.
• Disabled VPN Bypass for now.

To active the dynamic routing feature you will need to install the Enterprise Node Features software license on the Node side. So this feature is built-in on any Viprinet Hub and of course on the 2610/2620 for free.

• A new web interface object "Dynamic routing settings", also including two new tools "Full routing table" and "Viprinet routing table". 
• Allows you to dynamically distribute static LAN/WAN Viprinet routes.
• Push / Accept routes per tunnel. You can find this setting in each tunnel. The standard use case is to enable Push routes on the node side and enable Accept incoming routes on the hub side. I'm sure you will find a scenario where it is useful to use it in both directions.
• You can select which interface should speak in which area and if it should be used for dynamic routing (OSPF/OSPF for IPv6 only).
• WAN/VPN routing rules, VPN Client pools, LAN IPs and additional LAN routes can be distributed.
• The Viprinet router is able to announce itself as default gateway, but it will ignore default routes announced by other routers.

Two example cases

Case 1: Use the new Tunnel protocol to send all node networks to the hub so the hub can route them (No static WAN/VPN routing rules)

• Hub side: Enable "Accept incoming routes" in the selected VPN tunnel
• Node side: Enable "Push routes through tunnel" in the selected VPN tunnel

After enabling these settings, the tunnel needs to be reconnected. The Hub should now receive all node networks and route them in the right tunnel.

Case 2: Extending Case 1 with a dynamic routing service

• First configure the Node and Hub the same way as in case 1
• Additional to that configure/enable on Node and/or Hub side the Dynamic routing service and the service you want to use (BGP, OSPF or OSPF for IPv6)

All networks incoming on node side will be also known by the Hub and can be routed. Make sure you have enabled the check mark "Distribute local Networks" in the service you want to use. Otherwise it will not be distributed. If you also enabled a dynamic routing service on the Hub side it can distribute all Node and Hub networks to the Uplink router.

Warning/Hints

• BGP only: To start the service, you need to configure at least one BGP neighbor. You can find the BGP neighbor object under "Integrated services" " "Dynamic routing settings" " "BGP settings".
• OSPF/OSPF for IPv6 only: For starting the service, you need to configure an interface to use in the LAN settings object; there, you can also configure the OSPF area.
• VPN Tunnels: Changing "Push routes through tunnel"/"Accept incoming routes" needs a tunnel reconnect to take effect.

Known issues

• OSPF/OSPF for IPv6: Password authentication doesn't work.
• Default routes announced by other routers are getting dropped right now.

• You can now update the firmware of VDSL modules inside the routers web interface. New firmware images for the VDSL modules are automatically downloaded as needed,  the same way the LTE firmware images are.
  ​Firmware changes for latest VDSL module firmware version 1.91:
  • VLANs now work in ADSL RFC1483 mode.
  • Module now reports authentication failure to the router if the credentials are wrong during ppp dial-in.
  • Ping and traceroute tools in Viprinet work again.
  • Now multiple connections via the module into the world work again (for example download test tool).
  • Uses most current Datapump (10.23.0.47) this fixes a lot of VDSL related sync issues.
• Full support for the 4.5G LTE-A module. The module will now also display the module's Viprinet serial number in the web interface.
• Implemented code that checks Ethernet/IP/TCP/UDP/ICMP packets in detail when coming in from the LAN and when going out. This is protecting both our routers and networks behind it against a huge range of TCP/IP protocol attacks.
• New logo animation on router boot-up. Nobody asked for this, but we still did it.

• We now allow VPN Tunnels, VPN Client Tunnels and Channels to be deleted while they still are enabled (but not connected). This is changed to work around a bug in the VPN Client that can get stuck in an unclean state on startup forever, trying to delete an enabled tunnel. But in general this should also improve convenience for all of our users.
• This release fixes the problems the LTE Europe/Australia/Africa module has with reading some SIMs.
• Fixed wrong time zone calculations being done on 200 and 5xx products, causing wrong log time stamps etc.
• Under rare circumstances a channel that was disconnecting uncleanly could get the routing core stuck.
• Under very rare circumstances access to some objects that were used by the routing core in that same moment could get it stuck (this could be reading SNMP, web interface, CLI or router stacking communication).
• On newer devices that were using an asynchronous hardware crypto accelerator, an unclean channel disconnect could cause the router kernel to crash, panic and reboot.
• Stacking masters could sometimes get stuck if a lot of changes were going on on channels and/or WAN modules that were synchronized between routers.
• A slow memory leak would cause the Hub to run out of RAM after a few days. This was mostly seen when using FEC.
• The Virtual VPN Hub's clone detection potentially could wrongly flag your Hub as a clone if time on our backend server cloud was de-sychnronized.
• SSL handshake timeouts are now much more relaxed, which should result in less SSL handshake errors on unstable WAN connections.
• In case that the router has to reboot (due to a routing core being stuck, being out of memory, etc), it will now first try to write a copy of the log file to flash memory. This means that in future our support team will be able to diagnose a Hub/Router after a reboot, even if you did not have a local syslog server.
• The designated stacking master will now use its own uptime instead of the one reported by the current stacking master. Also the logging has been improved and should be less confusing now.
• Fixed timing problem in Dynamic routing which resulted in "Duplicate Route received" on the remote side.
• The property "Distribute via Dynamic routing" in Additional LAN Routes was not used.
• A node connecting to a Hub could end up with 99% CPU forever in case the TCP connection broke down in the middle of the handshake.
• The "Guaranteed delivery" QoS feature/setting under rare circumstances was able to cause router crashes and memory leaks. The feature is disabled in this firmware release and will come back later. No matter what you set in the QoS now, in this build guaranteed delivery will not be used (it does not change your setting).
• As a protective measure on the Hub side, we will now close a channel connection if during authentication more than 10 errors have occurred.
• Implemented code that checks Ethernet/IP/TCP/UDP/ICMP packets in detail when coming in from the LAN and when going out. This is to make sure that under no circumstances we are sending out garbage that might crash the kernel.
• Reduced the number of packets read from the LAN in one go. Before, if you flooded a Hub on the LAN interface with packets, the router was hardly able to handle anything else anymore – it could get the routing core feel stuck.
• On Hubs, there is another safeguard that a broken cached SSL session will not be re-used. This fixed the floods of SSL Handshake errors some customers have seen before the routing core got stuck.
• Fragmented IP packets that span more than 32kb could cause memory corruption and would then make the router crash. We have seen this in the wild, potentially part of an attack against a customer.
• When a Hub was switching from Hotspare to Replacement mode, some part was internally crashing. The Hub recovered from this, but it involved a system reboot. Due to this, failover was slower than intended. It is much quicker again now.
• LAN IP Aliases accepted invalid IPv6 addresses. They no longer do.
• Applying settings in DHCP services logged an internal error message for no reason.
• Changed SSH CLI RSA Key length from 1024 to 2048 bit.
• Until now, if you flooded a Viprinet device with ICMP ping packets, after a while it stopped responding and never answered ICMP again.
• The tunnel will now auto-reconnect in case a Fatal Error is experienced while trying to read a packet from a channel.

• Under certain circumstances traffic in one or more QoS classes would suddenly stop flowing. This could for example result in the users suddenly no longer being able to resolve IPs via DNS. This issue existed for a long time, but became more frequent with newer firmware releases. The issue now is verified to be fixed.
• In some installations, with the July firmware release LTE 450 MHz modules as used in Northern Europe would no longer be detected. They now are detected on all products again.

• UMTS and LTE modules now are using a brand new APN databases that is based on the SIM's IMSI range. This means we can now differentiate between network resellers – so “Tchibomobil” SIMs on O2 will now use their own APN instead of the O2 one. The database is always updated and fresh. In case the new system fails, there is a fallback to the old MCC/MNC-based APN detection.
• Drastically reduced memory usage both on Hubs and Nodes.
• LAN throughput on Hubs has been drastically increased. Even if the Hub could do more, in previous releases it would at the maximum read around 250 MBit/s from the LAN only. Now it is doing 2 Gbit/s again.
• Massive improvement on bonding throughput on most products. We have now seen peek bonding throughputs of >200 Mbit/s on a 310.
• Now supports the new LTE-A 4.5G APAC module.
• All recent LTE modules now are able to acquire the IP address on connect much faster than before.

• Using the packet capture tool you can now live-view or download pcap files of traffic at various places.
• In the web interface collections you can now not only add new items, but also insert them. If you use insert while being in the collection object (“Tunnels”), the item will be inserted on the top. If you have selected an item (“WurstTunnel”), the new item will be inserted in front of it.
• In collections you can now move items to the top and bottom instead of just up/down.
• Tunnel items may now be moved, and new tunnels inserted instead of just added.

• Various fixes and changes on how FEC and channel selection for it works.
• Various AWS fixes for certificate management.
• Some logic bugs in how QoS classes are allowed to send at what speed were fixed. This fixes the broken “guaranteed bandwidth” test cases reported by partners.
• Made sure that ALL possible LTE bands are enabled before it is known which bands the module actually supports. This might fix the problems partners had with “Forgotten LTE bands”.
• Now accepting silly TCP Option 14 through Viprinet tunnels.
• If the internal transfer network was re-configured to something else than the default settings, Virtual Hubs no longer were able to reach the Virtual Hub Verification servers.
• For WLAN Client modules, the currently seen WLAN APs are getting listed in the module info again, even if there no connection to an AP.
• Previous firmware releases could reboot after running for 49.7 days, due to a 32 bit counter wrap-around. They no longer are doing that.
• Fix for a workaround for bugs in some LTE module firmware releases that might cause the LTE modules of a 51x not to detect SIM cards on a cold boot.
• Fixed potential KRACK WLAN security issue.
• Some fixes for the “Modules are getting stuck in disconnecting state forever” problem that partners have seen.
• Fix for Chrome 61 being unhappy about the self-signed SSL certificates that our routers generate for the web interface. Please note that you must manually re-generate a new SSL certificate inside the router to make Chrome happy again.
• “Managed SIM Settings” have been removed from the firmware, as our managed SIMs haven't been available for a year already.
• The 511 LTE images were reduced by 35MB in size. Now doing an offline update on a 511 works reliably again.
• A slave in a stacked router setup was saving the config every time a change was sent from the master. It now only saves every 30 seconds max.
  Also the synching now has been throttled to eat less CPU.
• Under very rare circumstances, NATted ICMP-traffic coming from multiple sources (tunnels) at the same time could get one or more of these ICMPs flows get stuck.
• All download tools now support HTTP chunked encoding.
• In the previous stable release the LTE firmware carrier certification was not being displayed in module info.
• Made sure that for custom profiles all of its settings are confirmed to really be received by the LTE chipset. This fixes all reported problems when using private APNs.
• Some users were reporting the Google maps GPS tool in the web interface to no longer be working. A new Google Maps API key was added to solve this.
• Starting December 1st, all prior firmware releases incorrectly complained in the web interface to be outdated. We are sorry for the confusion.

• There have been reports that in some installations, VDSL or ADSL modules get stuck in "Disconnecting" state once they receive a new IP address during a 24h reconnect. There had been reports about this in the past, but just as today we are unable to reproduce this. If you are seeing this problem, please contact the Viprinet support team.
• Under circumstances, you are not able to enable VPN clients on Virtual VPN Hubs. Please contact support if this happening to you. We will be preparing a Hotfix for this.
• Deleting a VPN tunnel that had been connected within the last 3 minutes may cause a VPN Hub reboot. Please wait 3 Minutes before deleting a VPN Tunnel.
• After installing the firmware update, a VPN Hub Hotspare may wrongly report the active Hub not being able to reach any of its ping targets on the LAN and WAN, wanting to replace it. This problem is gone after a second reboot. One possible work-around for this problem is to temporarily remove the VPN Hub from Redundancy Group before updating it. If you need assistance in planning the update of a large amount of VPN Hubs, please contact our support for assistance. 

• VPN Bypass is here!
  This allows you to create traffic rules that do not point to a tunnel, but instead directly to the module, where traffic will be NATted to the module's IP.
  Go to WAN/VPN routing rules, enable “Allow VPN Bypass routing”, setup some routing rules pointing to a module, and have fun.
  Please note that this feature is only to be used in corner cases–for example if there is a DSL router with integrated VoIP gateway behind an Ethernet WAN module, and your phones need to reach it. Remember that using the WAN module directly for Internet traffic defeats pretty much any purpose Viprinet routers have (security, redundancy, etc).
  There also is the option “Module browsing tool” inside the WAN module objects if you just want to temporarily surf through a module to fill out a captive portal.
• You can now add and manage DNS A records of the integrated DNS server. This allows you to configure hosts like “mycomputer.local” and have that resolved to an IP for all computers using the router's DNS server.

• Using repeated security scan floods for a TLS ROBOT attack could make Hubs/Routers crash and reboot.
  We have now updated the Cipher suites used to completely disable RSA key exchange as recommended as a best practice.
  By that, we have removed compatibility for any Viprinet classic firmware device using a firmware version older than 2015 connecting to an updated Hub.
  You'll also no longer be able to use the web interface with HTTPS with very outdated browsers like IE below version 11.
  We also have hardened the VPN Tunnel code in regards of future TLS attacks.
• It was possible to run a DoS attack against the router by opening lots of connections against the SSH ports, then closing the SSH session on the SSH protocol layer, while at the same time keeping the SSH TCP connection open.
• With the previous firmware release, it was possible that routers restarted after 24 days of uptime displaying a “Routing core stuck” message due to a timer desynchronization.
• If a stacked setup was connected to a Hub, and the master rebooted, the slave took over. But if the master came back and restarted the channel, you could see on the Hub that the slave's channel might have hung in the “disconnecting” state until the hub rebooted. This was caused by  the "A split brain situation has occured on the remote stacking Node, channel will be disconnected" error.
• Problems with activating VPN Clients on Virtual Hubs were fixed.
• In very rare chases, DSL modules can get stuck due to communication issues between the router and the module. If that happens, modules will now automatically power-cycle. There are still known issues in this regard which we are working on. Should any of your modules get stuck in “Disconnecting” state, please contact our support team.
• Proper permanent fix for the “Outdated Firmware” message. The message will now always appear 1 year after the firmware's release date.
• Stacking often had problems doing ARP resolves for LTE modules, rendering these remote modules unusable for the stacking master.
• A whole lot of problems with the way routers handle IP fragmentation have been fixed. This will help all customers who are using fragmented IP packets (e.g. IPSec tunnels through the Viprinet VPN Tunnel, some audio/video codecs). Please note that IP fragmentation is still not recommended as it will hinder performance. You should fix any IP fragmentation you have on your network as far as you can by adapting IP payload size to your network's MTU.

• Having more than 256 routes could cause the dynamic routing engine and router startup to fail.
• Fixed a bug that could cause routers to reboot once every 24 days.
• Fixed a problem with dynamic routing that would randomly appear on startups.
• Fixed WAN modules sometimes getting stuck in “Disconnecting” state, mostly seen with VDSL.

• In the stable release 2018070900 we had prepared support for the web interface to be able to use Unicode (for localization) in the future. The implementation contains a bug that if a certain URL formatwere included in a HTTP/HTTPS request, it would make the Hub/Router silently reboot without giving any message.
• In some rare cases, updating a 51x router to the stable release 2018070900 could make it hang during the boot process. For some customers this has never happened, for some it happened on a lot of devices. The exact reasoning why this is happening only for some customers are unclear, but with those who had seen the problem we have verified the bug is fixed.
• With the stable release the "Minimum guaranteed bandwidth/maximum allowed bandwidth" features of QoS did not longer work as expected. This is now fixed, they fully work as expected again. (Bug ticket #1391)
• For 200/5xx routers an optimization for reading packets going to internal router services (web interface, SSH CLI) was introduced in the stable release 2018070900. This has now been removed, as CPU cache bugs were causing packet loss and reordered packets when accessing router services. From our tests we have not seen any significant impact in performance.
• Viprinet routers contain a connection limiter making sure you can not overload the router's services with simple single-IP DoS attacks. It makes sure only a certain amount of connections per IP can be established per service. However, in the 2018070900 stable release this was broken on two counts: For HTTP/HTTPs and SSH the limit was not enforced at all.
  • Web interface: 25
  • VPN Channels: 25
  • SSH Connections: 3
• The code that decided on how many concurrent WAN Optimizer connections to allow was basing it decision on how much free RAM was left on a router. However, it did not take into account that RAM it already uses itself should also be counted as "free". This caused a router after running for a long time or having used a lot of WAN Optimizer connections to reduce the maximum allowed WAN Optimizer connections, effectively resulting in at some point the WAN Optimizer hardly being used at all anymore.
• The TCP Option 254 originally used for RFC3694-style experiments according to IANA is illegal and should not be used, however customers have reported that they have broken equipment in their network that improperly uses this option in shipping products. We therefore are now allowing this TCP Option as requested by a partner.
• If you had flapping channels on a Hub (channels constantly reconnecting), this would cause a small memory leak that over time would grow large until the Hub ran out of memory. (Bug ticket: #1399: Memory leak with flapping channels)