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

giuliomagnifico · January 25, 2023, 4:42pm

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.

spence · January 25, 2023, 5:24pm

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

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

giuliomagnifico:

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]

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.

giuliomagnifico · January 25, 2023, 6:14pm

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

spence · January 25, 2023, 8:13pm

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.
.
.
.

giuliomagnifico:

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 (?).

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
.
.
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.

spence · January 26, 2023, 1:43am

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.

giuliomagnifico · January 26, 2023, 9:25am

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 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.

spence:

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'

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.

giuliomagnifico · January 26, 2023, 1:34pm

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 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".

spence · January 26, 2023, 4:30pm

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!

spence · January 26, 2023, 5:00pm

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.

giuliomagnifico · January 26, 2023, 5:19pm

Yes this is what I was saying, if they don't have an IP, how they can talk? I'll try the reboot when they are inside the lan and I will check if they get a valid

[quote="spence, post:19, topic:149133"]
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[/quote]

Yes but it shows up only in the (current) SSH session with the Mac I'm using, nothing else...

17:48:40.904910 80:cc:9c:eb:8d:37 > f8:e4:3b:a3:5f:54, ethertype IPv4 (0x0800), length 1326: (tos 0x4a,ECT(0), ttl 64, id 25025, offset 0, flags [DF], proto TCP (6), length 1312)
    192.168.1.3.22 > 192.168.1.10.50721: Flags [P.], cksum 0x8870 (incorrect -> 0x4fbc), seq 20940704:20941964, ack 13177, win 1002, options [nop,nop,TS val 3344280471 ecr 547442437], length 1260

It's what I'm trying to say, Avahi is not working as expected, and I think the host inside 'iot' interface are working only because there's the Avahi istance running on Homebridge, because all the queries are sent to them but from them

I see only traffic from other sources like smart plugs/TV/etcc..and the Homebridge server where Avahi is running and is running fine:

Homebridge server

192.168.1.5.5353 > 224.0.0.251.5353: 0 PTR (QM)? _hap._tcp.local. (33)
18:10:39.713126 e4:5f:01:b3:3a:8d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 1248: (tos 0x0, ttl 255, id 38789, offset 0, flags [DF], proto UDP (17), length 1234)

Random iot device

192.168.1.109.5353 > 224.0.0.251.5353: 0*- [0q] 3/0/2 Giulios-iPhone.local. (Cache flush) AAAA fe80::109a:cc7a:4eaf:87d5, Giulios-iPhone.local. (Cache flush) A 192.168.1.109, Giulios-iPhone.local. (Cache flush) AAAA fd91:e81d:cbd3:4623:1076:22e4:f83b:8ceb (153)

About the rule... hmmm but all the traffic can already go from 'lan' to 'netatmo', what rule I can try to add other than this that is already in firewall?

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

I also have to go out, I'll think on it!

Thanks!

EDIt:

Uhm, Avahi is running as I've always noticed but I noticed only now that assigned to the useless 'nobody' user! This could be the issue (?) no permissions?

19252 nobody    2684 S    avahi-daemon: running [WAX206.local]

spence · January 26, 2023, 9:36pm

giuliomagnifico:

I see only traffic from other sources like smart plugs/TV/etcc..and the Homebridge server where Avahi is running and is running fine:

Homebridge server

192.168.1.5.5353 > 224.0.0.251.5353: 0 PTR (QM)? _hap._tcp.local. (33)
18:10:39.713126 e4:5f:01:b3:3a:8d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 1248: (tos 0x0, ttl 255, id 38789, offset 0, flags [DF], proto UDP (17), length 1234)

Random iot device

192.168.1.109.5353 > 224.0.0.251.5353: 0*- [0q] 3/0/2 Giulios-iPhone.local. (Cache flush) AAAA fe80::109a:cc7a:4eaf:87d5, Giulios-iPhone.local. (Cache flush) A 192.168.1.109, Giulios-iPhone.local. (Cache flush) AAAA fd91:e81d:cbd3:4623:1076:22e4:f83b:8ceb (153)

These are all on the 'lan' network (192.168.1.0/24) and not the 'iot' network (192.168.5.0/24). We know Avahi proxies them to network 'Netatmo'. I am interested to know what mDNS hosts are in network 'iot' that we should see reflected to the other networks.
.
.
.
What I was suggesting is that after adjusting the config so avahi might work better / differently then look for reflected mDNS traffic exiting interfaces on the WAX206. You may have another tool to make that easier. Didn't you show me something like avahi-browse -arp ?
.
.
.

Since Avahi IS working reflecting mDNS from 'Netatmo' to 'lan' I would not think permissions are an issue. Why would "nobody" be allowed read to access of 'Netatmo' and write access to 'lan' but not read access from 'lan' or read/write access to 'iot'.

Are there mDNS / Homekit devices active on 'iot'?

