Netatmo HomeKit native devices, not able to update iOS Home app when isolated (but work online/using Netamo app)

Hi,
fllowing this thread and thank to @spence help, now I finally went able to have a different/separated subnet for the IoT devices that are running on Homebridge/homekit with normal speed and the devices on this subnet aren't able to browse my "main LAN", like the Guest LAN but with the mDNS reflector enabled from the Homebridge server (I had to create a new routing table in the main router to set it to work, without the new routing table, HomeKit wasn't able to find/reply to the devices across the subnets), this rule if can help someone:

config route
	option interface 'lan'
	option gateway '192.168.1.3'
	option source '192.168.1.2'
	option target '192.168.5.0/24'

(where .1.3 is the AP, .1.2 is the router, and .5.0/24 is the 'iot subnet')

Ok, but not all are working!

The two HomeKit native devices, two Netatmo devices (thermostat and weather station) are reachable via internet but not via Home app, I can't understand why.

At the beginning both were not reachable also from the Netatmo app or online, so I searched on the Netatmo and I've found this: https://helpcenter.netatmo.com/en-us/smart-thermostat/connection-wi-fi-radio/advanced-network-troubleshooting-guide

Please check if your router has any firewall / port filtering. If so:

  • Open the 25050 port (TCP).
  • Assign the Wi-Fi module a static IP with its Mac address.

so...

config rule
	list proto 'tcp'
	option src 'iot'
	option src_port '25050'
	option dest_port '25050'
	option target 'ACCEPT'
	option name 'Netatmo'
	option dest 'lan'

...and the Thermostat and Station are connected and I can control them via Netatmo app or website BUT not from HomeKit! I don't know what's going on with Apple protocols.

Netatmo website/app
Screenshot 2023-01-22 at 11.02.47

HomeKit (same for the Weather station)
Screenshot 2023-01-22 at 11.03.52

These are the the mDNS queries, so they are "visible" in the network:

_hap._tcp                                       PTR     Netatmo\032Relay\032(2)._hap._tcp
Netatmo\032Relay\032(2)._hap._tcp               SRV     0 0 5001 Netatmo\032Relay-2.local. ; Replace with unicast FQDN of target host
Netatmo\032Relay\032(2)._hap._tcp               TXT     "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay" "id=xx:xxxx:30:BF:3C" "na_tkn=cba8" "ci=2" "sh=LJ/KDg=="

_hap._tcp                                       PTR     Weather\032Station\032(2)._hap._tcp
Weather\032Station\032(2)._hap._tcp             SRV     0 0 5001 Weather\032Station-8.local. ; Replace with unicast FQDN of target host
Weather\032Station\032(2)._hap._tcp             TXT     "c#=11" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Weather Station" "id= xx:xxxx:F7:45:43:B8" "na_tkn=806e72" "ci=2" "sh=PQgp5A=="

So I have no idea how to debug this. Anyone have a suggestion to start? I don't know, a port, a protocol, what can be? Both the devices have a static IP, I can ping and see them, they are reachable and are communicating online but not with HomeKit (funny since they are HomeKit native).

thanks a lot!

Have you tested accessing the devices from a client while connected to the same network?

Is the router the only device that has to reach this network?

Yes but is the same, these 2 Netatmo devices aren't communicating.

Yes, but these two devices are online, I can see the temperature and set my thermostat via Netatmo webpage or app, only in HomeKit they appear as "no response" when I put them in the iot LAN interface.

When I assign to the iot WLAN the iot interface, in order to have them isolated on another subnet, I simply don't see any mDNS packet from the Netatmo devices, they are connected to WLAN, and they are working to send data to the Netatmo servers but not as mDNS inside the LAN.

I don't know, my thought is that, since is the Homebridge server that is sending the mdns discovery queries, and these device aren't on another subnet, then for some reasons they can't find the Homebridge server!
...but all the other iot devices in the same iot subnet, are able to discovery it. So my guess is that those Netatmo devices are using different settings to communicate.I have no idea.

I'm trying to doing some debug but those Netatmo devices are very weird:

I deleted all the setting from the weather station (WS I'll call it), I joined the 'Netatmo' interface (same as the 'iot', only with another name to debug it) with my iPad, configured the WS from scratch, all is gone well and the WS was working but I was unable to add it to HomeKit in the standard way:

So I bridged the 'Netatmo' interface to the main LAN and I downloaded the Netatmo app to connect it. But the station is unable to connect to the servers, also with the Netatmo interface bridged to LAN. Indeed if I join this network with my iPad I'm able to browse everything (also my main LAN).

This makes no sense.

Obviously I tried to use every (normal) DNS but is the same.

Updates will follow :frowning: nobody has some Netatmo products on a separated VLAN/WLAN? :frowning:

That network config does not look valid to me. The address and gateway need to be in the same address range defined by the network mask. Of course the gateway needs to match what is used on the router.

When the netatmo device is on a new isolated routed network (192.168.6.0/24) both the address and gateway need to be within 192.168.6.1 - 192.168.6.254.

When the netatmo device is bridged to the main LAN (192.168.1.0/24) both the address and gateway need to be within 192.168.1.1 - 192.168.1.254.

1 Like

Correct but when I entered the correct gateway "192.168.6.1" the reply was "this gateway is not correct", anyway I corrected a firewall rule and now it's working but as always not inside HomeKit. But there are tons of weird behaviors with this weather station, another is that if I configure the wifi using iOS, when I select "share wifi setting" it says "the password is not correct"... but I'm connected in the same SSID... or I get weird random errors, the only way I have to configure the wifi now, is with the cable connected to the Mac

:unamused: :face_with_symbols_over_mouth:

So I tried to reset the station, and now I'm not able to add again to homekit because I forgot to delete the station before resetting it... i'm going crazy. I think those device will stay on a normal WLAN -> LAN because otherwise they're a mess with HomeKit. They're working normally via web but not via HomeKit, at least in my network.

Because I discovered that this station is not HomeKit "native", they have added the HomeKit support with a firmware upgrade, the app generated the HomeKit code one time only (I still have the code fortunately) but the normal setup to add it to home doesn't work. You have to do it via the Netatmo app, but since the app detects that I've already added to my Home...now it isn't prompting to add it again to HomeKit!

I'm going crazy and I think I will have to complete reset my Home to re add it :weary:

Absurd...

This may be a an issue specific to netatmo. I understand that you might ask here in case someone has the experience and can help but you might need to contact netatmo support to find out how, if it is possible.

1 Like

Yes yes absolutely, no problem and thanks for the help! This is a Netatmo issue but the "stuff/behavior" that is doing when I use the Netatmo devices on a separated subnet, I don't know if it's only related to Netatmo or is something with the network/mDNS/etcc..

Because the thermostat it's a native HomeKit device, and every time I put it inside the Netatmo network, it stops work with HomeKit, but it works perfectly via web or app (well the app is web view...). But I can reach the station (and also other accessories) inside this subnet... so it's something with Apple protocol/Bonjour.

Okay, finally I managed how to reset this absurd Weather Station. It has touch top, you have to keep it pressed untill it will flash red fast, it was flashing, after it turn off and on again.

But is not resetted :rofl: damn, you have to release the "top" when it's flashing red and press one time to confirm that you are resetting it... absurd since it flash for 2-3 seconds only, I don't know who designed this complicated interaction, anyway...

Press and hold the top of the Station until it flashes red. Press once to confirm. The Station will then turn solid red. It will restart and flash blue (https://helpcenter1.inte.netatmo.com/hc/en-us/articles/360010066720-How-do-I-reset-the-Station-Apple-HomeKit-procedure-)

Now it has generated a new HomeKit code and blablabla, I'm at the beginning point again and I will not change the Netatmo devices configs since it's not the issue here but is something related to OpenWrt/firewall/routing/mdns/whatever.

Now my network is this, except for the IoT zone because if I put the Netatmo devices inside it, they will not work/respond inside Home app (everywhere else they're working).

So -only to debug- I created another WLAN called Netatmo only for these 2 devices, and I created also another network interface with ip 192.168.6.1), another firewall zones and obviously I duplicated the 'iot' rules to 'netatmo' rules. Because in this way I'm able to debug these two stupid devices without messing with the iot devices.

The interfaces:

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option gateway '192.168.1.2'
	option ipaddr '192.168.1.3'

config interface 'guest'
	option proto 'static'
	list ipaddr '192.168.3.1/24'
	list dns '192.168.1.4'

config interface 'iot'
	option proto 'static'
	list dns '192.168.1.4'
	list ipaddr '192.168.5.1/24'

config interface 'Netatmo'
	option proto 'static'
	option ipaddr '192.168.6.1'
	list dns '192.168.1.4'
	option netmask '255.255.255.0'

And the issue with the WLAN, if I assign Netatmo WLAN to the Netamo zone, or iot zone (where it should be) they should stay, the devices stop responding inside Home app, everywhere else they are working, via web/app/ping ecc..

config wifi-iface 'default_radio0'
	option device 'radio0'
	option mode 'ap'
	option key ''
	option ssid 'Magnifico_IoT'
	option network 'iot'
	option encryption 'sae-mixed'

config wifi-iface 'wifinet4'
	option device 'radio0'
	option mode 'ap'
	option ssid 'Netatmo'
	option key ''
	option network 'lan' #### when assigned to Netatmo, devices aren't responding from HomeKit ####
	option encryption 'sae-mixed'

The firewall are are tons of rules (because I duplicated some of them obviously)

Summary

root@WAX206:~# cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	list network 'lan'

config zone
	option name 'guest'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'guest'

config forwarding
	option src 'guest'
	option dest 'lan'

config rule
	option name 'Guest DHCP'
	list proto 'udp'
	option src 'guest'
	option dest_port '67-68'
	option target 'ACCEPT'

config rule
	option name 'Guest DNS'
	option src 'guest'
	option dest_port '53'
	option target 'ACCEPT'

config rule
	option name 'Block guest LAN'
	option src 'guest'
	option dest 'lan'
	option target 'DROP'
	list proto 'all'
	list dest_ip '192.168.1.0/24'

config zone
	option name 'iot'
	option output 'ACCEPT'
	option input 'REJECT'
	option forward 'REJECT'
	list network 'iot'
	list subnet '192.168.5.1/24'

config forwarding
	option src 'iot'
	option dest 'lan'

config rule
	option src 'iot'
	option dest_port '53'
	option target 'ACCEPT'
	option name 'IoT allow DNS'

config rule
	option target 'ACCEPT'
	option src 'iot'
	option name 'IoT port 80'
	list proto 'tcp'
	list proto 'udp'
	option src_port '80'

config rule
	option dest_port '443'
	option target 'ACCEPT'
	option src 'iot'
	option name 'IoT port 443'

config rule
	option dest_port '5353'
	option target 'ACCEPT'
	option src_port '5353'
	option src 'iot'
	list proto 'udp'
	option dest 'lan'
	option name 'IoT mDNS port 5353'
	list dest_ip '224.0.0.251'
	list dest_ip 'ff02::fb'

config rule
	list proto 'tcp'
	option src 'iot'
	option src_port '25050'
	option dest_port '25050'
	option target 'ACCEPT'
	option dest 'lan'
	option name 'Netatmo port 25050'

config rule
	option target 'ACCEPT'
	option src_port '51826-51827'
	option dest_port '51826-51827'
	option src 'iot'
	option dest 'lan'
	option name 'HomeKit connectivity'

config rule
	option src 'iot'
	option dest 'lan'
	option target 'DROP'
	list dest_ip '192.168.1.0/24'
	option name 'Block IoT to LAN'
	list proto 'all'

config rule
	option name 'LAN to IoT'
	option src 'lan'
	option target 'ACCEPT'
	option dest 'iot'
	list proto 'all'

config zone
	option name 'Netatmo'
	option output 'ACCEPT'
	list network 'Netatmo'
	option input 'REJECT'
	option forward 'REJECT'

config forwarding
	option src 'Netatmo'
	option dest 'lan'

config rule
	option src 'Netatmo'
	option dest_port '53'
	option target 'ACCEPT'
	option name 'Netatmo allow DNS'

config rule
	option dest_port '443'
	option target 'ACCEPT'
	option src 'Netatmo'
	option name 'IoT port 443'

config rule
	option dest_port '5353'
	option target 'ACCEPT'
	option src_port '5353'
	option src 'Netatmo'
	list proto 'udp'
	option dest 'lan'
	option name 'Netatmo mDNS port 5353'
	list dest_ip '224.0.0.251'
	list dest_ip 'ff02::fb'

config rule
	option target 'ACCEPT'
	option src_port '51826-51827'
	option dest_port '51826-51827'
	option src 'Netatmo'
	option dest 'lan'
	option name 'HomeKit connectivity'

config rule
	option name 'LAN to Netatmo'
	option src 'lan'
	option target 'ACCEPT'
	option dest 'Netatmo'
	list proto 'all'

config rule
	option name 'Netatmo DHCP'
	list proto 'udp'
	option src 'Netatmo'
	option dest_port '67-68'
	option target 'ACCEPT'

config rule
	option name 'Block Netatmo to LAN'
	option src 'Netatmo'
	option dest 'lan'
	option target 'DROP'
	list proto 'all'
	list dest_ip '192.168.1.0/24'

config rule
	option name 'Netatmo port 80'
	option src 'Netatmo'
	option src_port '80'
	option target 'ACCEPT'

config rule
	option name 'Netatmo 25050'
	list proto 'tcp'
	option src 'Netatmo'
	option src_port '25050'
	option dest_port '25050'
	option target 'ACCEPT'

How to solve or debug this? When the devices are inside the main LAN I can find and trace the normal mdns/arp packets via wireshark, when they are inside the Netatmo or iot interface, they disappear from my network, also if I join the netatmo WLAN with my Mac and I search for packets using the wireless antenna to capture traffic. Looks like they are death. I don't know what else I can do.

And thanks in advice!

For clarity:
When you move the Netatmo devices to a different SSID/network by changing settings on the WAX206 do the Netatmo devices change their network config properly?

If not, or you are not sure, then reset/power cycle the Netatmo units or maybe shut down the wifi radio for a minute to trigger a reassociation and DHCP update.
.
.
Info/ideas for more debug:

Get into packet / traffic analysis. If your AP is the WAX206, I assume that has a hardware switch and some local traffic won't hit the cpu interface so visibility of some traffic won't be available there.
If you have client isolation enabled on the wifi, then as far as I know, you won't see unicast traffic on your Mac other than traffic to/from the Mac with the Mac connected to that SSID.

For seeing traffic you expect to see between the Netatmo devices in network .6.0/24 and the Home (hub/bridge?) in network .1.0/24 try a capture on the L2 interface on the AP with the Ethernet MAC address of the Netatmo device instead of the IP address for it.

Something like:
tcpdump -nn -e -i wifinet4 ether host 70:EE:50:40:30:20
( use correct interface and Netatmo device MAC )
See what shows up. It may be revealing to do this while initializing (rebooting) the Netatmo device(s) once you determine the appropriate interface etc. Capture to a file and analyze in wireshark if need be.

You can watch both Netatmo devices at the same time in one log with an or between the two MACs in the ether host filter expressions:
tcpdump -nn -e -i wifinet4 ether host 70:EE:50:40:30:20 or 70:EE:50:60:50:40

Getting a capture point in between devices when it works (on the same LAN including all the node initialization and Home discovery etc and then repeating it all in the broken state should at least show what is different and hopefully lead to a fixing change.

Devise and implement a capture on the LAN (.1.0/24) side to verify that your implementation to route through the R4S is working as intended. You may assume that because non-Home traffic works that your routing setup works but actually watch it to find out.
Probably capture on both the R4S and WAX206 simultaneously. Capturing with a port mirror on the switch is a possibility as well.

I know most of the communication may be encrypted but correlation of packet flows with timestamps of events, like you triggering a discovery or a reset, should point out the differences in communications.

Tedious and possibly a lot to learn along the way.
Been there - done that for 40 hours straight!

1 Like

Million dollar question :smiley: I have no idea of what they're doing, this is the main, I'm sure that when they are inside the 192.168.1.0 subnet they work locally and remotely, when I put them in the 192.168.6.0 subnet they're sending data outside the network but not the classic ARP/mDNS packets,

A 10secs capture when the Netamo device are assigned to LAN (all normal)

root@WAX206:~# tcpdump -nn -e -i br-lan ether host 70:EE:50:65:73:8a
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:07:40.942978 72:55:73:33:98:bf > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 78: 20.86.150.173.25050 > 192.168.1.150.52730: Flags [P.], seq 2240388473:2240388497, ack 4173017290, win 65535, length 24
22:07:40.948059 70:ee:50:65:73:8a > 72:55:73:33:98:bf, ethertype IPv4 (0x0800), length 147: 192.168.1.150.52730 > 20.86.150.173.25050: Flags [P.], seq 1:94, ack 24, win 2664, length 93
22:07:40.980191 72:55:73:33:98:bf > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 60: 20.86.150.173.25050 > 192.168.1.150.52730: Flags [.], ack 94, win 65535, length 0
22:07:42.803550 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.2 tell 192.168.1.150, length 28
22:07:42.803894 72:55:73:33:98:bf > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 60: Reply 192.168.1.2 is-at 72:55:73:33:98:bf, length 46
22:07:47.937674 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.2 tell 192.168.1.150, length 28
22:07:47.938003 72:55:73:33:98:bf > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 60: Reply 192.168.1.2 is-at 72:55:73:33:98:bf, length 46
22:07:53.043825 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.2 tell 192.168.1.150, length 28
22:07:53.044177 72:55:73:33:98:bf > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 60: Reply 192.168.1.2 is-at 72:55:73:33:98:bf, length 46
22:07:55.962956 72:55:73:33:98:bf > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 78: 20.86.150.173.25050 > 192.168.1.150.52730: Flags [P.], seq 24:48, ack 94, win 65535, length 24
22:07:55.965582 70:ee:50:65:73:8a > 72:55:73:33:98:bf, ethertype IPv4 (0x0800), length 147: 192.168.1.150.52730 > 20.86.150.173.25050: Flags [P.], seq 94:187, ack 48, win 2640, length 93
22:07:55.997426 72:55:73:33:98:bf > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 60: 20.86.150.173.25050 > 192.168.1.150.52730: Flags [.], ack 187, win 65535, length 0
22:07:58.095754 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.2 tell 192.168.1.150, length 28
22:07:58.096082 72:55:73:33:98:bf > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 60: Reply 192.168.1.2 is-at 72:55:73:33:98:bf, length 46
22:07:58.807119 70:ee:50:65:73:8a > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 329: 192.168.1.150.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/6 PTR Weather Station._hap._tcp.local. (287)
22:07:58.808057 70:ee:50:65:73:8a > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 349: fe80::72ee:50ff:fe65:738a.5353 > ff02::fb.5353: 0*- [0q] 1/0/6 PTR Weather Station._hap._tcp.local. (287)
22:07:58.812355 e4:5f:01:b3:3a:8d > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 74: 192.168.1.5.37376 > 192.168.1.150.5001: Flags [S], seq 2347416178, win 64240, options [mss 1460,sackOK,TS val 1586155469 ecr 0,nop,wscale 7], length 0
22:07:58.813864 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.5 tell 192.168.1.150, length 28
22:07:58.814083 e4:5f:01:b3:3a:8d > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 60: Reply 192.168.1.5 is-at e4:5f:01:b3:3a:8d, length 46
22:07:58.815431 70:ee:50:65:73:8a > e4:5f:01:b3:3a:8d, ethertype IPv4 (0x0800), length 58: 192.168.1.150.5001 > 192.168.1.5.37376: Flags [S.], seq 3645119822, ack 2347416179, win 3000, options [mss 1000], length 0
22:07:58.815639 e4:5f:01:b3:3a:8d > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 60: 192.168.1.5.37376 > 192.168.1.150.5001: Flags [.], ack 1, win 64240, length 0
22:07:58.815919 e4:5f:01:b3:3a:8d > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 306: 192.168.1.5.37376 > 192.168.1.150.5001: Flags [P.], seq 1:253, ack 1, win 64240, length 252
22:07:58.818431 70:ee:50:65:73:8a > e4:5f:01:b3:3a:8d, ethertype IPv4 (0x0800), length 104: 192.168.1.150.5001 > 192.168.1.5.37376: Flags [P.], seq 1:51, ack 253, win 2748, length 50
22:07:58.818599 e4:5f:01:b3:3a:8d > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 60: 192.168.1.5.37376 > 192.168.1.150.5001: Flags [.], ack 51, win 64190, length 0
22:07:58.818982 70:ee:50:65:73:8a > e4:5f:01:b3:3a:8d, ethertype IPv4 (0x0800), length 54: 192.168.1.150.5001 > 192.168.1.5.37376: Flags [F.], seq 51, ack 253, win 2748, length 0
22:07:58.820423 e4:5f:01:b3:3a:8d > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 60: 192.168.1.5.37376 > 192.168.1.150.5001: Flags [F.], seq 253, ack 52, win 64189, length 0
22:07:58.823861 70:ee:50:65:73:8a > e4:5f:01:b3:3a:8d, ethertype IPv4 (0x0800), length 54: 192.168.1.150.5001 > 192.168.1.5.37376: Flags [.], ack 254, win 2747, length 0
^C
27 packets captured
27 packets received by filter
0 packets dropped by kernel

capture when they are assigned to the Netatmo interface inside the .6 subnet:

root@WAX206:~# tcpdump -nn -e -i wl0-ap1 ether host 70:EE:50:65:73:8a
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wl0-ap1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:35:47.541673 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.150 tell 192.168.6.1, length 28
08:35:47.546401 70:ee:50:65:73:8a > 02:0c:43:26:60:30, ethertype ARP (0x0806), length 42: Reply 192.168.6.150 is-at 70:ee:50:65:73:8a, length 28
08:35:47.721432 70:ee:50:65:73:8a > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 82: 192.168.6.150.24801 > 192.168.6.1.53: 21516+ A? nv2-namain.netatmo.net. (40)
08:35:47.723933 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 163: 192.168.6.1.53 > 192.168.6.150.24801: 21516 3/0/0 CNAME nv2-extend.netatmo.net., CNAME nv2-extend.trafficmanager.net., A 20.224.172.199 (121)
08:35:47.725869 70:ee:50:65:73:8a > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 62: 192.168.6.150.56681 > 20.224.172.199.25050: Flags [S], seq 631897089, win 3000, options [mss 1000,nop,nop,nop,eol], length 0
08:35:47.761367 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 58: 20.224.172.199.25050 > 192.168.6.150.56681: Flags [S.], seq 552465767, ack 631897090, win 64240, options [mss 1452], length 0
08:35:47.765148 70:ee:50:65:73:8a > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 54: 192.168.6.150.56681 > 20.224.172.199.25050: Flags [.], ack 1, win 3000, length 0
08:35:48.470806 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:35:48.470848 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:35:48.470898 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
08:35:53.526593 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:35:53.526631 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:35:53.526672 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
08:35:58.660816 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:35:58.660853 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:35:58.660886 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
08:36:03.716787 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:36:03.716813 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:36:03.716849 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
08:36:09.021274 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:36:09.021301 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:36:09.021347 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
08:36:14.161775 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:36:14.161803 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:36:14.161829 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
08:36:19.311063 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:36:19.311107 70:ee:50:65:73:8a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.150, length 28
08:36:19.311150 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
08:36:19.720466 02:0c:43:26:60:30 > 70:ee:50:65:73:8a, ethertype IPv4 (0x0800), length 54: 20.224.172.199.25050 > 192.168.6.150.56681: Flags [.], ack 1, win 64240, length 0
08:36:19.725119 70:ee:50:65:73:8a > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 54: 192.168.6.150.56681 > 20.224.172.199.25050: Flags [.], ack 1, win 3000, length 0
^C
30 packets captured
30 packets received by filter
0 packets dropped by kernel

The mDNS packets are disappeared, and indeed from the router, where looks like they never arrive (this is why I don't see them in wireshark):

root@R4S:~# tcpdump -nn -e -i br-lan ether host 70:EE:50:65:73:8a
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

As soon as I assign the Netamo WLAN to the br-lan the packets re-appear on both the devices. Looks like something with DHCP?

Edit:

another thing, when I try to add again the Netatmo thermostat, when it's in the netamo interface, and with the firewall that is blocking the access from Netatmo->lan, it fails, but every time I press "try again" I see some requests from a different port:

09:37:37.110929 f8:b1:dd:a6:53:80 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 54: 192.168.6.127.49406 > 192.168.6.149.25050: Flags [.], ack 5, win 65535, length 0

the next try

09:39:19.320635 70:ee:50:6d:c6:80 > f8:b1:dd:a6:53:80, ethertype IPv4 (0x0800), length 88: 192.168.6.149.25050 > 192.168.6.127.49407: Flags [P.], seq 310:344, ack 190, win 2811, length 34

Looks like those devices are randomizing the ports that they're using to search for HomeKit devices inside the LAN, this could be why they're working from the Netatmo website/app but not inside HomeKit (?).

(As soon as I open the firewall from Netatmo->lan I'm able to add/install the devices with the app)

But I still don't understand why if I left these Netatmo devices inside the 'Netatmo' interface, and I allow all traffic from this zone to the lan, they are still unable to work/respond in HomeKit! :thinking: this makes no sense...

The first output-acknowledgement when Netatmo devices are connected to the lan:

root@WAX206:~# tcpdump -nn -e -i wl0-ap1 ether host 70:ee:50:6d:c6:80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wl0-ap1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:48:08.204733 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, 802.3, length 6: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 6: 01 00
13:48:08.204860 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, 802.3, length 6: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 6: 01 00
13:48:08.252227 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:48:08.252256 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:48:09.962711 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:48:09.962740 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308

13:48:21.970395 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.129.198 tell 0.0.0.0, length 28
13:48:21.970424 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.129.198 tell 0.0.0.0, length 28
13:48:23.066182 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.129.198 tell 0.0.0.0, length 28
13:48:23.066206 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 169.254.129.198 tell 0.0.0.0, length 28

13:48:27.398936 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 169.254.129.198.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
13:48:27.398972 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 169.254.129.198.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
13:48:27.399769 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
13:48:27.399788 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
13:48:27.470817 70:ee:50:6d:c6:80 > 33:33:ff:6d:c6:80, ethertype IPv6 (0x86dd), length 86: fe80::72ee:50ff:fe6d:c680 > ff02::1:ff6d:c680: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff6d:c680, length 24
13:48:27.470850 70:ee:50:6d:c6:80 > 33:33:ff:6d:c6:80, ethertype IPv6 (0x86dd), length 86: fe80::72ee:50ff:fe6d:c680 > ff02::1:ff6d:c680: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff6d:c680, length 24
13:48:27.503193 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 233: 169.254.129.198.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (191)
13:48:27.503211 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 233: 169.254.129.198.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (191)
13:48:27.503916 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 253: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (191)
13:48:27.503933 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 253: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (191)
13:48:27.571233 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 169.254.129.198 > 224.0.0.251: igmp v2 report 224.0.0.251
13:48:27.571258 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 169.254.129.198 > 224.0.0.251: igmp v2 report 224.0.0.251
13:48:27.572237 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 86: fe80::72ee:50ff:fe6d:c680 > ff02::fb: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::fb, length 24
Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
13:48:28.171528 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 169.254.129.198.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)

this is what is receveing the R4S:


[details="Summary"]
root@R4S:~# tcpdump -nn -e -i br-lan ether host 70:ee:50:6d:c6:80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
13:48:08.206191 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, 802.3, length 6: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 50: 01 00
13:48:08.253571 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:48:09.964056 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:48:13.969059 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:48:21.970316 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:48:21.971741 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Request who-has 169.254.129.198 tell 0.0.0.0, length 50
13:48:23.067516 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Request who-has 169.254.129.198 tell 0.0.0.0, length 50
13:48:24.169015 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Request who-has 169.254.129.198 tell 0.0.0.0, length 50
13:48:27.371819 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Request who-has 169.254.129.198 tell 169.254.129.198, length 50
13:48:27.400308 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 169.254.129.198.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
13:48:27.401108 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)

And this is when the Netatmo interface is assigned to the Netatmo interface separated:


[details="Summary"]
root@WAX206:~# tcpdump -nn -e -i wl0-ap1 ether host 70:ee:50:6d:c6:80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wl0-ap1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:52:01.344797 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, 802.3, length 6: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 6: 01 00
13:52:03.031000 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:52:03.031037 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:52:03.032164 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 342: 192.168.6.1.67 > 192.168.6.247.68: BOOTP/DHCP, Reply, length 300
13:52:03.035289 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:52:03.035326 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
13:52:03.037219 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 342: 192.168.6.1.67 > 192.168.6.247.68: BOOTP/DHCP, Reply, length 300
13:52:03.039507 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 0.0.0.0, length 28
13:52:03.039538 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 0.0.0.0, length 28
13:52:04.031390 70:ee:50:6d:c6:80 > 33:33:ff:6d:c6:80, ethertype IPv6 (0x86dd), length 86: fe80::72ee:50ff:fe6d:c680 > ff02::1:ff6d:c680: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff6d:c680, length 24
13:52:04.137704 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 161: 192.168.6.1.53 > 192.168.6.247.25227: 25227 3/0/0 CNAME nv2.netatmo.net., CNAME nv2.trafficmanager.net., A 51.105.245.118 (119)
13:52:04.214023 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 78: 51.105.245.118.25050 > 192.168.6.247.65130: Flags [P.], seq 1:25, ack 1, win 64240, length 24
13:52:04.215941 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 108: 192.168.6.247.65130 > 51.105.245.118.25050: Flags [P.], seq 1:55, ack 25, win 2976, length 54
13:52:04.330452 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.6.247 > 224.0.0.251: igmp v2 report 224.0.0.251
13:52:04.330499 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.6.247 > 224.0.0.251: igmp v2 report 224.0.0.251
13:52:04.355735 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 54: 51.105.245.118.25050 > 192.168.6.247.65130: Flags [.], ack 59, win 64182, length 0
13:52:04.535475 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
13:52:04.535521 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
[/details]

On the R4S there's nothing obviously.

Funny thing: now sometimes when the devices are in the the same subnet-lan, they aren't working online but they work inside the HomeKit app, and when they are in the separate subnet they are working from the Netatmo website and not in HomeKit. :unamused:

I have been looking at this for over 3 hours today. :thinking:

There are different firewall rules and network path and various configuration differences.
.
.
.

So DHCP for clients in 192.168.6.1/24 is working correctly now?

Did you post all the lines in that tcpdump sequence? There are missing packets.

Please share the current routes on WAX206 and R4S.

Yes yes but when they are inside the main LAN they were working always! Probably the devices keeps the old DHCP settings

Yes but the DHCP server was working also before. The devices sometimes are keeping their static addresses, this is why I have to reconfigure them.

Yes sorry, due to avoid a spamming tons of lines, here's the full output

Summary
root@WAX206:~# tcpdump -nn -e -i wl0-ap1 ether host 70:ee:50:6d:c6:80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wl0-ap1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:07:10.554730 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, 802.3, length 6: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 6: 01 00
19:07:12.444822 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
19:07:12.444853 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
19:07:12.445932 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 342: 192.168.6.1.67 > 192.168.6.247.68: BOOTP/DHCP, Reply, length 300
19:07:12.448932 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
19:07:12.448964 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:ee:50:6d:c6:80, length 308
19:07:12.450948 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 342: 192.168.6.1.67 > 192.168.6.247.68: BOOTP/DHCP, Reply, length 300
19:07:12.452514 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 0.0.0.0, length 28
19:07:12.452542 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 0.0.0.0, length 28
19:07:12.945743 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 0.0.0.0, length 28
19:07:12.945782 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 0.0.0.0, length 28
19:07:12.946910 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 0.0.0.0, length 28
19:07:12.946930 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 0.0.0.0, length 28
19:07:13.445868 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 192.168.6.247, length 28
19:07:13.445912 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 192.168.6.247, length 28
19:07:13.446754 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.6.247 > 224.0.0.251: igmp v2 report 224.0.0.251
19:07:13.446782 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 86: fe80::72ee:50ff:fe6d:c680 > ff02::fb: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::fb, length 24
19:07:13.446797 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.6.247 > 224.0.0.251: igmp v2 report 224.0.0.251
19:07:13.446797 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 86: fe80::72ee:50ff:fe6d:c680 > ff02::fb: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::fb, length 24
19:07:13.448000 70:ee:50:6d:c6:80 > 33:33:ff:6d:c6:80, ethertype IPv6 (0x86dd), length 86: fe80::72ee:50ff:fe6d:c680 > ff02::1:ff6d:c680: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff6d:c680, length 24
19:07:13.448021 70:ee:50:6d:c6:80 > 33:33:ff:6d:c6:80, ethertype IPv6 (0x86dd), length 86: fe80::72ee:50ff:fe6d:c680 > ff02::1:ff6d:c680: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff6d:c680, length 24
19:07:13.452195 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.247, length 28
19:07:13.452214 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.247, length 28
19:07:13.452243 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
19:07:13.946537 70:ee:50:6d:c6:80 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::72ee:50ff:fe6d:c680 > ff02::2: ICMP6, router solicitation, length 16
19:07:13.946581 70:ee:50:6d:c6:80 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::72ee:50ff:fe6d:c680 > ff02::2: ICMP6, router solicitation, length 16
19:07:14.947569 70:ee:50:6d:c6:80 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::72ee:50ff:fe6d:c680 > ff02::2: ICMP6, router solicitation, length 16
19:07:14.947609 70:ee:50:6d:c6:80 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::72ee:50ff:fe6d:c680 > ff02::2: ICMP6, router solicitation, length 16
19:07:15.338805 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 192.168.6.247.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:15.338829 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 192.168.6.247.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:15.339812 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 193: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:15.339848 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 278: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 3/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local., PTR _hap._tcp.local. (236)
19:07:15.339863 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 193: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:15.339864 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 278: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 3/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local., PTR _hap._tcp.local. (236)
19:07:15.340637 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 298: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 3/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local., PTR _hap._tcp.local. (236)
19:07:15.340658 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 298: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 3/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local., PTR _hap._tcp.local. (236)
19:07:15.442582 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:15.442612 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:15.443389 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:15.443406 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:15.846066 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 192.168.6.247.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:15.846094 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 192.168.6.247.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:15.846815 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 193: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:15.846837 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 193: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:15.946777 70:ee:50:6d:c6:80 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::72ee:50ff:fe6d:c680 > ff02::2: ICMP6, router solicitation, length 16
19:07:15.946816 70:ee:50:6d:c6:80 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::72ee:50ff:fe6d:c680 > ff02::2: ICMP6, router solicitation, length 16
19:07:16.136050 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 192.168.6.247.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:16.136084 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 192.168.6.247.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:16.136794 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 193: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:16.136817 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 193: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:16.396051 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 192.168.6.247.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:16.396087 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 173: 192.168.6.247.5353 > 224.0.0.251.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:16.397048 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 193: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:16.397072 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 193: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0 [2q] [3n] ANY (QM)? Netatmo Relay._hap._tcp.local. ANY (QM)? Netatmo Relay.local. (131)
19:07:16.496658 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:16.496695 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:16.497523 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:16.497546 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:16.639754 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 368: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:16.639792 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 368: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:16.640727 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 388: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:16.640748 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 388: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:17.454152 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.247 tell 192.168.6.1, length 28
19:07:17.455787 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype ARP (0x0806), length 42: Reply 192.168.6.247 is-at 70:ee:50:6d:c6:80, length 28
19:07:17.668639 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 368: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:17.668676 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 368: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:17.669609 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 388: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:17.669629 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 388: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:18.548651 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:18.548689 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 231: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:18.550070 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:18.550096 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 251: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 2/0/2 (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local. (189)
19:07:18.554221 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.247, length 28
19:07:18.554243 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.247, length 28
19:07:18.554285 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
19:07:18.659214 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 80: 192.168.6.247.37123 > 192.168.6.1.53: 12122+ A? netcomv2.netatmo.net. (38)
19:07:18.661059 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 147: 192.168.6.1.53 > 192.168.6.247.37123: 12122 3/0/0 CNAME nv2.netatmo.net., CNAME nv2.trafficmanager.net., A 51.105.245.118 (105)
19:07:18.663724 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 62: 192.168.6.247.56878 > 51.105.245.118.25050: Flags [S], seq 499896734, win 3000, options [mss 1000,nop,nop,nop,eol], length 0
19:07:18.701017 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 58: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [S.], seq 2376679884, ack 499896735, win 64240, options [mss 1452], length 0
19:07:18.702397 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 54: 192.168.6.247.56878 > 51.105.245.118.25050: Flags [.], ack 1, win 3000, length 0
19:07:18.741511 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 78: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [P.], seq 1:25, ack 1, win 64240, length 24
19:07:18.743333 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 108: 192.168.6.247.56878 > 51.105.245.118.25050: Flags [P.], seq 1:55, ack 25, win 2976, length 54
19:07:18.780246 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 54: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [.], ack 55, win 64186, length 0
19:07:18.780980 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 62: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [P.], seq 25:33, ack 55, win 64186, length 8
19:07:18.782493 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 58: 192.168.6.247.56878 > 51.105.245.118.25050: Flags [P.], seq 55:59, ack 33, win 2968, length 4
19:07:18.867504 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 54: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [.], ack 59, win 64182, length 0
19:07:18.868902 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 86: 192.168.6.247.56878 > 51.105.245.118.25050: Flags [P.], seq 59:91, ack 33, win 2968, length 32
19:07:18.905994 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 54: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [.], ack 91, win 64150, length 0
19:07:18.906052 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 78: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [P.], seq 33:57, ack 91, win 64150, length 24
19:07:18.914671 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 54: 192.168.6.247.56878 > 51.105.245.118.25050: Flags [.], ack 57, win 2944, length 0
19:07:19.720712 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 368: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:19.720749 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 368: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:19.721729 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 388: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:19.721751 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 388: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 6/0/2 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (326)
19:07:22.653606 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 526: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 8/0/4 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (484)
19:07:22.653645 70:ee:50:6d:c6:80 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 526: 192.168.6.247.5353 > 224.0.0.251.5353: 0*- [0q] 8/0/4 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (484)
19:07:22.654871 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 546: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 8/0/4 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (484)
19:07:22.654892 70:ee:50:6d:c6:80 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 546: fe80::72ee:50ff:fe6d:c680.5353 > ff02::fb.5353: 0*- [0q] 8/0/4 (Cache flush) TXT "c#=9" "s#=1" "ff=1" "sf=0" "pv=1.1" "md=Netatmo Relay^@" "id=70:60:BB:30:BF:3C" "na_tkn=ea8a693cc5c6" "ci=2" "sh=LJ/KDg==", PTR _hap._tcp.local., PTR Netatmo Relay._hap._tcp.local., (Cache flush) PTR Netatmo Relay.local., (Cache flush) PTR Netatmo Relay.local., (Cache flush) SRV Netatmo Relay.local.:5001 0 0, (Cache flush) A 192.168.6.247, (Cache flush) AAAA fe80::72ee:50ff:fe6d:c680 (484)
19:07:23.659273 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.247, length 28
19:07:23.659315 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.247, length 28
19:07:23.659351 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
19:07:26.087383 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 78: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [P.], seq 57:81, ack 91, win 64150, length 24
19:07:26.091772 70:ee:50:6d:c6:80 > 02:0c:43:26:60:30, ethertype IPv4 (0x0800), length 809: 192.168.6.247.56878 > 51.105.245.118.25050: Flags [P.], seq 91:846, ack 81, win 2920, length 755
19:07:26.170821 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype IPv4 (0x0800), length 54: 51.105.245.118.25050 > 192.168.6.247.56878: Flags [.], ack 846, win 63420, length 0
19:07:28.764265 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.247, length 28
19:07:28.764306 70:ee:50:6d:c6:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.6.1 tell 192.168.6.247, length 28
19:07:28.764340 02:0c:43:26:60:30 > 70:ee:50:6d:c6:80, ethertype ARP (0x0806), length 42: Reply 192.168.6.1 is-at 02:0c:43:26:60:30, length 28
^C
107 packets captured
110 packets received by filter
0 packets dropped by kernel
root@WAX206:~# 

WAX206

root@WAX206:~# route -n && ip route show
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.2     0.0.0.0         UG    0      0        0 br-lan
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 wl1-ap1
192.168.5.0     0.0.0.0         255.255.255.0   U     0      0        0 wl0-ap0
192.168.6.0     0.0.0.0         255.255.255.0   U     0      0        0 wl0-ap1
default via 192.168.1.2 dev br-lan 
192.168.1.0/24 dev br-lan scope link  src 192.168.1.3 
192.168.3.0/24 dev wl1-ap1 scope link  src 192.168.3.1 
192.168.5.0/24 dev wl0-ap0 scope link  src 192.168.5.1 
192.168.6.0/24 dev wl0-ap1 scope link  src 192.168.6.1 

R4S

root@R4S:~# route -n && ip route show
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.100.1   0.0.0.0         UG    0      0        0 pppoe-wan
10.4.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 wg0
10.4.0.3        0.0.0.0         255.255.255.255 UH    0      0        0 wg0
10.4.0.4        0.0.0.0         255.255.255.255 UH    0      0        0 wg0
10.4.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 wg0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.5.0     192.168.1.3     255.255.255.0   UG    0      0        0 br-lan
192.168.100.1   0.0.0.0         255.255.255.255 UH    0      0        0 pppoe-wan
default via 192.168.100.1 dev pppoe-wan 
10.4.0.2 dev wg0 scope link 
10.4.0.3 dev wg0 scope link 
10.4.0.4 dev wg0 scope link 
10.4.0.5 dev wg0 scope link 
192.168.1.0/24 dev br-lan scope link  src 192.168.1.2 
192.168.2.0/24 dev eth0 scope link  src 192.168.2.2 
192.168.5.0/24 via 192.168.1.3 dev br-lan  src 192.168.1.2 
192.168.100.1 dev pppoe-wan scope link  src 79.58.blabla 

As always thank you very much :clap:

I will go through that capture and comment on a few things later.

For future captures, please add the 'v' (verbose) option unless a specific capture doesn't need it. I would like to see 'tcp' vs 'udp' clearly showing in the output.
tcpdump -ennv -i wl0-ap1 ...

Using the filter expression 'ether host 70:ee:50:6d:c6:80' and the -e option is useful in early investigation to see what the hosts are doing, ether host usually only applies when capturing on the same layer2 network. Use the appropriate ethernet address that applies on a different l2 segment to see the related traffic on the different network or use the related ip addresses etc. as appropriate.

Using the ether host expression was useful because it showed the DHCP traffic and it show that the Netatmo device (thermostat?) is also using IPv6. It could be that the Netatmo devices work with HomeKit using IPv6 when on the same L2 network. It is possible unless proven to be false.
.
.
.

Notice that the first is from 192.168.6.127.49406 > 192.168.6.149.25050 and the second is in the opposite direction: 192.168.6.149.25050 > 192.168.6.127.49407, not that it matters for this discussion. Port randomization usually picks non-sequential port numbers. It is common with many protocols that a different source port is used for each new connection so what you shared is expected unless you know that the protocol in use by Netatmo is different.
.
.
.
If IP addresses are working, let us dig into mDNS.
If you still have your Netatmo thermostat and weather station on the Netatmo SSID and network (192.168.6.0/24) with the WAX206 interface of wl0-ap1, please do a new, different tcpdump. Run it long enough to see repeated mDNS queries from the Netatmo devices and any responses from the other side. Same for queries and responses in the opposite direction:
tcpdump -ennv -i wl0-ap1 port 5353

If nothing is seen coming back from the "LAN" through avahi, 192.168.1.0/24 then from a new terminal window, do 2 new captures, still on WAX206 starting at the same time with a similar capture on the br-lan side in the added ssh session:
tcpdump -ennv -i br-lan port 5353
and a new one for tcpdump -ennv -i wl0-ap1 port 5353 .

Use the appropriate 'wlX-apY' for network "LAN" if needed to see wifi traffic for network 192.168.1.0/24.

Please share the complete output as quoted text. Feel free to PM them and any other communications to me if you don't want to share with the world. You can update the "solution" at the end.

EDIT: Please include any traffic from the "iot" network. It is useful for comparisons.
Please identify what host the IP addresses belong to and describe the function if you think it may not be clear to me. Netatmo thermostat, weather station, router, HomeBridge, HomeHub, Mac, etc.
We should avoid using pronouns or other terms that may be ambiguous or otherwise unclear. This one can be a challenge for me :slight_smile:
.
.
Are all the hosts of interest on wifi?

Is Avahi still running on WAX206?
.
.
.

Info: Keeping the captures on each interface separate helps keep track of what is seen where.

I will try to work on keeping future questions / responses to a narrow focus. :slight_smile:

1 Like

I spent a lot of time researching and writing down details of the setup so I didn't write up info on the full tcpdump session you shared earlier. In summary, the capture shows DHCP working, Netatmo devices using IPv6, doing mDNSqueries and sending replies, doing normal dns, arp requests, and having a tcp session with a server on the Internet.
.
.
.
Here are my notes so far ( time for me to eat a late supper and relax an hour before bedtime. )

Info about the full capture session and starting a list of what we know and what we assume.

Know: All traffic from "LAN" to "iot" and "Netatmo" is allowed:

Know: Apple Home (HomeKit) system natively uses HAP, HomeKit Accessory Protocol, on Ethernet/WIFI.

Assume: Communication is direct between the Home app and each Homekit (HAP) capable appliance. With your Mac or iPhone or iPad connected to your home wifi, each should be having direct communication with every managed (Home) device.

I (Spence) do not know what other intermediate devices you have or what they do. Things like a bridge, hub, pod.

Assume: Everything learns about all other devices through Bonjour / mDNS.
Assume: Each system advertises the service it provides via mDNS, including 'TXT' and 'SRV' records including the TCP port to connect on.

Firewall Rule:

config rule
	option dest_port '5353'
	option target 'ACCEPT'
	option src_port '5353'
	option src 'iot'
	list proto 'udp'
	option dest 'lan'
	option name 'IoT mDNS port 5353'
	list dest_ip '224.0.0.251'
	list dest_ip 'ff02::fb'

Note that this rule allows mDNS to the router (WAX206) on IPv6 even though IPv6 routing is not configured on the WAX206. Avahi on WAX206 should be proxying mDNS.

Know: mDNS uses local_only IP multicast.
Know: mDNS uses IPv4 multicast group address 224.0.0.251 and UDP port 5353 on Ethernet multicast address 01:00:5E:00:00:FB.
Know: mDNS uses IPv4 multicast group address ff02::fb and UDP port 5353 on Ethernet multicast address 33:33:00:00:00:FB.

I saw it stated that mDNS replies "should" be to the unicast address of the querier but it is clear that we have seen replies to 224.0.0.251. We should be open to either styles.

As an example for the Home app on your mac asking for appliance info we should expect to see packet captures with the following src and dst:

Query:
WAX206 int wl0-ap0: 192.168.1.10:5353 > 224.0.0.251:5353 proto UDP
WAX206 int wl0-ap1: 192.168.6.1:5353 > 224.0.0.251:5353 proto UDP

Reply:
WAX206 int wl0-ap1: 192.168.6.127:5353 > 224.0.0.251:5353 proto UDP
WAX206 int wl0-ap0: 192.168.1.3:5353 > 224.0.0.251:5353 proto UDP

Is wlo-ap0 bound to the LAN network, same as br-lan?

Assume: HAP and Home uses the ports advertised in mDNS.

Know: We have seen The Home protocol use TCP ports 51826 and 51827.
You have a rule on WAX206:

config rule
	option target 'ACCEPT'
	option src_port '51826-51827'
	option dest_port '51826-51827'
	option src 'iot'
	option dest 'lan'
	option name 'HomeKit connectivity'

The "LAN" network has some added complexity. There is the main interface for it on R4S with IP address 192.168.1.1 and DHCP gives .1 as the default gateway.
However, WAX206 connects via 'LAN' with address .3. Normally any packets destined for network 192.168.1.0/24 would be sent direct to the hosts ethernet address via the ARP entry on WAX206. Various security improvements over the years may cause this to not work as hosts only know their default route via 192.168.1.1 and send to it for further routing. When replies come from the MAC address of the WAX206, a host may not accept the packet. Either router may also choose not to forward the packet depending on security settings. This may not be a problem as many hosts in the 'iot' network are communicating with hosts in the 'LAN' network.
A work-around is in place, an additional route table on WAX206:

config route
	option interface 'LAN'
	option gateway '192.168.1.3'
	option source '192.168.1.2'
	option target '192.168.5.0/24'

So, if this is working, we should see unicast IP traffic from 'iot' or 'Netatmo' networks destined for 'LAN' forwarded to R4S, and R4S send to host MAC addresses based on ARP entries.
since mDNS uses local_only multicast, we need to see how it behaves when proxied by Avahi on WAX206 with the custom route.

The end.

1 Like

Woah, thanks for the super-exhaustive reply! I try to reply:

Yes is the thermostat, I'm using it because it's easy to reset. About the IPv6, yes but it should be the same when in the other subnet and in all my network the ipv6 is disabled.

My thought indeed is that the Netatmo devices are using random ports also to communicate inside the LAN. It would be improbable because they are using standard protocols...but...

Yes, I will use Pastebin now, because there's a words limit here on the forum, here is the output: https://pastebin.com/xMY2xp3D but since there's nothing from the 'lan' side, here is the tcpdump -ennv -i br-lan port 5353, and the tcpdump -ennv -i br-lan port 5353.

I think the name of the devices is explicit :smiley: anyway the
Thermostat is at: 70:ee:50:6d:c6:80 and 192.168.6.247
Weather Station 70:EE:50:65:73:8A and 192.168.6.150

Yes to both, only my TV is cabled to my Lan but is in the .1.x subnet.

Avahi is running with this config:

[server]
#host-name=foo
#domain-name=local
use-ipv4=yes
use-ipv6=yes
check-response-ttl=no
use-iff-running=no

[publish]
publish-addresses=yes
publish-hinfo=yes
publish-workstation=no
publish-domain=yes
#publish-dns-servers=192.168.1.1
#publish-resolv-conf-dns-servers=yes

[reflector]
enable-reflector=yes
reflect-ipv=no

[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=30
rlimit-stack=4194304
rlimit-nproc=3

There's only the Netgear switch between but it hasn't any configuration, it's doing nothing, only adding ports.

I added the ipv6 address because only the ipv4 wasn't working and I noted that other Apple devices are using also the ipv6, I can remove it but is the same.

wl0-ap0 is the 'iot' interface and has the 192.168.5.1, the Netatmo interface is just to debug without rely on the iot interface but has the same rules/config/etc... of the iot interface as I wrote before.

No, is bound to nothing, is not assigned because I had weird issue if doing it, anyway I also tried to bound it to br-lan but is the same.

This is what I thought, I added the routing table at the beginning of this reply, and I also tried it some days before, but without any help.

Exactly, but instead it's a problem for these Netatmo devices! The only difference is that those devices don't rely on the Homebridge server at 192.168.1.5 because they're HomeKit native, so they should communicate with the hub/homepod directly. But this doesn't happen when they are in the 'iot' or 'netatmo' interface/subnet as the other devices in the same interface are doing.

thanks a lot for this extended reply, I have no idea what else I can do...other people are reporting that Netatmo devices in separated VLANs are working (after using Avahi as reflector), so this is my network issue.

1 Like

After investigating I'm starting think that Avahi is not working as expected with these Netatmo devices, I try to explain:

When the Netatmo devices are isolated from the lan, I absolutely can't see any query when I listen from the WAX206 with avahi-browse -arp.

As soon as I bond the Netatmo wireless interface to the br-lan interface, they appear! But note the IPs (I separated with white lines for easy readability):

root@WAX206:/etc/avahi# avahi-browse -arp
...............
=;br-lan;IPv4;MacBook\032Air;_airplay._tcp;local;MacBook-Air.local;192.168.1.103;7000;"srcvers=675.4.1" "pk=6fe401bbca6a752c126a0fbd36fbe5267a539b5bd785b0f99bd3770ac720cfcc" "psi=5CFB1E52-17CB-45A9-9D50-485E568203CF" "pi=0f45d894-46b5-421f-a59a-51e046da8964" "protovers=1.1" "at=4" "model=MacBookAir10,1" "gcgl=0" "igl=0" "gid=E3FA7F36-2BDD-4B22-8F1B-2607B9D468C4" "flags=0x204" "rsf=0x8" "features=0x4A7FCFD5,0xB8154FDE" "fex=1c9/St5PFbgmIQ" "deviceid=1C:91:80:EA:46:61" "acl=0" "act=2"
=;br-lan;IPv4;HomePodSensor\032469446;_hap._tcp;local;Salotto.local;192.168.1.127;61204;"sh=yi0Ddg==" "ci=10" "sf=0" "s#=7" "pv=1.1" "md=HomePod" "id=5A:CF:80:22:AA:E5" "ff=2" "c#=1"
=;br-lan;IPv4;homebridge-lgwebos-tv\0329992;_hap._tcp;local;homebridge.local;192.168.1.5;33600;"sh=xZ2SGg==" "ci=2" "sf=0" "s#=1" "pv=1.1" "md=homebridge" "id=0E:C9:34:9B:85:24" "ff=0" "c#=2"
=;br-lan;IPv4;RPi\0322EDD;_hap._tcp;local;homebridge.local;192.168.1.5;35521;"sh=foRhag==" "ci=2" "sf=0" "s#=1" "pv=1.1" "md=homebridge" "id=0E:AA:D3:5A:E1:5C" "ff=0" "c#=4"
=;br-lan;IPv4;Meross\0325B65;_hap._tcp;local;homebridge.local;192.168.1.5;53167;"sh=kMp34A==" "ci=2" "sf=0" "s#=1" "pv=1.1" "md=homebridge" "id=0E:66:A1:4E:B2:EA" "ff=0" "c#=4"
=;br-lan;IPv4;homebridge-prometheus-exporter\0326097;_hap._tcp;local;homebridge.local;192.168.1.5;35834;"sh=wOpYyw==" "ci=2" "sf=0" "s#=1" "pv=1.1" "md=homebridge" "id=0E:C6:E7:21:D6:C4" "ff=0" "c#=2"
=;br-lan;IPv4;Televisione\0327492;_hap._tcp;local;homebridge.local;192.168.1.5;38855;"sh=IFwVEg==" "ci=31" "sf=0" "s#=1" "pv=1.1" "md=Model Name" "id=0B:74:47:D6:70:6B" "ff=0" "c#=52"
=;br-lan;IPv4;Broadlink\032RM\0324A8F;_hap._tcp;local;homebridge.local;192.168.1.5;33440;"sh=eKzYEw==" "ci=2" "sf=0" "s#=1" "pv=1.1" "md=homebridge" "id=0E:B7:47:FD:F0:28" "ff=0" "c#=4"
=;br-lan;IPv4;SwitchBot\032E202;_hap._tcp;local;homebridge.local;192.168.1.5;49850;"sh=yE+FFA==" "ci=2" "sf=0" "s#=1" "pv=1.1" "md=homebridge" "id=0E:66:68:8A:59:5F" "ff=0" "c#=3"
=;br-lan;IPv4;Homebridge\03227ED;_hap._tcp;local;homebridge.local;192.168.1.5;51625;"sh=zeQfPA==" "ci=2" "sf=1" "s#=1" "pv=1.1" "md=homebridge" "id=0E:94:69:C8:F3:6E" "ff=0" "c#=2"
+;br-lan;IPv4;Giulio\226\128\153s\032iPhone;_rdlink._tcp;local
+;br-lan;IPv4;70\058b3\05806\0581d\0585e\058d9\064fe80\058\05872b3\0586ff\058fe1d\0585ed9-supportsRP;_apple-mobdev2._tcp;local
=;br-lan;IPv4;Giulio\226\128\153s\032iPhone;_rdlink._tcp;local;Giulios-iPhone.local;192.168.1.109;50712;"rpAD=a498ad3f4f0e" "rpVr=430.3" "rpBA=08:8E:C5:42:74:7B"
=;br-lan;IPv4;70\058b3\05806\0581d\0585e\058d9\064fe80\058\05872b3\0586ff\058fe1d\0585ed9-supportsRP;_apple-mobdev2._tcp;local;Giulios-iPhone.local;192.168.1.109;32498;
-;br-lan;IPv4;Giulio\226\128\153s\032iPhone;_rdlink._tcp;local
-;br-lan;IPv4;70\058b3\05806\0581d\0585e\058d9\064fe80\058\05872b3\0586ff\058fe1d\0585ed9-supportsRP;_apple-mobdev2._tcp;local


+;br-lan;IPv4;Netatmo\032Relay;_hap._tcp;local
=;br-lan;IPv4;Netatmo\032Relay;_hap._tcp;local;Netatmo\032Relay.local;169.254.129.198;5001;"sh=LJ/KDg==" "ci=2" "na_tkn=cd35dff9ce88" "id=70:60:BB:30:BF:3C" "md=Netatmo Relay\000" "pv=1.1" "sf=0" "ff=1" "s#=1" "c#=9"
+;br-lan;IPv4;Weather\032Station;_hap._tcp;local
=;br-lan;IPv4;Weather\032Station;_hap._tcp;local;Netatmo.local;169.254.139.115;5001;"sh=7jn59A==" "ci=2" "na_tkn=c082117652ea" "id=8C:3F:21:DD:87:8C" "md=Weather Station" "pv=1.1" "sf=0" "ff=1" "s#=1" "c#=11"


+;br-lan;IPv4;Giulio\226\128\153s\032iPhone;_rdlink._tcp;local
+;br-lan;IPv4;70\058b3\05806\0581d\0585e\058d9\064fe80\058\05872b3\0586ff\058fe1d\0585ed9-supportsRP;_apple-mobdev2._tcp;local
=;br-lan;IPv4;Giulio\226\128\153s\032iPhone;_rdlink._tcp;local;Giulios-iPhone.local;192.168.1.109;50712;"rpAD=a498ad3f4f0e" "rpVr=430.3" "rpBA=08:8E:C5:42:74:7B"
=;br-lan;IPv4;70\058b3\05806\0581d\0585e\058d9\064fe80\058\05872b3\0586ff\058fe1d\0585ed9-supportsRP;_apple-mobdev2._tcp;local;Giulios-iPhone.local;192.168.1.109;32498;
+;br-lan;IPv4;iPadPro;_rdlink._tcp;local
=;br-lan;IPv4;iPadPro;_rdlink._tcp;local;iPadPro.local;192.168.1.106;49154;"rpAD=7acbfc19fe6c" "rpVr=420.5" "rpBA=0A:D4:AA:49:DD:10"
^CGot SIGINT, quitting.
root@WAX206:/etc/avahi# 

With 169.254.129.198;5001 and 169.254.139.115;5001 as IPs, they will never e discovered by Avahi when they are separated... but why they don’t have correct IPs when in lan? From the WAX206 I see the correct IP.

I have no idea of what to do now :thinking: :grin: how to fix this issue? edit the avahi config file somewhere in these points? I'm just thinking on what to do now, if you have any suggestion...

publish-dns-servers= Takes a comma seperated list of IP addresses for unicast DNS servers. You can use this to announce unicast DNS servers via mDNS. When used in conjunction with avahi-dnsconfd on the client side this allows DHCP-like configuration of unicast DNS servers.
publish-resolv-conf-dns-servers= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will publish the unicast DNS servers specified in /etc/resolv.conf in addition to those specified with publish-dns-servers. Send avahi-daemon a SIGHUP to have it reload this file. Defaults to "no".

169.254.x.x are self assigned local_only addresses.

Commonly used when a host has no valid ip address config or DHCP.
If you changed the network connectivity without causing a physical link loss on the hosts, this could be expected. Simple devices sometimes don't have code to deal with that situation, or perhaps any network change without a reboot.

Try causing a wifi re-association for the Netatmo devices if that is easy or just reboot them.
.
.
.

This agrees with the packet captures.
.
.
.

I looked at the traces.
I think we are close!
The capture on the Netatmo side (.6.0/24) shows proxied mDNS from the LAN (.1.0/24).
There is zero mDNS traffic from the Netatmo side showing on the LAN side.
Avahi seems to be working in one direction: LAN to Netatmo.

Once the Netatmo devices are back in the Netatmo network and you verify that they have correct IP addresses and mDNS traffic is seen by tcpdump -ennv -i wl0-ap1 port 5353 on WAX206, please do a capture on the WAX206 with this:
tcpdump -ennv -i br-lan
and verify that the IP address on the WAX206, 192.168.1.3, shows up as a source in some packets.
If your ssh session is from the LAN network then there should be plenty of traffic during a short capture.
I don't need you to share those captures with me.

If you can capture some packets "from" the interface on WAX206 directly connected to the LAN then it looks like Avahi is only working in one direction.
I noticed there was no proxied mDNS traffic from 'iot' network on the br-lan capture.
Are there any devices doing mDNS on the 'iot' network? If there are, then maybe avahi is currently only forwarding from 'Netatmo'.

I don't have any suggestions but please work on changing the Avahi config / firewall rules so Avahi forwards from 'Netatmo' to 'LAN' as well.
Check with tcpdump -ennv -i br-lan port 5353 should show nDNS traffic from source 192.168.1.3.

Good luck!
I will be away for 2 - 3 hours but I look forward to some good news from you then! :slight_smile:

1 Like

A quick addition before I run out the door...

Look into advanced options of netstat and ps commands to see the network binding to the avahi process(es).

netstat -nluepw or other variants.
ps -w

There are other tools that may need to be added by opkg but I hope the above tools reveal the process and network bindings. They may help correlate bindings to the Avahi config changes for listening/forwarding to/from interfaces.

1 Like