nicopace / cotonete Goto Github PK

Thanks to IPv6 privacy extension, the IPv6 link-local of a client (e.g. for a station connected to an AP interface) could be different from the one calculated with eui64 from the device MAC address.

To detect this, either:

• check if the calculated IPv6 link local is a known neighbour (ARP table, ip neigh show)
• or simply if zero ping replies are received (this could also be due to a firewall on the client)

Once this case is detected, either:

• do a single broadcast ping on the same interface (ping6 -c 1 -w 1 ff02::1%br-lan)
• or get one reachable neighbour on the same interface (ip neigh show dev br-lan nud reachable) and ping it

I am using an Ubiquiti NanoStation M2 as client, and at a certain point it couldn't ping the gateway anymore.
I suspect the interface went deaf, but I could be wrong, it could have been an AP problem.
Cotonete did not detect it, as the numbers of sent and received packets are increasing anyway.
Could it be?

This is what tcpdump shows during this "deaf" time.

listening on wlan0-sta, link-type EN10MB (Ethernet), capture size 262144 bytes
12:37:39.279228 IP 192.168.1.63.35248 > 141.1.1.1.53: 42206+ A? www.google.com. (32)
12:37:39.279490 IP 192.168.1.63.35248 > 4.2.2.2.53: 42206+ A? www.google.com. (32)
12:37:39.280239 IP 192.168.1.63.3465 > 141.1.1.1.53: 37905+ AAAA? www.google.com. (32)
12:37:39.282145 IP 192.168.1.63.3465 > 4.2.2.2.53: 37905+ AAAA? www.google.com. (32)
12:37:45.463845 IP 192.168.1.63.56789 > 141.1.1.1.53: 21812+ PTR? 2.2.2.4.in-addr.arpa. (38)
12:37:50.473902 ARP, Request who-has 192.168.1.1 tell 192.168.1.63, length 28
12:37:51.322103 IP6 fe80::de9f:dbff:fe36:28a9 > ff02::1:ff20:8fa6: ICMP6, neighbor solicitation, who has fe80::de53:7cff:fe20:8fa6, length 32
12:37:51.482048 ARP, Request who-has 192.168.1.1 tell 192.168.1.63, length 28
12:37:55.482921 IP 192.168.1.63.40678 > 141.1.1.1.53: 40743+ PTR? 2.179.154.195.in-addr.arpa. (44)
12:38:00.556091 IP 192.168.1.63.28002 > 141.1.1.1.53: 58117+ PTR? 44.165.216.115.in-addr.arpa. (45)
12:38:05.562097 ARP, Request who-has 192.168.1.1 tell 192.168.1.63, length 28
12:38:05.643249 IP 192.168.1.63.49124 > 185.60.216.11.443: Flags [S], seq 3330035749, win 65535, options [mss 1460,sackOK,TS val 57158362 ecr 0,nop,wscale 5], length 0

Do you think that these packets would sum up to the transmitted packets number even if the interface is deaf (or in my case it was just an AP problem?)?
I will report here if the situation repeats, thanks.

When restarting the wireless interfaces using the wifi command, cotonete throws many error messages due to the interface not being available:

Sun Oct 20 20:21:14 2019 daemon.err cotonete.sh[1675]: ping: sendmsg: Permission denied
Sun Oct 20 20:21:15 2019 daemon.err cotonete.sh[1675]: ping: sendmsg: Permission denied
Sun Oct 20 20:21:15 2019 daemon.err cotonete.sh[1675]: ping: sendmsg: Permission denied
Sun Oct 20 20:21:15 2019 daemon.err cotonete.sh[1675]: ping: sendmsg: Permission denied
[...]
Sun Oct 20 20:21:19 2019 daemon.err cotonete.sh[1675]: connect: Address not available
Sun Oct 20 20:21:19 2019 daemon.err cotonete.sh[1675]: sh: 0: unknown operand

A check should be implemented for avoiding to use a non-existing or down interface.

When cotonete tries to ping clients of an AP interface, e.g. wlan0-ap, the ping will use %wlan0-ap as a suffix for the IPv6 link local direction.
This ping will never get any reply as the AP interface is inside the br-lan bridge and anything related with IPv6 link local has to be run specifying %br-lan as a suffix instead of %wlan0-ap.
For this reason, this command does not generate any traffic and the interface is erroneously detected as deaf (if no other traffic is flowing independently from cotonete).