This release improves Route10’s core reliability and observability, with performance enhancements that help networks operate smoothly.
Add support for reading SFP port DDM info (RX power, temperature, etc.).
Add support for reporting firmware updates to audit log.
Add support for reporting storage usage.
Improve lookup-host usage with CloudFlare DDNS client.
Improve storage reliability on larger sites.
Improve VLAN Acceleration reliability, for WANs using VLANs.
This update is being rolled out now. You can manually initiate the upgrade if you’d like, or it will automatically update overnight (if auto-updates are enabled). The complete, up-to-date changelog is available here:
If you have questions, feedback, or run into any issues, feel free to reply here or start a new topic. Including configuration details or relevant logs where possible helps us troubleshoot and respond more quickly.
No issues with this update like the last few where there is a loss of internet and need to reboot a few times to get it work! not sure what may have changed but great outcome.
@bsantiago It does directly fix the issue @jcolp shared, however, I think it is related to your issue. I actually didn’t realize this before either..
How do you have your hostname entered in Control for the DDNS client? Is it subdomain.domain.tld? Or is it subdomain@domain.tld? The former is actually incorrect, and won’t assign the zone_id but the latter (@) is the correct/expected method for the zone_id to automatically propagate. This only applies to CloudFlare when using subdomains (assuming bearer token has proper perms, etc).
The bug mentioned fixed part of a parsing issue, but I’m told without the hostname being in the expected format, then it will never map to the proper zone_id automatically. Given that your input was being parsed with a . I think it may actually be in the incorrect format. I’m sorry that I didn’t realize this when I was offering advice to the support agent you worked with.
Our help center article will be updated with this info shortly. If that is the case, and you switch it, please let me know. I would recommend either moving or deleting the post-cfg.sh before adjusting the DDNS client config, that way when it saves it will wipe the customizations. You can usemv /cfg/post-cfg.sh /cfg/post-cfg.bakto back up the post-cfg.sh file, or rm in place of mv to remove it.
Something was abnormal with this update. I set it to update overnight, and this morning I had no connectivity, however remote icmp (ping) to the device from wan was working. I didn’t have time to do any troubleshooting so I just power cycled it to get back online.
Edit: random noise because I originally posted this in the wrong topic but I could not re-post because it complained the text was too similar!
There is a chance this is related to the baby jumbo script I made. I didn’t experience this on my 1.4r test build upgrades, or the final one, but those are similar symptoms to what I encountered and why I had posted a message about dual-WAN configs not working right.
Thanks for reporting this, presumably for 1.4r. If you don’t mind, please do mention it if it does continue whether in a release thread, the baby jumbos topic, or even via DM/email.
I will be doing some more testing and possibly iterating on it, and follow up if I find anything obvious. I still need to share a newer version anyway, which includes the updated logic so I’ll make a point of getting that out, either later today or over the weekend.
Thanks Mike. I don’t think this is related because I haven’t gotten around to implementing it yet (and I only have a single WAN in any case). For the benefit of this thread, I have a WAN connection that uses a VLAN, and on the LAN side I use multiple VLANs.