For netstat, try a broader, more inclusive set of options but grep for '5353':
netstat -np |grep 5353
If nothing shows up then run netstat -anp and look for anything interesting. There might be something tied to ubusd or netflow etc. I don't know how avahi runs. Maybe there is revealing info in /etc/rc.d or /etc/init.d.
.
.
.
As for Avahi config, I didn't find much info on openwrt.org/docs/ but from https://linux.die.net/man/5/avahi-daemon.conf I found allow-interfaces=.

A recent posting of your Avahi config does not have a line for
allow-interfaces=
It may be good to add that back to section [server] and leave the list empty.
Try it and look for proxied mDNS, either with 'avahi-browse -arp` or tcpdump.

Have you been watching logread and dmesg for any related messages, especially avahi startup and dhcp events. If you use dnsmasq for dhcp, I think you can turn on event logging for things like unusual client requests in the config file and reload the config.

spence · January 26, 2023, 10:07pm

I am thinking that it is more likely that avahi is only reflecting from network 'lan' to network 'Netatmo` and not from 'Netatmo' or 'iot' to 'lan'.

To test this, identify a system that is known to be sending mDNS traffic and seen by WAX206 and move it to network 'Netatmo'. Better yet, I saw your iPhone mDNS traffic reflected from 'lan' to 'Netatmo'.

09:24:33.909046 02:0c:43:26:60:30 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 304: (tos 0x0, ttl 255, id 45888, offset 0, flags [DF], proto UDP (17), length 290)
    192.168.6.1.5353 > 224.0.0.251.5353: 0 [3q] [5n] ANY (QM)? GiulioM-bM-^@M-^Ys iPhone._rdlink._tcp.local. ANY (QM)? Giulios-iPhone.local. ANY (QM)? 70:b3:06:1d:5e:d9@fe80::72b3:6ff:fe1d:5ed9-supportsRP._apple-mobdev2._tcp.local. (262)

09:24:34.160194 02:0c:43:26:60:30 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 304: (tos 0x0, ttl 255, id 45899, offset 0, flags [DF], proto UDP (17), length 290)
  192.168.6.1.5353 > 224.0.0.251.5353: 
    0 [3q] [5n]
     ANY (QM)? GiulioM-bM-^@M-^Ys iPhone._rdlink._tcp.local.
     ANY (QM)? Giulios-iPhone.local.
     ANY (QM)? 70:b3:06:1d:5e:d9@fe80::72b3:6ff:fe1d:5ed9-supportsRP._apple-mobdev2._tcp.local.
    (262)

(I added some line breaks in the second packet for easy reading)
Did you have the Home app open on your iPhone at around 9:24 this morning?
.
.

Try moving your iPhone to the 'Netatmo' network, verify that it has a good IP address and see if it shows up in avahi-browse and or in tcpdumps.

Also test to see if Avahi is reflecting to 'iot'. I don't think we did that yet. I had that on my todo list from yesterday.

giuliomagnifico · January 26, 2023, 10:13pm

Ehy @spence you won't trust me but.... I solved the issue. In a very stupid way, and this is not the first time I have a similar experience with OpenWrt (I also wrote it before, about bounding/assigning an interface to a device, example.

I was simply searching a way to allow the traffic rom netatmo to lan as you wrote:

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.

And I changed this, just for curiosity (since the Netatmo zone is already assigned to the wl0-ap0 interface):

That is the same as add list device

config zone
	option name 'Netatmo'
	option output 'ACCEPT'
	list network 'Netatmo'
	option forward 'ACCEPT'
	option input 'REJECT'
	list device 'wl0-ap1'

My previous setting was

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

This fixed all.

I have no idea of what is the difference in doing this, I mean assign a zone to an interface or specify the interface from a zone, but that is all.

Now here in Italy are the 11PM so I'm to tired to think to something else rather than sleep

Tomorrow I'll reply to your post, I'll turn off the netatmo interface and I'll put the Netatmo devices inside the iot WLAN, do some tcpdump, I'll investigate better, etc...

That's absurd... I spent one week just to add a stupid option to assign a stupid

list device 'wl0-ap1'

to a firewall zone that is already assigned to the 'wl0-ap0` interface.

That emoticon explain my mood!

I don't know if it's a weird behviour with LuCi or what else, but is way faster and simpler create a new firewall zone when you create the new interface with LuCi.... but if this don't/will not work, then is pointless, you still have to go inside the firewall and specify to which device this zone must be assigned.

Anyway I learned lots of new things/stuff doing this debug, thanks to you! So I'm happy to fixed it in this "stupid way"

spence · January 26, 2023, 10:23pm

Yay!!!! Congratulations!!

spence · January 27, 2023, 12:05am

I believe it! I am not surprised that it is something like that. I was working with you to find the point where it breaks so you could focus on finding a solution for a specific problem.

