You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the MME starts up, if the interface labeled in enb_addr is down, or if it does not have the address named in enb_iface_addr, the MME crashes with a somewhat cryptic error message. This is a problem because (1) we cannot guess a sane default for either of these values, and (2) these values often change over time or during network setup/configuration. Additionally, this is literally the most common (and only) error that we encounter during deployments.
The immediate fix here is to add a better error message (likely in mme_app_main.c) that clearly explains the problem, so that someone outside of our team can understand what to fix.
Other Notes:
We used to set the MME bind address to 0.0.0.0 (so that it would just listen on all addresses and thereby avoid this problem) but for some reason this DOES NOT WORK for SCTP on Ubuntu 18.04.
The ideal long-term behavior, for me, is one where the default configured MME listens/binds on all interfaces, and operators can lock it down more if they want. In this vision, enb_iface and enb_iface_addr are optional values, defaulting to *, and specifying an interface simply restricts it to this interface.
I think the main thing driving this problem is that the MME/eNB communication uses SCTP instead of TCP. The Linux SCTP implementation is far less mature than TCP/IP and likely to stay this way for a while :-(.
When the MME starts up, if the interface labeled in enb_addr is down, or if it does not have the address named in enb_iface_addr, the MME crashes with a somewhat cryptic error message. This is a problem because (1) we cannot guess a sane default for either of these values, and (2) these values often change over time or during network setup/configuration. Additionally, this is literally the most common (and only) error that we encounter during deployments.
The immediate fix here is to add a better error message (likely in mme_app_main.c) that clearly explains the problem, so that someone outside of our team can understand what to fix.
Other Notes: