[BUG] Connection via Virtual Nodes no longer working

[m0urs]

Describe the bug
With 3.5.0 I am no longer able to connect to my node via the Virtual Node functionality of MeshMonitor. I tested with the orginal Android App and also with a Python BBS script I have running here. Both cannot connect with 3.5.0

Additional context
I downgraded to 3.4.13 again end everything works as expected.

[Yeraze]

CAn you share some additional information? It's working fine for me using the iOS client and meshtastic cli app

[m0urs]

What exactly do you need? I just try to connect via the Android app and the connection does not succeed. With the same setup connection works for me with 3.4.13.

[Yeraze]

Your docker compose file.. container logs.. Have you tried anything other than the Android app?

[m0urs]

Will share the log with you tomorrow.

Yes, as I said, I do have e.g. a Python BBS script running which also connects to the node via the virtual Meshmonitor node and it show the same behaviour.

My YAML file:

services:
  meshmonitor:
    # Use pre-built image from GitHub Container Registry
    #image: ghcr.io/yeraze/meshmonitor:latest
    image: ghcr.io/yeraze/meshmonitor:3.4.13
    container_name: meshmonitor
    restart: unless-stopped
    ports:
      - "3001:3001"  # Expose on port 3001 for reverse proxy
      - "4403:4404"
    volumes:
      - meshmonitor-data:/data:rw
    environment:
      - COMPOSE_PROJECT_NAME=meshmonitor
      - NODE_ENV=production
      - TZ=Europe/Berlin
      # Session Secret (REQUIRED for production)
      # Generate with: openssl rand -hex 32
      # This ensures sessions persist across container restarts
      - SESSION_SECRET=xxxxxxxxxxxxx
      # Meshtastic Node Configuration
      - MESHTASTIC_NODE_IP=192.168.4.187
      - MESHTASTIC_USE_TLS=false
      - MESHTASTIC_TCP_PORT=4403
      # Reverse Proxy Settings
      - TRUST_PROXY=true
      - ALLOWED_ORIGINS=https://meshmonitor.urspringer.de
      # Security Settings for HTTPS
      - COOKIE_SECURE=true
      - COOKIE_SAMESITE=lax
      # Virtual Node Configuration
      - ENABLE_VIRTUAL_NODE=true
      - VIRTUAL_NODE_ALLOW_ADMIN_COMMANDS=true
      # Logging
      - ACCESS_LOG_ENABLED=false
      - ACCESS_LOG_PATH=/data/logs/access.log
      - ACCESS_LOG_FORMAT=combined  # Apache Combined Log Format
      # Enable auto-upgrade functionality
      - AUTO_UPGRADE_ENABLED=true
      # Variables for scripts
      - PIRATE_WEATHER_API_KEY = "xxxxxxxxxxxxxxxxxxxx"
    deploy:
      resources:
        limits:
          # cpus: '2.0'
          memory: 512M
        reservations:
          # cpus: '0.5'
          memory: 256M      

  # Upgrade watchdog sidecar
  meshmonitor-upgrader:
    image: docker:24.0.2
    container_name: meshmonitor-upgrader
    restart: unless-stopped
    volumes:
      # Docker socket for container control
      - /var/run/docker.sock:/var/run/docker.sock
      # Shared data volume to monitor trigger file and access upgrade script (rw for status file)
      - meshmonitor-data:/data
      # Mount docker-compose directory for proper recreation
      - .:/compose:ro
    environment:
      - CONTAINER_NAME=meshmonitor
      - IMAGE_NAME=ghcr.io/yeraze/meshmonitor
      - TRIGGER_FILE=/data/.upgrade-trigger
      - STATUS_FILE=/data/.upgrade-status
      - CHECK_INTERVAL=5
      - COMPOSE_PROJECT_DIR=/data/compose
      - COMPOSE_PROJECT_NAME=meshmonitor
    command: /data/scripts/upgrade-watchdog.sh
    depends_on:
      - meshmonitor
    # networks:
    #   - default
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  meshmonitor-data:
    driver: local
    driver_opts:
      o: bind
      type: none
      device: /volume1/docker/meshmonitor/data
  

[Yeraze]

And your script/app is connecting to meshmonitor:4403 ?

Are you getting a connection refused? Timeouts? Starts to connect and never completes?

[madeofstown]

After updating to 3.5.0 yesterday Meshmonitor won't even connect to my node. The trick of restarting both Meshtasticd and Meshmonitor and waiting 10 minutes didn't work this time. This morning it still was saying it won't connect. Meshtasticd logs are showing that the connection is dropped after trying to configure module 14. This is Meshtasticd version 2.7.19.

INFO  | 05:47:55 1754 [ApiServer] Force close previous TCP connection
INFO  | 05:47:55 1754 [ApiServer] Incoming API connection
INFO  | 05:47:55 1754 [ApiServer] Incoming wifi connection
INFO  | 05:47:55 1754 [ServerAPI] Client wants config, nonce=4294967295
INFO  | 05:47:55 1754 [ServerAPI] Start API client config millis=1754710
INFO  | 05:47:55 1754 [ServerAPI] getFromRadio=STATE_SEND_UIDATA
ERROR | 05:47:55 1754 [ServerAPI] Unknown module config type 14
INFO  | 05:47:55 1754 [ServerAPI] Config Send Complete millis=1754731
INFO  | 05:47:55 1754 [ServerAPI] Lost phone connection
INFO  | 05:47:55 1754 [ServerAPI] Client dropped connection, suspend API service

[madeofstown]

I was able to fix this by backing up my config settings with the Meshtastic CLI then factory resetting the node and restoring the config.

[Yeraze]

So... Module 14 is the new StatusMessage package, it looks like your node with new firmware supports it but meshtasticd doesn't.

Can you describe your setup? Are you using a linux node, pi hat, something like that?

[madeofstown]

Yeah, I am using a Raspberry Pi 4 with a LoRa HAT. Meshtasticd does still show the module 14 error in the logs but allows the connection anyway.

[Yeraze]

I'm not entirely sure waht would be throwing that error, but I'm not all that familiar with the Pi Hat+meshtasticd system.. 3.5.0 shouldn't even be requesting Module 14 (a bug I just fixed), so I'm not sure what's throwing that.

Glad you found a fix. It almost sounds like the node had a buggy configuration. Maybe it had a 2.7.15 style configuration that wasn't fully compatible with the new 2.7.19 modules and that was causing the issues?

[madeofstown]

I'm not entirely sure waht would be throwing that error, but I'm not all that familiar with the Pi Hat+meshtasticd system.. 3.5.0 shouldn't even be requesting Module 14 (a bug I just fixed), so I'm not sure what's throwing that.

Glad you found a fix. It almost sounds like the node had a buggy configuration. Maybe it had a 2.7.15 style configuration that wasn't fully compatible with the new 2.7.19 modules and that was causing the issues?

That's my assumption as well. I think I need to wipe Meshtasticd and completely re-install. It's been running since early v2.6 without a refresh.