Your solution looks unusual to me. I never used swconfig so I only had to learn the DSA way and other "new" config styles and did not need to unlearn old openwrt ways. It was interesting learning openwrt after 26 years of cisco and other vendors before that.
.
.
.
I'm sure it is already your plan but after testing in network 'iot', you can set mDNS reflection to be limited to 'lan' and 'iot' so 'guest' can not see nor serve records, unless you want that to work for screen casting to your tv or something.

Assuming that the rest of your setup for iot isolation goes smoothly, feel free to bring up anything you mentioned earlier that I did not address to your satisfaction or new things as well.

giuliomagnifico · January 27, 2023, 7:50am

Yes thanks again!

...don't tell it to me... this solution looks absurd, because the Netatmo interface was already assigne to the Netamo zone of the firewall. So why add a device to a firewall zone if an interface is assigned to the same zone?

But this is a DSA router/AP, not swconfig, with my old swconfig things were "more logical", is the second time that this DSA config is incomprensibile to me. But that's the (new) way! And I like learn new things

Yes thanks, already done, after assignign the same wireless interface to the 'iot' firewall zone, I've put the Netatmo device inside the 'iot' zone, now they're working as expected.

Oh thanks, at the moment everything is perfect, the only next step I'm planning is to add the TV to a VLAN, because it's wired connected to the hub, but I have to chose if I have to use the Netgear hub to make a untagged VLAN or a tagged one in the R4S I don't like both ways, the interface in the Netgear witch is ugly and I don't like the tagged VLANs but since I use the TV for airplay content sharing, maybe is better leave it inside the lan with other devices to avoid further messes

I'll write a post on my blog for this issue, maybe could be useful for someone else, since it was a very weird and not logical solution!

Edit: another weird behavior

I'm cleaning up the Netatmo interface, zone, etcc... but I discovered that if I don't specify also the subnet IP inside the firewall (not only the attached device), the setup isn't working.

config zone
	option name 'iot'
	option output 'ACCEPT'
	option input 'REJECT'
	list device 'wl0-ap0'
	list network 'iot'
	option forward 'REJECT'
	list subnet '192.168.5.0/24'

With the Netatmo zone it was working without specifying anything... becuse the wl0-ap0 device is already assigned to the iot zone that has 192.168.5.0/24 has IP. I have no idea...

Finn · January 27, 2023, 12:39pm

Hi Giulio.
just picked up this thread from our wax206 thread and haven't gone through the entire post - yet.
FYI
There shall be no firewall settings/setup on the AP (and no dhcp or dns) - these things You can disable in system->startup - those services shall be handled by the router only

giuliomagnifico · January 27, 2023, 12:50pm

Hi Finn, thanks for the reply, I solved the issues yesterday, you can read only the last post: Netatmo HomeKit native devices, not able to update iOS Home app when isolated (but work online/using Netamo app) - #24 by giuliomagnifico

Anyway yes, use the firewall on the router only is another way but I have to create lots of tagged VLANs and the router should handle more work. Instead using the firewall access point I demand some work to it and I can have another layer of security.

Now my network is made in this way, with 3 isolated subnets and no VLANs

Finn · January 27, 2023, 2:11pm

I think I recall You as having a Nanopi R4S as Your router - it's piece of cake to run many vlans for that device.
I am running 3 vlans (found out how to set it up from reading Your posts amongst others) - lan, IOT and game and yet another vlan will be added soon.

My setup: WAN -> NanopiR4S (OpenWrt) -> Netgear 308Tgs (Openwrt) - Netgear wax206 AP (Openwrt)

Most security is in the firewall (router) and in here I control what which vlan can regarding access to the internet - Lan full access to wan and IOT, IOT only outgoing access to wan no access to Lan same with Game (no one can access IOT or game from WAN) but that requires me to allow dhcp and dns requests (in traffic rules) so IOT and Game can receive information when needed and maybe this may have caused Your issues not getting any ip's ? just a guess

Ciao

giuliomagnifico · January 27, 2023, 2:36pm

Yes I also have the small great R4S (that also @spence has IIRC). And thanks. We're on the same exact hardware, except that I have another Netgear switch (very similar, the GS108E)

Your config is perfect, whatever to use VLAN or subnet is a personal choice. Both have advantages and disadvantages! My network is similar to your, only using subnets, by the way my issue wasn’t the IPs/DHCP, was something related to specific explain every subnet and device attached to the a firewall zone. Also if it’s already selected an interface that is assigned to the same subnet/device. And I had to specify a new route and gateway for the subnets to the R4S to route the mDNS packets for the Homebridge server… just a mess for Apple stuff

Anyway I’m writing a new post blog on my actual home setup, because I made some hardware changes, like two big fans inside the """server cabinet* """ I will write also the details about this issue and the configuration of the WAX206.

The R4S is rugged/dust-proof