I spoke too soon! It’s turned into a problem again.
@rubi1200, I applied your fix, and it worked, thank you! How did you figure out that the MTU needs to be 1,320?
1 Like
It’s interesting that it’s only some broadband providers that have problems. When I logged on to this site with my work’s internet connection, the site displayed properly. So obviously, I’m thinking that it must be the site blocking certain IP ranges.
Although I could easily ping discourse.ubuntu.com from a terminal.
sudo ip link set dev eno1 mtu 1320
worked for me
1 Like
Okay I really do not understand this.
I did that command setting the MTU On my desktop computer. Logged onto the site using my Wi-Fi connection on my phone and it suddenly works. Very strange.
1 Like
Lowering the MTU lowers the your computer’s maximum data transfer speed.
My hypothesis is that lowering the MTU value works because it doesn’t satisfy a speed threshold that would engage DDOS mitigation. Therefore, instead of your computer being unable to access the forums, the system allows you to connect.
The reason we don’t see this on mobile is because MTU values are usually ~1400, not to mention there’s additional latency introduced due to the nature of cellular connections.
4 Likes
The forums had been working well for a while, but I have to change the MTU again 
Oh well.
1 Like
Logged in 15:30 - 20 May 2026 without @rubi1200’s special sauce.
Does anybody know why normal login fails occasionally?
I can only imagine that the network security people are still struggling with the after-effects of the DDOS, so sometimes we need the MTU fix and other times not. It’s not just the login; it affects accessing the forum at all (for me, anyway).
I’ve set up a Bash function to automatically change the MTU for when this happens. If it’s of any interest, here it is:
# Temporary workaround for Ubuntu Discourse after the DDOS.
function discourse
{
# Find the physical internet link.
local -r INTERFACE=$( ip link show | grep -F BROADCAST | grep -Fv NO-CARRIER | cut --delimiter=: --field=2 )
printf 'Setting the MTU for %s\n' ${INTERFACE}
sudo ip link set dev ${INTERFACE} mtu 1320
}
3 Likes
Yes, agreed - both the forum and login are unavailable sometimes.
Yes, I suspect that you are correct.
I would expect there to be additional information in the official thread, but nothing since 06 May 2026.
2 Likes
Hi, everyone 
Today (Saturday, 30th May 2026), at several times, including right now (21H46, Lisbon - Portugal time) I’m having the same behavior when trying to access this https://discourse.ubuntu.com web site (“Ubuntu Discourse” / “Ubuntu Community Hub”) that had happened some weeks ago and that rightly prompted @paddylandau to start this discussion topic: I can’t access it because I get a connection timeout error (“This site can’t be reached discourse.ubuntu.com took too long to respond. Try: - Checking the connection - Checking the proxy and the firewall ERR_TIMED_OUT”) when using my (large) Portuguese ISP home Internet access.
The problem is also happening to me when I use my Android smartphone, when it is connected to my home Wi-Fi that uses the same Internet connection.
However, if I connect my laptop computer to the free tier of Proton VPN and select (or get selected) the Netherlands free server, then I can access it.
I also can access this Discourse using my Android smartphone, if I switch to 5G access (“mobile data”), instead of using Wi-fi (my mobile voice / mobile data ISP is the same Portuguese ISP).
I’ve found the following bug / issue but it has been marked as completed, by the person that reported the bug (RokeJulianLockhart - which I assume is the same person as @rokejulianlockhart here in “Ubuntu Discourse”) on 20th May 2026 (presumably he marked the issue as completed because the problems seemed to have stopped then but, as I’ve said, they’re happening again, at least to me):
“[Bug] Attempting to connect discourse.ubuntu.com returns PR_IO_TIMEOUT_ERRORs, 99 % of the time. · Issue #16350 · canonical/ubuntu.com · GitHub” - https://github.com/canonical/ubuntu.com/issues/16350
Is that issue / bug in GitHub the best place to report that the problem is happening again?
Thanks in advance!
2 Likes
Same for me here also.
3 Likes
Yes, today 30 may 2026, @rubi1200’s special sauce, advertised in post 37, comes to the rescue once again
3 Likes
That and a no-cache refresh of the Discourse page (CtrlShiftR in Firefox) is all that’s required, actually; and the refresh is only for the impatient, because after reducing the MTU size, while FF is still trying to connect, it will eventually connect with the changed MTU in a retry.
And yes, I’m also affected by this; I only need to do the reverse (set MTU to 1500 again) and FF gets stuck trying to connect, currently. I occasionally do that to see if the issue is resolved, and it works sometimes, so I’d categorize this as intermittent.
4 Likes
Availability/accessibility of the Ubuntu Discourse site has become so unpredictable, that I’ve given up any attempt at visiting on a regular basis.
If that is the experience of others who depend on the site as the basis for actual support, that does not bode well for the future attractiveness of Ubuntu as a platform.
I should NOT have to change what were my long-standing browser settings in order to overcome, or fake-out, any new site filtering mechanisms, in order to access my pre-existing Member account.
Please … it would be nice to see the site restored to its “traditional” availability.
5 Likes
I have same problem in Chromium Incognito window and Firefox (both standard and Privacy window).
It works in Chromium (standard window) and in Palemoon.
Ubuntu 26.04 LTS, wifi. I did not try mobile data.
Sure. Likewise, you should NOT have to keep locking your front door when you leave your house. But, you do. Because of criminals. Blaming you for the problem would be unproductive and unhelpful.
So, what do you suggest? Having a nice chat with the hackers who are causing the DDoS because they think that Canonical is somehow a part of the invasion of Iran (even though Canonical isn’t even a US company)?
The solution is either to somehow persuade the hackers to stop it — a highly unlikely scenario — or to use the known workaround until the problem stops.
It’s hardly productive to blame Canonical for the problem.
If you want an easy way to solve the problem, add this code to your .bashrc:
function discourse
{
# Find the active internet link.
local -r INTERFACE=$( ip link show | grep -F BROADCAST | grep -Fv NO-CARRIER )
# Find its name.
local -r NAME=$( cut --delimiter=: --field=2 <<<${INTERFACE} )
# Find its current MTU.
local -ir MTU=$( grep -P --only-matching '(?<=\bmtu )\d+' <<<${INTERFACE} )
if (( MTU == 1320 ))
then
printf 'MTU for %s is already %d.\n' ${NAME} ${MTU}
else
printf 'Setting MTU for %s to 1320.\n' ${NAME}
sudo ip link set dev ${NAME} mtu 1320
fi
}
Then, each time you want to visit the forum, open a terminal, enter discourse, and continue from there. You only have to do this once, until you restart your computer.
If you don’t want to keep entering your password each time, add this line to sudoers (change eric to your actual username):
eric ALL = NOPASSWD: /usr/sbin/ip link set dev wlo1 mtu 1320
EDIT: You’ll have to change wlo1 to whatever your computer’s interface name is.
This is what we have to do to support Canonical during this stressful time.
3 Likes
The issue is being worked on and hopefully will be resolved soon.
We apologize for the inconvenience even staff have had issues intermittently.
8 Likes
It seems to be fixed now in all browsers.
I wouldn’t count my chickens just yet; I’ve been there. 
1 Like
There were some adjustments made earlier today in hopes it would fix it.
Just need some hours of users being able to get on or not to see if it worked.
4 Likes
Alright then; I currently have no issues anymore and MTU is the default 1500.
2 Likes