E-mails with attachments larger than 15-20kbps fails (error message 0x80040115 from Outlook send&receive) to send when a user is logged in on the hotspot, when connected through the main/unrestriced bridge (without hotspot) mails with any size attachment go through. We are using Office365.
Is there any restrictions on the hotspot functionality that is preventing office365 services from working?
Any other webpage or other traffic loads normally. Any ideas or pointers would be very very welcome.
P.S. We are running this over a satellite link with high latency (650-750ms), but if that was an issue we should have seen this causing trouble on both unrestriced vs hotspot access from what I understand.
When something appear not work correctly, first migrate to a more long-term version (6.48.6) and check if is not already solved.
And also, after 2 years (2020-Jul-08) is the time to upgrade…
We had similar problems a few years ago (though with equipment from another vendor) and I believe the root cause was that tcp suffered from double nac and like. It was solved by fine tuning the tcp settings mtu etc. Google “tcp timeout satellite links” for some hints
Two years old fw is just fine if everything runs smoothly in production. My advice is do NOT upgrade for the sole purpose of checking this out since you may run into other problems instead.
If possible to use a sniffer which is able to trigger on broken connections using a long time recording ie plenty of storage space. Then you might be able to correlate the error from the MT logs and hopefully locate the root cause. In addition, it’s not always necessarily a router problem as the problem also might originate from the end equipment.
Just for cite some publics vulnerability, and I don’t mention the hidden ones, on version 6.47.1, repaired in later versions…
What’s new in 6.48.3 (2021-May-25 06:09)> :
MAJOR CHANGES IN v6.48.3:
!) wireless - fixed all affecting ‘FragAttacks’ vulnerabilities (CVE-2020-24587, CVE-2020-24588, CVE-2020-26144, CVE-2020-26146, CVE-2020-26147)
Security vulnerabilities is of course allways important to consider but even then there might be other ways to mitigate issues but to perform a direct upgrade.
It all depends on the current situation and what type of vulnerabilities you have to deal with as well as many other aspects but that’s beside the point in this particular matter.
It might be a linguistic misconception but my point was not to upgrade for the sole purpose of investigate this particular matter as you may encounter new issues especially if your preferred way of working is trail n’ error (aka ctl-alt-del)
Personally I always prefer to identify the root cause first thing.
You'd be surprised how many HOSPITALS still run WINDOWS XP (Yes, XP !) because otherwise their lab-tools don't work anymore.
Now, if that is a wise decision or not, thát's another discussion ...
Thanks for the pointers guys, unfortunately the problem was somewhere else..
In the end this was related to the queue type kind the hotspot users were assigned once they were logged in, we use a shore based radius server and when the users were logged in they were assigned to the default-small queue which is set as pfifo. Users created locally on a hotspot are assigned to the hotspot-default queue which is set as sfq. Once we changed the queue kind for the default-small to sfq the mails with attachments went through without any issues. Limited at 10MB which I believe is a server limit.
Great you managed to locate the root cause and made it work. Working at sea can be a nightmare when it comes to this kind of hassle and remote management is rarely working good enough due to latency in my experience. Agree that the size limit is most probably at the server side.
Btw, I know some cruise companies are trying out Starlink at some limited regions. This together with CAKE (queue management) will probably improve both throughput and latency significantly. In my point of view this is the optimal solution.
Starlink operates closer to earth so they have maybe 100-150ms latency vs what we do which is GEO stationary orbit with approx 650ms latency. Perhaps they would not notice this to the same degree as we saw that on a shore based link we did not see the same issue, so speed/latency had a big enough impact on the solution for us.
Great you’ve solved it!
If I may add, from my previous previous life as an e-mail sys admin, we found MS Exchange to be very chatty and didn’t work too well over slow links. It would work great over LAN links if the client is local (10Mbps those days!), but crawl over slower WAN links when the clients were remote. I guess it’s been improved considerably now.
However you may consider these best-practice suggestions from Microsoft: Turn on Cached Exchange Mode and Work offline in Outlook
