Martian destination 0.0.0.0

ESPHome
1

I find already for a couple of months multiple of these messages in the syslog and messages files.

Aug 14 21:21:53 rpi3 kernel: [20902.701844] IPv4: martian destination 0.0.0.0 from 192.168.178.33, dev wlan0
Aug 15 21:21:53 rpi3 kernel: [23902.701844] IPv4: martian destination 0.0.0.0 from 192.168.178.30, dev wlan0

Both IP-addresses (192.168.178.3[03]) happen to be ESP32’s loaded with ESPhome and both configured as a BLE gateway.
I have over 50 or so IP components in the network, but it is these two that produce these “martian storms”.
I’m not a network expert, but all my network devices pickup the network configuration through DHCP (pihole), but for these 2 I also tried static IP, but that has no effect.
Anyone who has an idea ? Thank you, Yann

1 Like
2

What is the yaml for those esp devices (just one should do)

3 
# These substitutions allow the end user to override certain values
substitutions:
  name: "ble-gtway33"

esphome:
  name: "${name}" 
  platform: ESP32
  board: wemos_d1_mini32


# Enable logging
logger:

# Enable Home Assistant API
api:

ota:
  password: "372979d3f8d7f46f08c1daf4a4057810"

wifi:
  networks:
    - ssid: !secret wifi1_ssid 
      password: !secret wifi1_passwd
    - ssid: !secret wifi2_ssid 
      password: !secret wifi2_passwd
  domain: .lan
      # manual_ip:
      #   static_ip: 192.168.178.33
      #   gateway: 192.168.178.1
      #   subnet: 255.255.255.0

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${name} Fallback Hotspot"
    password: !secret AP_password

captive_portal:

time:
  - platform: homeassistant
  
esp32_ble_tracker:

switch:
  - platform: gpio
    name: "${name}-Onboard-LED"
    pin: 2
    inverted: True

  - platform: restart
    name: "${name}-restart"
    id: restart_switch

sensor:
  - platform: uptime
    name: "${name}-Uptime Sensor"
    
  - platform: wifi_signal
    name: "${name}-WiFi_Signal"

# watchout, different sensor, different platform
  - platform: atc_mithermometer
    mac_address: "A4:C1:38:DB:FB:2D"
    temperature:
      name: "${name}-ATC_DBFB2D_temperature"
    humidity:
      name: "${name}-ATC_DBFB2D_humidity"
    battery_level:
      name: "${name}-ATC_DBFB2D_battery_level"
    battery_voltage:
      name: "${name}-ATC_DBFB2D_voltage"
    signal_strength:
      name: "${name}-ATC_DBFB2D_signal"

  - platform: atc_mithermometer
    mac_address: "a4:c1:38:b0:08:b0"
    temperature:
      name: "${name}-ATC_B008B0_temperature"
    humidity:
      name: "${name}-ATC_B008B0_humidity"
    battery_level:
      name: "${name}-ATC_B008B0_battery_level"
    battery_voltage:
      name: "${name}-ATC_B008B0_voltage"
    signal_strength:
      name: "${name}-ATC_B008B0_signal"
4

I am seeing the same issue with two ESP32 DevKits with latest ESPHome installed with Bluetooth proxy. No customization from the defaults.

5

Is it doing harm though?

6

I would say so. The device that detects the martian messages created by the ESP-devices is running Nextcloud and this devices just freezes say every other day and the only way to bring it up again is to reset it. And in general that is not good for a system that is running a database and has open files in a filesystem.

7

Certainly that is true!

I suppose you are just assuming about the cause though. Co-incidence is not causation, although suspicion arises :slight_smile:

Any other clues in the nextcloud machine’s logs?

Try compiling a new firmware with a newer version of esphome and see if it persists.

You could also try firewalling the esp devices from the nextcloud machine.

8

Indeed for now it is co-incidence, not a prove causation. Non of my other PI’s have these martian error messages so it could be Nextcloud. But I have other ESPhome devices (being esp8266) and why do they not cause these messages. The 2x ESP’s of which I found the messages are based ESP32 (and I have only two). I did compile the firmware multiple times with different parameters but that didn’t do anything. That is why to me, the cause could be the expressive WIFI/TCP stack.
Another track is of course, why is the nextcloud system sensitive and my OMV, Wordpress, Pihole PI’s not.

9

For me to understand properly. The 2x ESP32 that are configured as a Bluetooth proxy also cause for error messages? Where?

10

Hi,

have noticed the same logs here, without nextcloud or bluetooth gateways involved.

esphome:
  name: luna-light

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:
  password: "XXX"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Luna-Light Fallback Hotspot"
    password: "XXX"

captive_portal:

light:
- platform: rgb
  name: "Luna Buntlicht"
  red: output_red
  green: output_green
  blue: output_blue

output:
- platform: ledc
  pin: GPIO21
  id: output_red
- platform: ledc
  pin: GPIO19
  id: output_green
- platform: ledc
  pin: GPIO18
  id: output_blue

logs:

[Di Okt 25 10:42:07 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 10:53:22 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 10:58:59 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 11:01:48 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 11:03:12 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 11:03:54 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 11:04:15 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 11:04:26 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 11:04:31 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 11:04:34 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot
[Di Okt 25 12:04:37 2022] IPv4: martian destination 0.0.0.0 from 192.168.2.6, dev iot

I’m not aware of anything in my network setup that could cause this. It’s only affecting one of my current two ESPHome devices, the other one is based on an ESP8266 - so maybe something ESP32 specific?

Was running on ESPHome 2022.6.2 and HomeAssistant 2022.8.0 when this was logged, just upgraded both to the latest versions.

11

Is there an ESP involved, ESP32 maybe?
Then it can also be something in the Expressif WIFI stack.

12

Did anybody ever get this solved? I’m having the same version on one of my esp32s running 2022.11 esphome

13

Not yet. I’m open for new ideas.

14

I am still seeing this with my ESP32 devices when pulling logs on my proxmox server. Has anyone resolved this?

1 Like
15

I was also seeing kernel logs like "IPv4: martian destination 0.0.0.0 from 192.168.1.220, dev eth0" on my Proxmox server where HA is hosted as a VM.

I was getting these consistently from a handful of specific IPs that were ESP devices running ESPHome. After I updated these devices running older versions of ESPHome (maybe 2023.7.x to 2023.11.x) to the near-latest 2024.7.3, I haven’t seen these “martian” logs for several hours now. Hopefully that was the culprit and I won’t see this error again. I’m guessing it was just an issue with ESPHome’s TCP/IP stack on the older versions. :crossed_fingers:

16

I spoke too soon. I’m still seeing these “martian destination 0.0.0.0” kernel messages on my Proxmox host–despite updating ESPHome devices to a newer version. In fact, I even got a message from an IP of one of my LXC containers running on my Proxmox host. So, this seems to have nothing to do with ESPHome. ;(