try:
    # PySide6 6.8.0 contains a known crash bug (spyder-ide/qtpy#494).
    # Read the version from package metadata (no import needed) and skip
    # the broken release so the PyQt5 fallback is used instead.
    try:
        from importlib.metadata import version as _pkg_version
        if _pkg_version("PySide6") == "6.8.0":
            raise ImportError("PySide6 6.8.0 is known to crash IDA Pro; falling back to PyQt5")
    except Exception as _e:
        if "6.8.0" in str(_e):
            raise
        from PySide6.QtCore import *      # noqa: F401,F403
        from PySide6.QtGui import *       # noqa: F401,F403
        from PySide6.QtWidgets import *   # noqa: F401,F403

        # Explicit exports required by IDAssist modules.
        from PySide6.QtCore import (
            QObject,
            QDateTime,
            QPointF,
            QTimeZone,
            Qt,
            QTimer,
            QThread,
            QSize,
            QRect,
            Signal,
            Slot,
        )
        from PySide6.QtGui import (
            QAction,
            QIcon,
            QColor,
            QBrush,
            QPen,
            QFont,
            QTextCursor,
        )
        from PySide6.QtWidgets import (
            QWidget,
            QApplication,
            QDialog,
            QVBoxLayout,
            QHBoxLayout,
            QLabel,
            QPushButton,
            QLineEdit,
            QTextEdit,
            QPlainTextEdit,
            QComboBox,
            QCheckBox,
            QSpinBox,
            QTabWidget,
            QTableWidget,
            QTableWidgetItem,
            QTreeWidget,
            QTreeWidgetItem,
            QGraphicsView,
            QGraphicsScene,
            QGraphicsItem,
            QGraphicsEllipseItem,
            QGraphicsLineItem,
            QGraphicsTextItem,
            QMessageBox,
            QFileDialog,
            QMenu,
        )

        QT_BINDING = "PySide6"
except ImportError:
    from PyQt5.QtCore import *        # noqa: F401,F403
    from PyQt5.QtGui import *         # noqa: F401,F403
    from PyQt5.QtWidgets import *     # noqa: F401,F403
    from PyQt5.QtCore import pyqtSignal as Signal  # noqa: F401
    from PyQt5.QtWidgets import QAction  # noqa: F401
    QT_BINDING = "PyQt5"

QT_AVAILABLE = QT_BINDING is not None


_STOP_BUTTON_STYLE_PROPERTY = "_idassist_stop_button_base_stylesheet"
STOP_BUTTON_STYLESHEET = """
QPushButton {
    background-color: #ff6b6b;
    color: white;
    border: 1px solid #e85a5a;
    border-radius: 4px;
}
QPushButton:hover {
    background-color: #ff5c5c;
}
QPushButton:pressed {
    background-color: #e85a5a;
}
QPushButton:disabled {
    background-color: #d98c8c;
    color: #f5f5f5;
}
""".strip()

don't forget about bottom part of that file...

IDA is analysing the input file...
You may start to explore the input file right now.
PySide has not been widely tested on Python >= 3.14; IDA cannot guarantee that it will function as expected.
 INFO: provider_type column already exists, skipping migration
 DEBUG: reasoning_effort column already exists, skipping migration
 INFO: LiteLLM columns already exist, skipping migration
 DEBUG: timeout column already exists, skipping migration
 DEBUG: command column already exists on mcp_providers
 DEBUG: args column already exists on mcp_providers
 DEBUG: env column already exists on mcp_providers
 DEBUG: cwd column already exists on mcp_providers
 INFO: Successfully created oauth_credentials table
 INFO: Provider type name migration: no providers needed updating
 INFO: bypass_proxy column already exists, skipping migration
 ERROR: Failed to init Explain tab: cannot import name 'QObject' from 'src.qt_compat' (C:\Users\Administrator\AppData\Roaming\Hex-Rays\IDA Pro\plugins\IDAssist\src\qt_compat.py)
 ERROR: Failed to init Query tab: cannot import name 'QDateTime' from 'src.qt_compat' (C:\Users\Administrator\AppData\Roaming\Hex-Rays\IDA Pro\plugins\IDAssist\src\qt_compat.py)
 ERROR: Failed to init Actions tab: cannot import name 'QObject' from 'src.qt_compat' (C:\Users\Administrator\AppData\Roaming\Hex-Rays\IDA Pro\plugins\IDAssist\src\qt_compat.py)
 ERROR: Failed to init Semantic Graph tab: cannot import name 'QPointF' from 'src.qt_compat' (C:\Users\Administrator\AppData\Roaming\Hex-Rays\IDA Pro\plugins\IDAssist\src\qt_compat.py)
 ERROR: Failed to init SymGraph tab: cannot import name 'QObject' from 'src.qt_compat' (C:\Users\Administrator\AppData\Roaming\Hex-Rays\IDA Pro\plugins\IDAssist\src\qt_compat.py)
 ERROR: Failed to init RAG tab: cannot import name 'QObject' from 'src.qt_compat' (C:\Users\Administrator\AppData\Roaming\Hex-Rays\IDA Pro\plugins\IDAssist\src\qt_compat.py)
 ERROR: Failed to init Settings tab: cannot import name 'QObject' from 'src.qt_compat' (C:\Users\Administrator\AppData\Roaming\Hex-Rays\IDA Pro\plugins\IDAssist\src\qt_compat.py)
 DEBUG: Resolved binary hash from stored IDB input SHA-256
 INFO: Binary context initialized (hash: cf7a6211902596c9...)
 INFO: IDAssist panel created with all tabs

