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.

Hardware RB951Ui-2HnD running ROS v6.47.1

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...

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.

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 doNOTupgrade 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.

@Larsa... two year firmware is OK?...

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.

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.

Hope this helps somebody, was driving me nuts!

Thanks for the feedback!

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.

Happy to share with the community

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.

TGIF!

TGIF!

Concur, cheers!

Dont forget this larsa....
viewtopic.php?p=934431#p934431

LOL you made me get caught in the first trap, check it up! Have a nice weekend, cheers!

Thanks for the pointers guys, unfortunately the problem was somewhere else..

Great you've solved it!
如果我可以加入,从我以前的以前的生活作为一个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