M_LIMIT_EXCEEDED error due to multiple networks (Docker) when trying to make or receive a voice call

[polaris64]

Steps to reproduce

When making or receiving calls I got a pop-up message each time saying M_LIMIT_EXCEEDED and the call was immediately disconnected. The solution for me was to remove some of my Docker networks.

I accumulated a large number of Docker networks over a period of many months, so it's hard to say whether creating them manually will trigger this error. However the problem was definitely solved by removing them as a call beforehand failed with the above error but a subsequent call after removing the networks connected successfully. I'm also not sure exactly how many Docker networks are needed in order to trigger the error but I probably had 20 to 30 at a guess. After deletion I currently have only 4 and calls now work fine.

I'm not sure if this is a problem with Element, the homeserver, Firefox's implementation of WebRTC or something else. If it's not down to Element then could you let me know and I'll report this to the relevant people?

I'm not an expert in ICE, STUN, and WebRTC but I'd imagine the solution would be to filter out the Docker networks so that they are never used during call set-up.

Outcome

What did you expect?

For the call to be established correctly.

What happened instead?

The call seemed to connect however almost immediately a pop-up containing the message M_LIMIT_EXCEEDED was shown and the call was disconnected.

Operating system

Arch Linux 5.19.13-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 04 Oct 2022 14:36:58 +0000 x86_64 GNU/Linux

Browser information

Firefox 105.0.3 (64-bit)

URL for webapp

https://app.element.io/

Application version

Element version: 1.11.8, Olm version: 3.2.12

Homeserver

matrix.org

Will you send logs?

No

[t3chguy]

Without logs this has no information to go off

[polaris64]

Without logs this has no information to go off

I'm sorry for the lack of logs. I opened the issue after having fixed it and I didn't capture any logs while I was having the problem. I can perhaps try recreating a lot of Docker networks again and then try to recreate the problem. If I can then I'll be sure to send over the logs.

[MadLittleMods]

@polaris64 You can still submit debug logs now. The logs will probably include previous start-ups of Element which capture what happened before. It would help if you had a time/date estimate when it happened but we can assume around when you made the report.

[polaris64]

@MadLittleMods, I didn't realise that, thanks for letting me know!

I have just tried to do this however I received the following: Failed to send logs: IDBDatabase.transaction: 'logs' is not a known object store name

[polaris64]

[MadLittleMods]

@polaris64 I'm not sure how the logs exactly work 🙇. Perhaps you have a browser setting that doesn't allow or clears IndexedDB 🤷

For reference, I see a bunch of entries in the IndexedDB logs in Firefox and Chrome.

In any case, it looks like the information we need isn't available so you will need to figure out how to make the logs record and reproduce again to get the details needed here.

[polaris64]

@MadLittleMods I just deleted the highlighted item in my screenshot and refreshed the Element web app. Now I can see entries being added (under logs and logslastmod) so it looks like it's working again.

Sadly though that means that I don't have logs for the period of time when I was getting these errors, so I'll have to try to reproduce them and then send over the new logs.

[turt2live]

I'm closing as new logs do not appear to have been sent. If this is untrue, or this is still happening, please open a new issue with fresh reproduction steps for our QA team to review.