Bonjour,
J’ai abordé ce sujet sur le forum caps de K-Net (
https://forum.caps.services/index.php/topic,8122.0.html ), mais comme cela concerne tous abonnés de Covage 14 (tous FAI confondus sauf peut-être les offres passives), je poste ici.
Je reçois depuis le WAN des paquets UDP provenant d’une adresse APIPA, toutes les 15 secondes en moyenne. Actuellement, c’est 169.254.64.208, mais hier, c’était 169.254.234.247. Le port d’origine est 49150.
Ces paquets sont destinés au broadcast 255.255.255.255 port 49152.
L’analyse de ces paquets me donne ceci (scan sur 10 secondes) :
root@HERMES:~$ tcpdump -i brwan udp port 49150 -vv -X
tcpdump: listening on brwan, link-type EN10MB (Ethernet), capture size 96 bytes
11:25:05.417880 IP (tos 0x0, ttl 64, id 63302, offset 0, flags [DF], proto UDP (17), length 48) 169.254.64.208.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
0x0000: 4500 0030 f746 4000 4011 58a8 a9fe 40d0 E..0.F@.@.X...@.
0x0010: ffff ffff bffe c000 001c 9952 5245 4e53 ...........RRENS
0x0020: 4f4e 5f44 4556 4943 452f 4a53 4f4e 3f00 ON_DEVICE/JSON?.
11:25:15.421035 IP (tos 0x0, ttl 64, id 63939, offset 0, flags [DF], proto UDP (17), length 48) 169.254.64.208.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
0x0000: 4500 0030 f9c3 4000 4011 562b a9fe 40d0 E..0..@.@.V+..@.
0x0010: ffff ffff bffe c000 001c 9952 5245 4e53 ...........RRENS
0x0020: 4f4e 5f44 4556 4943 452f 4a53 4f4e 3f00 ON_DEVICE/JSON?.
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
Les pings ICMP, UDP et TCP ne retournent rien, mais ARP oui :
root@HERMES:~$ arping -I brwan 169.254.64.208
ARPING 169.254.64.208 from 2.59.XX.XX brwan
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.905ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.342ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.373ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.373ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.374ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.530ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.530ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.467ms
^CSent 8 probe(s) (1 broadcast(s))
Received 8 response(s) (0 request(s), 0 broadcast(s))
Cela me donne trois informations :
1) La MAC de cet appareil qui est 00:11:2a:22:48:e7
Cette MAC indique que c’est un appareil de chez Niko NV - Industriepark West 40 - Sint-Niklaas O/V 9100 - BE
https://www.niko.eu/fr-frDonc sauf MAC spoofing, c’est un appareil de domotique de chez Niko.
2) Le temps de latence d’environ 5.5 ms, et
3) Le fait que l’appareil soit visible avec arp :
Le routeur de collecte Covage 14 (10.2.0.211), ainsi que la passerelle WAN sont à 2.5 ms de mon routeur.
Les routeurs d’échange Covage/FAI sont à 7 ms de mon routeur.
Cet appareil étant à 5.5 ms et dans mon voisinage arp, il est situé avant la livraison Covage aux FAI, quelque part dans la boucle de collecte 14.
Quelqu’un a donc connecté un appareil domotique au mauvais endroit ou sur un switch connecté à leur ONT.
Apparemment, les routeurs Covage laissent passer les paquets provenant d’adresses privées (ici APIPA) et les distribuent partout (car destination 255.255.255.255 qui signifie tous les appareils).
Ce n’est pas dramatique ici, mais Covage devrait bloquer ces paquets qui polluent la boucle, car tous les clients de ma boucle locale (possiblement tous les clients Covage 14 actif) reçoivent ces paquets.
Peut-être que l’abonné fibre qui possède cet appareil Niko lit ce forum, et devrait vérifier son installation, car 1) l’appareil ne fonctionne probablement pas (pas d’IP attribuée car APIPA...) et 2) la configuration de son réseau local n’est pas correcte.