1. How VoIP works in this game

The basic flow seems to be:

VoIP phone
↓
generates phone connection traffic over udp/5060
↓
voip-server accepts accept-voip-phone-connection
↓
voip-server converts it into stream-voice
↓
customer/user consumes stream-voice

Important point: the customer who wants stream-voice does not need a phone next to them.

The phone is needed by the VoIP server as the source of accept-voip-phone-connection.

2. What you need

Minimum setup:

1. A server with voip-server installed
2. A domain, for example voip.net
3. DNS mapping voip.net to the VoIP server
4. A VoIP phone generating udp/5060 traffic
5. Routing for udp/5060 toward the voip-server

Example:

@core-voip = VoIP server
@core-dns  = DNS server
voip.net   = stream-voice service domain

DNS example:

dns map voip.net @core-voip on @core-dns

If the game requires registering a domain with a provided use, make sure the domain provides:

stream-voice

3. Trace is not enough

This may work:

trace voip.net from @floor1/phone with udp/5060

But that only proves that a route exists.

It does not always prove that the real VoIP phone traffic is being consumed by the server.

You can have this situation:

trace works
voip-server sees udp/5060 packets
but stream-voice is still not produced

Check the VoIP server with:

dstat @core-voip

If you see something like:

 = 10
voip-server load: 0/10

then the server is ready to accept phone connections, but it is not receiving valid active phone usage yet.

4. Best setup without VLANs

Before VLANs are unlocked, the cleanest approach is to build a separate physical network for VoIP phones.

Recommended layout:

VoIP phones → voice switch → @core-voip

customers/users → normal network → core-router → @core-voip

So @core-voip can have two sides:

port0 = normal customer/user network
port1 = dedicated VoIP phone network

This is the closest substitute for VLANs early in the campaign.

5. If the phone is on a normal floor network

Assume:

@floor1/router port2 = uplink to core/backbone
@floor1/router port3 = local floor switch
@core-router port0   = backend/core where @core-voip is located

On the floor router where the phone exists, add:

route add traffic udp/5060 via port2 on @floor1/router using @dbg

Do not rely only on a destination-based route like:

route add @core-voip traffic udp/5060 via port2 ...

Why? Because VoIP phone traffic is broadcast-based and may not yet have @core-voip as its destination.

A better rule is:

route add traffic udp/5060 via port2 on @floor1/router using @dbg

6. On the core router

If @core-voip is behind port0, add:

route add traffic udp/5060 via port0 on @core-router using @dbg

Also add a normal route to the VoIP server:

route add @core-voip via port0 on @core-router using @dbg

Example core-router setup:

route add @floor1/ via port4 on @core-router using @dbg
route add @floor2/ via port5 on @core-router using @dbg
route add @core-voip via port0 on @core-router using @dbg
route add traffic udp/5060 via port0 on @core-router using @dbg

7. Be careful with broadcast

This is the main trap.

If you use:

route enable broadcast on @core-router

VoIP may start working, but you can easily create a:

broadcast storm

Symptoms:

high network load
random timeouts
DNS/DHCP instability
VoIP works, but the whole network becomes unstable

General rule:

drop broadcast on the main network
use a separate VoIP path, or route udp/5060 very carefully

8. Pro tip: default drop + enable broadcast

Some players use this trick:

route default drop on @router using @dbg
route enable broadcast on @router using @dbg
route add traffic udp/5060 via portX on @router using @dbg

The idea:

broadcast is enabled,
but there is no default port for it to leak through,
so only explicitly routed udp/5060 goes out.

Downside: with default drop, you must manually define routes for everything else:

DNS
DHCP
VoIP
traffic to core
local prefix traffic
other services

It can work, but it becomes annoying to maintain without VLANs.

9. Common mistakes

Mistake 1: Route to @core-voip, but no udp/5060 traffic route

This alone may not be enough:

route add @core-voip via port0

Also add:

route add traffic udp/5060 via port0

Mistake 2: Destination-based VoIP route only

For broadcast VoIP traffic, this is often better:

route add traffic udp/5060 via port0

than this:

route add @core-voip traffic udp/5060 via port0

Mistake 3: Broadcast drop blocks the phone

If the VoIP phone is on a floor network and broadcast is dropped, stream-voice may never be created.

Test:

route enable broadcast on @floor1/router using @dbg

If stream-voice appears after enabling broadcast, the issue is confirmed.

But do not leave broadcast open everywhere, because it can cause a storm.

Mistake 4: Phone behind a router instead of a switch

VoIP phones are better placed behind a switch:

phone → switch → core/voip

rather than:

phone → router → router → core

Routers can mishandle the phone broadcast traffic.

Mistake 5: Confusing accept-voip-phone-connection with stream-voice

On the VoIP server, you may see:

accept-voip-phone-connection = 10

That does not mean customers are receiving stream-voice.

It means the server has capacity to accept phone connections. stream-voice appears only when the phone actually provides the connection.

10. Debugging checklist

Step 1: Check DNS

dns show on @core-dns

You should see:

voip.net → @core-voip

Step 2: Trace from the phone

trace voip.net from @floor1/phone with udp/5060

It should reach:

@core-voip

Step 3: Trace from the customer

trace voip.net from @floor2/customer with udp/5060

It should also reach:

@core-voip

Step 4: Watch the VoIP server

watch @core-voip

or:

dstat @core-voip

Look for:

voip-server load
accept-voip-phone-connection
stream-voice
network load
udp/5060

If udp/5060 reaches the server but voip-server load stays 0/10, the packets are reaching the machine but are not being consumed as valid VoIP usage.

11. Recommended early-game setup

Without VLANs, I recommend:

Normal network:
customers → floor router → core-router → @core-voip port0

Voice network:
VoIP phones → voice switch → @core-voip port1

On the main routers:

route drop broadcast on @floor1/router using @dbg
route drop broadcast on @floor2/router using @dbg
route drop broadcast on @core-router using @dbg

Keep VoIP broadcast outside the main network on a dedicated physical switch/path.

12. After VLANs are unlocked

Then you can do it properly:

VLAN voice = VoIP phones
VLAN users = customers/users
VLAN infra = DNS/DHCP/routers

Example idea:

vlan tag port1 with #voice on @msw
vlan tag port2 with #users on @msw
vlan tag port3 with #voice #users on @msw

Then VoIP broadcast stays inside the voice VLAN and does not flood the whole network.

Conclusion

VoIP in this game needs a different mindset than DNS or HTTP.

Key rules:

1. VoIP phone traffic is broadcast udp/5060.
2. voip-server converts phone connection into stream-voice.
3. A route to @core-voip alone is not enough.
4. You must handle udp/5060 as a traffic type.
5. Broadcast can easily cause a storm.
6. Without VLANs, use a separate physical VoIP network.

Best early-game architecture:

VoIP phones on a dedicated switch
normal customers on the normal network
@core-voip as the meeting point
no VoIP broadcast through the core-router

first check logs using

docker logs -f --tail 50 hassio_supervisor

check for output like

istant%2Fqemuarm-homeassistant&platform=linux%2Farm64: Internal Server Error ("Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io: no such host")
2025-03-31 15:48:12.252 WARNING (MainThread) Failed to install landingpage, retrying after 30sec
2025-03-31 15:48:42.255 INFO (MainThread) Downloading docker image ghcr.io/home-assistant/qemuarm-homeassistant with tag landingpage.
2025-03-31 15:48:42.272 ERROR (MainThread) Can't install ghcr.io/home-assistant/qemuarm-homeassistant:landingpage: 500 Server Error for http+docker://localhost/v1.45/images/create?tag=landingpage&fromImage=ghcr.io%2Fhome-assistant%2Fqemuarm-homeassistant&platform=linux%2Farm64: Internal Server Error ("Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io: no such host")
2025-03-31 15:48:42.272 WARNING (MainThread) Failed to install landingpage, retrying after 30sec

this is DNS error issue, and how to fix it?

type:

sudo rm /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
systemctl enable systemd-resolved
systemctl restart systemd-resolved

wait a few minutes and check, if it still doesn't work then edit the /etc/resolv.conf file and add e.g. 8.8.8.8

it is a type of exchange of public keys and entering them into the Admin Key fields between nodes

Not working? remove (from admin perspective) managed node from node list, and wait for reappear, restart nodes.

Tip: You can set same Public key and Private key on each node (then Public Key an Admin Key will be same values, don't forget to copy prv key)

Tip: Admin key is public key of managed node (or node, admin node), it means "allow manage by admin that identifies by that public key"

Why These Changes Matter

Meshtastic has always been about open communication and the free exchange of data across a wide network of nodes. The ability to share GPS locations and other telemetry data via MQTT servers has been a cornerstone of the system’s functionality. However, with the new restrictions in place, the default MQTT server is no longer as versatile as it once was.

Under the zero-hop policy, the system’s capacity to relay information across multiple nodes has been severely limited. This, combined with the decision to restrict access to telemetry data, has made the default server less effective for users who previously depended on it for essential data. While it was initially believed that these restrictions would prevent users from subscribing to the general msh/# channel, which covers all data, it turns out that users can still subscribe to specific channels such as msh/DE/2/e/LongFast/ or msh/CZ/2/map/. Although this does limit the range of data available, it still allows for targeted listening.

Additionally, it is important to note that, as of now, the transmission of neighbour information or other data beyond a user's own data is no longer available. This change prevents users from conducting terrain analysis and utilizing telemetry for broader network management.

The Solution: Transition to Private Servers

Given these changes, it’s clear that the community must adapt by switching to private MQTT servers. By transitioning to private servers, users can regain control over their data and maintain the functionality that drew them to Meshtastic in the first place. This move also empowers the community to preserve the flexibility and openness that are core to the Meshtastic philosophy.

Final Thoughts

While the decisions by the administrators may have been made with the best intentions, the reality is that they have limited the utility of the default server. For those who value the ability to freely share and access telemetry data, switching to a private MQTT server is not just an option—it’s a necessity. Even though the ability to listen to broad channels has been restricted, the option to subscribe to specific channels still offers some functionality. As the community adapts to these changes, it’s important to stay informed and proactive in finding solutions that meet our collective needs.

Meshtastic alternative MQTT servers:

• Address: mqtt.meshnet.nl
• Username: boreft
• Password: meshboreft
• Website: meshnet.nl/nederland-map.html
• Primary target: Netherlands

• Address: mqtt.meshtastic.liamcottle.net
• Username: uplink
• Password: uplink
• Website: meshtastic.liamcottle.net
• Primary target: Global

• Address: loranet.pl
• Username: no username
• Password: no password
• Website: loranet.pl
• Primary target: Poland

1. Channels
   • LongFast
     • Uplink Enabled = ON
2. Device
   • Role = Client
   • NodeInfo broadcast interval = 3600
3. Position (for stationary device, mobile? jump to point 4.)
   • Position broadcast interval = 900
   • GPS Mode Enabled = False
   • Smart position enabled = False
   • Use fixed position = True
   • Latitude = type latitude for node location
   • Longitude = type longitude for node location
4. Position (for mobile device, stationary? jump to point 3.)
   • Position broadcast interval = 900
   • GPS Mode Enabled = True
   • Smart position enabled = True
   • Use fixed position = False
   • GPS update interval seconds = 120
5. LoRa
   • Use mode preset = True
   • Mode preset = LONG_FAST
   • Region (frequency plan) = EU_868 
   • Hop limit = 7
   • TX enabled = True
   • TX power = 27 
   • Frequency slot = 1
   • Override Duty Cycle = True
   • SX126X RX boosted gain = True
   • Ignore MQTT = True 
   • OK to MQTT = True (2.5.x, allow to spread telemetry accros other nodes )
6. MQTT
   • MQTT Enabled = True
   • JSON output enabled = True
   • Root topic = msh/pl (for Poland, or msg/cz for Czech, msg/EU_868 for EU etc.)
   • Map reporting = HIGH_PRECISION (or any other)
7. Store & Forward Config 
   • Store & Forward enabled = True 
   • Heartbeat = True
8. Telemetry
   • Environment metrics module enabled = True
   • (depends on module, Tbeam Supreme etc.) Air quality metrics module enabled = True
9. Neighbor Info Config
   • Neighbor info enabled = True
   • Update interval (seconds) = 600

All settings I haven't mentioned remain unchanged.