La Fibre

Forum : => Calvados (14) => La Fibre par département => Calvados (14 - Altitude Infra) => Discussion démarrée par: bolemo le 29 octobre 2020 à 14:11:56

Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 29 octobre 2020 à 14:11:56: 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) :
Code: [Sélectionner]
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 :
Code: [Sélectionner]
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-fr
Donc 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.
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 31 octobre 2020 à 17:09:52: Les paquets en provenance de l’adresse 255.255.255.255 sont transmis par les switches, mais en principe pas par les routeurs. Ce n’est donc adressé qu’à tous les voisins d’un même réseau.

Ça semble cohérent puisqu’arp ne peut voir que le voisinage réseau.

Donc ça serait un appareil sur la boucle locale, avant le premier routeur de Covage, donc sur le même switch que moi dans le NRO, et ça pourrait donc venir d’un client en offre passive.

A moins qu’un routeur Covage laisse passer cette adresse...

Personne de chez Covage ici qui pourrait vérifier d’où ça provient ?
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Steph le 31 octobre 2020 à 17:34:03: En principe, les adresse APIPA sont locales au subnet.

Ce serait sympa d'avoir des gens de chez Covage sur ce forum. Je n'en ai malheureusement jamais vu... ou du moins, ils ne l'ont pas dit...
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 31 octobre 2020 à 18:00:53: C’est cohérent.

Un appareil domotique ne reçoit aucune configuration DHCP, donc il se donne une adresse APIPA.
Ensuite, il cherche à communiquer avec tous ses voisins sur son voisinage avec une requête UDP de type JSON, probablement un esclave qui cherche son maître, ou un maître qui cherches les esclaves de ce système domotique.

Maintenant pourquoi ces paquets se retrouvent-ils dans une boucle de collecte Covage ?

Comment une adresse non attribuée par Covage (et derrière les FAI) peut elle envoyer des paquets à tous le voisinage, et qu’elle est la taille du voisinage ?

Apparemment, cela laisse entendre que n’importe quel appareil connecté à un ONT ou sur un switch sur l’ONT peut s’attribuer une adresse et envoyer des paquets à tout le voisinage (département ?).

Tant que l’on rencontre des switches, à priori, on reste local.
Donc, où se trouve le tout premier routeur ? Au NRO, à la collecte départementale ?

Le premier que je peux pinguer ou qui répond à traceroute est le fameux 10.2.0.211, la collecte départementale du 14, donc est-ce que cet appareil envoie des paquets dans tout le 14 ou seulement mon NRO ?

Ici, c’est clairement quelqu’un qui a très mal configuré son réseau (et son appareil ne fonctionne probablement pas ainsi), et sans danger, mais cela soulève des questions de sécurité...
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Steph le 31 octobre 2020 à 18:51:45: Pour le voisinage, dificile à dire : cela dépend de qui voit qui. Après l'OLT, je ne sais pas trop ce qu'il y a...

Le premier routeur de collecte est en 10.2.0.x et en gros, il y en a un par département (sauf dans le 77 où il y en a plein...)
https://forum.caps.services/index.php/topic,7534.msg95039.html

Il faudrait que d'autres utilisateur de Covage 14 nous disent s'ils voient ses fameux paquets.
C'est peut être parce que ces paquets peuvent se balader qu'ils y a des problèmes sporadiques sur le réseau Covage14 en ce momment?

Je n'ai jamais très bien compris comment marchent les sous-réseaus Covage en 10.2.0.x.
Nos routeurs ont bien une passerelle en IPpublique.254 chez K-net, adresse portée par le routeur Covage 10.2.0.x? Routeur qui forward tout à K-net.
Il ne forward certainement pas les paquets APIPA que tu reçois.

Concernant la sécurité du sous-réseau, j'ai l'impression que c'est fragile : N'importe quelle appareil avec n'importe quelle IP peut causer sur le sous réseau. Il ne passera pas le routeur si l'IP n'est pas reconnues. Et l'IP en question doit être distribuée par DHCP avec association MAC pour la sécurité.
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 31 octobre 2020 à 20:33:46: Oui, je crois qu’à partir du routeur départemental, les paquets sont bloqués.
Avant, ce ne sont probablement que des switches.

L’IP APIPA a de nouveau changée, maintenant, c’est 169.254.189.112

Ça ne m’étonnerait pas que ces paquets perturbent certaines boxes, oui...
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Mimou1208 le 01 novembre 2020 à 11:39:55: Bonjour, voilà ce que j'ai chez moi sur mon routeur Netgear dans mes logs

[LAN access from remote] from 169.254.189.112:5353 to 192.168.1.5:5353, Sunday, November 01, 2020 11:32:44

Je joint aussi un screen de mon geofiltrage qui m'indique que l'équipement fait quand même pas mal de ping :o
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 01 novembre 2020 à 13:48:46: @Mimou1208 : C’est vraiment curieux ça ! Cet appareil envoie aussi des paquets chez vous, mais depuis un autre port 5353 vers 5353 qui est du multicast DNS.
Avez-vous moyen de faire un tcpdump des paquets que vous recevez pour voir si ce sont les mêmes que les miens ?

Si oui, il y aurait donc un routeur chez Covage qui ferait de la redirection de port pour cet appareil... Ça serait curieux.

Si non, cet appareil envoie plusieurs paquets sur différents ports, mais je ne reçois que ceux concernant le port 49150, et vous ceux concernant le port 5353 (et il y aurait donc un filtrage partiel de certains ports dans la boucle Covage).

Quoi qu’il e soit, c’est de plus en plus curieux... Vous êtes dans quel coin du Calvados ?

EDIT : un instant, l’appareil cible un appareil spécifique de votre LAN ! 192.168.1.5
Mon log Netgear ne me montre pas les paquets, c’est mon script perso Aegis qui les bloque (blocage par iptables depuis des listes ipset, du même genre que FireHOL). Peut-être que les paquets du port 49150 arrivent bien chez vous aussi (ils ne ciblent personne en particulier, broadcast), mais le paquet que votre routeur a détecté semble ciblé. Avez vous une règle NAT pour le port 5353 ?
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 02 novembre 2020 à 13:23:29: L’IP a de nouveau changé: 169.254.228.175
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 05 novembre 2020 à 17:24:24: Maintenant : 169.254.196.192
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Steph le 05 novembre 2020 à 17:32:10: T'as essayé de contacter un expert Covage? ;)
https://www.covage.com
pied de page "Vous avez des questions?"

On peut toujours rêver...
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 05 novembre 2020 à 18:13:45: Citation de: Steph le 05 novembre 2020 à 17:32:10
T'as essayé de contacter un expert Covage? ;)
https://www.covage.com
pied de page "Vous avez des questions?"

On peut toujours rêver...

C’est fait.
J’ai été technique et spécifique. À suivre...
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Boule2gom le 06 novembre 2020 à 10:37:18: Si tu as une réponse, joues au loto de suite.
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 06 novembre 2020 à 12:50:02: On verra bien. Peut-être le côté technique et inhabituel de la demande les fera réagir.
Je pensais aussi informer K-Net sur leur support technique pour qu’ils remontent à Covage, mais comme ils sont déjà débordés, je vais attendre.
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Steph le 06 novembre 2020 à 14:58:32: Vincent a sans doute vu passé ce fil et celui sur Caps. :)
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Steph le 06 novembre 2020 à 15:04:06: Citation de: Boule2gom le 06 novembre 2020 à 10:37:18
Si tu as une réponse, joues au loto de suite.
Ouais, on peut rêver...
J'ai déjà signaler des NRO ouverts et ils s'en foutent royalement...
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 13 novembre 2020 à 17:54:21: L’IP est maintenant 169.254.166.248
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 15 novembre 2020 à 13:39:40: Elle a changé à nouveau : 169.254.119.215

Toujours rien de Covage (pas une surprise).

Incroyable qu’ils laissent passer ces paquets envoyés toutes les 10/15 secondes et qui parasitent tous les clients fibre sur la boucle !
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Steph le 15 novembre 2020 à 14:36:09: C'est peut-être du matos Covage? :-X

Le section "Fibre Calvados" est peut-être un peu confidentielle pour avoir d'autres avis.
Les gens de Covage (et des OI en général à quelques exceptions près) n'ont pas l'air de fréquenter beaucoup ce forum.
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 15 novembre 2020 à 18:12:37: Et ça a encore changé : 169.254.16.41 ; deux fois aujourd’hui. Avant, ça n’avait pas bougé pendant des jours.

Peut-être une caméra IP ou un thermostat connecté dans la loge NRO :o
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 16 novembre 2020 à 15:29:54: 169.254.151.13
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 17 novembre 2020 à 16:56:22: Depuis hier, je reçois en plus une multitude de paquets venant de la plage d’IP 192.168.14.xx
Environ 5 paquets par secondes, tous UDP, principalement vers le port 6666 ou 6667 (depuis 49154, 49155 ou 49156), l’IP de destination est le broadcast 255.255.255.255

Un tcpdump plus tôt (pas celui ci-dessous) m’a indiqué que les émetteurs sont des appareils multiples (freebox, netatmo...)

Un échantillon tcpdump :
Code: [Sélectionner]
root@HERMES:~$ tcpdump -v -i brwan -X net 192.168.14.0/24 tcpdump: listening on brwan, link-type EN10MB (Ethernet), capture size 96 bytes 16:43:55.321468 IP (tos 0x0, ttl 255, id 3537, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.212.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 0dd1 0000 ff11 ddd3 c0a8 0ed4 E............... 0x0010: ffff ffff c002 1a0a 00b8 6799 0000 55aa ..........g...U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3231 3222 2c22 6777 4964 4.212","gwId 16:43:55.451365 IP (tos 0x0, ttl 255, id 27869, offset 0, flags [none], proto UDP (17), length 200) 192.168.14.113.49153 > 255.255.255.255.6667: UDP, length 172 0x0000: 4500 00c8 6cdd 0000 ff11 7f2e c0a8 0e71 E...l..........q 0x0010: ffff ffff c001 1a0b 00b4 eaa6 0000 55aa ..............U. 0x0020: 0000 0000 0000 0013 0000 009c 0000 0000 ................ 0x0030: d097 6667 6f33 69eb 10b5 e9f1 32fd 802a ..fgo3i.....2..* 0x0040: 2ccd 3a32 d780 57e6 607a 51db ,.:2..W.`zQ. 16:43:55.481668 IP (tos 0x0, ttl 255, id 9289, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.153.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 2449 0000 ff11 c796 c0a8 0e99 E...$I.......... 0x0010: ffff ffff c002 1a0a 00b8 d1fa 0000 55aa ..............U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3135 3322 2c22 6777 4964 4.153","gwId 16:43:55.767454 IP (tos 0x0, ttl 255, id 36379, offset 0, flags [none], proto UDP (17), length 200) 192.168.14.106.49153 > 255.255.255.255.6667: UDP, length 172 0x0000: 4500 00c8 8e1b 0000 ff11 5df7 c0a8 0e6a E.........]....j 0x0010: ffff ffff c001 1a0b 00b4 18d1 0000 55aa ..............U. 0x0020: 0000 0000 0000 0013 0000 009c 0000 0000 ................ 0x0030: d097 6667 6f33 69eb 10b5 e9f1 32fd 802a ..fgo3i.....2..* 0x0040: 70f0 76b2 f329 c371 4ac0 8d64 p.v..).qJ..d 16:43:55.820500 IP (tos 0x0, ttl 255, id 1878, offset 0, flags [none], proto UDP (17), length 200) 192.168.14.237.49154 > 255.255.255.255.6667: UDP, length 172 0x0000: 4500 00c8 0756 0000 ff11 e439 c0a8 0eed E....V.....9.... 0x0010: ffff ffff c002 1a0b 00b4 f867 0000 55aa ...........g..U. 0x0020: 0000 0000 0000 0013 0000 009c 0000 0000 ................ 0x0030: d097 6667 6f33 69eb 10b5 e9f1 32fd 802a ..fgo3i.....2..* 0x0040: 2f3d bca9 3bb9 71dd e62a e140 /=..;.q..*.@ 16:43:55.840962 IP (tos 0x0, ttl 255, id 33880, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.198.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 8458 0000 ff11 675a c0a8 0ec6 E....X....gZ.... 0x0010: ffff ffff c002 1a0a 00b8 82f1 0000 55aa ..............U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3139 3822 2c22 6777 4964 4.198","gwId 16:43:55.892259 IP (tos 0x0, ttl 255, id 57396, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.157.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc e034 0000 ff11 0ba7 c0a8 0e9d E....4.......... 0x0010: ffff ffff c002 1a0a 00b8 bbe5 0000 55aa ..............U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3135 3722 2c22 6777 4964 4.157","gwId 16:43:56.114783 IP (tos 0x0, ttl 255, id 6571, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.114.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 19ab 0000 ff11 d25b c0a8 0e72 E..........[...r 0x0010: ffff ffff c002 1a0a 00b8 7f1f 0000 55aa ..............U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3131 3422 2c22 6777 4964 4.114","gwId 16:43:56.618938 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 579) 192.168.14.168.45954 > 255.255.255.255.1900: UDP, length 551 0x0000: 4500 0243 0000 4000 4011 695a c0a8 0ea8 E..C..@.@.iZ.... 0x0010: ffff ffff b382 076c 022f ae56 4e4f 5449 .......l./.VNOTI 0x0020: 4659 202a 2048 5454 502f 312e 310d 0a48 FY.*.HTTP/1.1..H 0x0030: 4f53 543a 2032 3339 2e32 3535 2e32 3535 OST:.239.255.255 0x0040: 2e32 3530 3a31 3930 300d 0a43 .250:1900..C 16:43:56.635901 IP (tos 0x0, ttl 255, id 31576, offset 0, flags [none], proto UDP (17), length 200) 192.168.14.207.49154 > 255.255.255.255.6667: UDP, length 172 0x0000: 4500 00c8 7b58 0000 ff11 7055 c0a8 0ecf E...{X....pU.... 0x0010: ffff ffff c002 1a0b 00b4 3c94 0000 55aa ..........<...U. 0x0020: 0000 0000 0000 0013 0000 009c 0000 0000 ................ 0x0030: d097 6667 6f33 69eb 10b5 e9f1 32fd 802a ..fgo3i.....2..* 0x0040: 70ae 10d0 0a73 aa19 eb0d e417 p....s...... 16:43:56.668672 IP (tos 0x0, ttl 64, id 57415, offset 0, flags [DF], proto UDP (17), length 49) 192.168.14.249.55132 > 192.168.14.255.32414: UDP, length 21 0x0000: 4500 0031 e047 4000 4011 bb2b c0a8 0ef9 E..1.G@.@..+.... 0x0010: c0a8 0eff d75c 7e9e 001d 9431 4d2d 5345 .....\~....1M-SE 0x0020: 4152 4348 202a 2048 5454 502f 312e 310d ARCH.*.HTTP/1.1. 0x0030: 0a . 16:43:56.697663 IP (tos 0x0, ttl 255, id 6518, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.199.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 1976 0000 ff11 d23b c0a8 0ec7 E....v.....;.... 0x0010: ffff ffff c002 1a0a 00b8 6e0c 0000 55aa ..........n...U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3139 3922 2c22 6777 4964 4.199","gwId 16:43:56.809503 IP (tos 0x0, ttl 64, id 57494, offset 0, flags [DF], proto UDP (17), length 49) 192.168.14.249.35467 > 192.168.14.255.32412: UDP, length 21 0x0000: 4500 0031 e096 4000 4011 badc c0a8 0ef9 E..1..@.@....... 0x0010: c0a8 0eff 8a8b 7e9c 001d e104 4d2d 5345 ......~.....M-SE 0x0020: 4152 4348 202a 2048 5454 502f 312e 310d ARCH.*.HTTP/1.1. 0x0030: 0a . 16:43:56.818844 arp who-has 192.168.14.1 tell 192.168.14.203 0x0000: 0001 0800 0604 0001 70ee 501b ff3a c0a8 ........p.P..:.. 0x0010: 0ecb 0000 0000 0000 c0a8 0e01 0000 0000 ................ 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 16:43:56.864017 IP (tos 0x0, ttl 255, id 37966, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.220.49155 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 944e 0000 ff11 574e c0a8 0edc E....N....WN.... 0x0010: ffff ffff c003 1a0a 00b8 cc43 0000 55aa ...........C..U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3232 3022 2c22 6777 4964 4.220","gwId 16:43:56.881106 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 632) 192.168.14.168.45954 > 255.255.255.255.1900: UDP, length 604 0x0000: 4500 0278 0000 4000 4011 6925 c0a8 0ea8 E..x..@.@.i%.... 0x0010: ffff ffff b382 076c 0264 4f43 4e4f 5449 .......l.dOCNOTI 0x0020: 4659 202a 2048 5454 502f 312e 310d 0a48 FY.*.HTTP/1.1..H 0x0030: 4f53 543a 2032 3339 2e32 3535 2e32 3535 OST:.239.255.255 0x0040: 2e32 3530 3a31 3930 300d 0a43 .250:1900..C 16:43:57.120406 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 582) 192.168.14.168.45954 > 255.255.255.255.1900: UDP, length 554 0x0000: 4500 0246 0000 4000 4011 6957 c0a8 0ea8 E..F..@.@.iW.... 0x0010: ffff ffff b382 076c 0232 1aec 4e4f 5449 .......l.2..NOTI 0x0020: 4659 202a 2048 5454 502f 312e 310d 0a48 FY.*.HTTP/1.1..H 0x0030: 4f53 543a 2032 3339 2e32 3535 2e32 3535 OST:.239.255.255 0x0040: 2e32 3530 3a31 3930 300d 0a43 .250:1900..C 16:43:57.234527 arp who-has 192.168.14.1 tell 192.168.14.205 0x0000: 0001 0800 0604 0001 70ee 5011 dc8a c0a8 ........p.P..... 0x0010: 0ecd 0000 0000 0000 c0a8 0e01 0000 0000 ................ 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 16:43:57.300162 IP (tos 0x0, ttl 255, id 49948, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.176.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc c31c 0000 ff11 28ac c0a8 0eb0 E.........(..... 0x0010: ffff ffff c002 1a0a 00b8 6a75 0000 55aa ..........ju..U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3137 3622 2c22 6777 4964 4.176","gwId 16:43:57.708972 IP (tos 0x0, ttl 255, id 30090, offset 0, flags [none], proto UDP (17), length 216) 192.168.14.111.49154 > 255.255.255.255.6667: UDP, length 188 0x0000: 4500 00d8 758a 0000 ff11 7673 c0a8 0e6f E...u.....vs...o 0x0010: ffff ffff c002 1a0b 00c4 3439 0000 55aa ..........49..U. 0x0020: 0000 0000 0000 0013 0000 00ac 0000 0000 ................ 0x0030: d097 6667 6f33 69eb 10b5 e9f1 32fd 802a ..fgo3i.....2..* 0x0040: b617 5e3d c0aa f37f efa4 5e13 ..^=......^. 16:43:57.960800 IP (tos 0x0, ttl 255, id 5108, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.171.49156 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 13f4 0000 ff11 d7d9 c0a8 0eab E............... 0x0010: ffff ffff c004 1a0a 00b8 889c 0000 55aa ..............U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3137 3122 2c22 6777 4964 4.171","gwId 16:43:57.987947 IP (tos 0x0, ttl 255, id 45664, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.226.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc b260 0000 ff11 3936 c0a8 0ee2 E....`....96.... 0x0010: ffff ffff c002 1a0a 00b8 9566 0000 55aa ...........f..U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3232 3622 2c22 6777 4964 4.226","gwId 16:43:58.118938 arp who-has 192.168.14.1 (Broadcast) tell 192.168.14.201 0x0000: 0001 0800 0604 0001 f406 8d73 2fe0 c0a8 ...........s/... 0x0010: 0ec9 ffff ffff ffff c0a8 0e01 0000 0000 ................ 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 16:43:58.255520 IP (tos 0x0, ttl 255, id 36443, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.102.49156 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 8e5b 0000 ff11 5db7 c0a8 0e66 E....[....]....f 0x0010: ffff ffff c004 1a0a 00b8 faf4 0000 55aa ..............U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3130 3222 2c22 6777 4964 4.102","gwId 16:43:58.321531 IP (tos 0x0, ttl 255, id 3538, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.212.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 0dd2 0000 ff11 ddd2 c0a8 0ed4 E............... 0x0010: ffff ffff c002 1a0a 00b8 6799 0000 55aa ..........g...U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3231 3222 2c22 6777 4964 4.212","gwId 16:43:58.481856 IP (tos 0x0, ttl 255, id 9290, offset 0, flags [none], proto UDP (17), length 204) 192.168.14.153.49154 > 255.255.255.255.6666: UDP, length 176 0x0000: 4500 00cc 244a 0000 ff11 c795 c0a8 0e99 E...$J.......... 0x0010: ffff ffff c002 1a0a 00b8 d1fa 0000 55aa ..............U. 0x0020: 0000 0000 0000 0000 0000 00a0 0000 0000 ................ 0x0030: 7b22 6970 223a 2231 3932 2e31 3638 2e31 {"ip":"192.168.1 0x0040: 342e 3135 3322 2c22 6777 4964 4.153","gwId ^C 26 packets captured 27 packets received by filter 0 packets dropped by kernel
Et pas mal de messages ARP qui circulent pour ce sous-réseau :
Code: [Sélectionner]
root@HERMES:~$ tcpdump -v -i brwan -X arp net 192.168.14.0/24 tcpdump: listening on brwan, link-type EN10MB (Ethernet), capture size 96 bytes 16:50:01.012971 arp who-has 192.168.14.1 (Broadcast) tell 192.168.14.201 0x0000: 0001 0800 0604 0001 f406 8d73 2fe0 c0a8 ...........s/... 0x0010: 0ec9 ffff ffff ffff c0a8 0e01 0000 0000 ................ 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 16:50:04.097101 arp who-has 192.168.14.1 (Broadcast) tell 192.168.14.201 0x0000: 0001 0800 0604 0001 f406 8d73 2fe0 c0a8 ...........s/... 0x0010: 0ec9 ffff ffff ffff c0a8 0e01 0000 0000 ................ 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 16:50:04.255707 arp who-has 192.168.14.1 tell 192.168.14.203 0x0000: 0001 0800 0604 0001 70ee 501b ff3a c0a8 ........p.P..:.. 0x0010: 0ecb 0000 0000 0000 c0a8 0e01 0000 0000 ................ 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 16:50:04.674983 arp who-has 192.168.14.1 tell 192.168.14.205 0x0000: 0001 0800 0604 0001 70ee 5011 dc8a c0a8 ........p.P..... 0x0010: 0ecd 0000 0000 0000 c0a8 0e01 0000 0000 ................ 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 16:50:05.050678 arp who-has 192.168.14.111 tell 192.168.14.111 0x0000: 0001 0800 0604 0001 5002 9158 e81c c0a8 ........P..X.... 0x0010: 0e6f 0000 0000 0000 c0a8 0e6f 0000 0000 .o.........o.... 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. ^C 5 packets captured 5 packets received by filter 0 packets dropped by kernel
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: Steph le 25 mai 2022 à 15:45:33: Citation de: bolemo le 17 novembre 2020 à 16:56:22
Environ 5 paquets par secondes, tous UDP, principalement vers le port 6666 ou 6667 (depuis 49154, 49155 ou 49156), l’IP de destination est le broadcast 255.255.255.255
J'ai un robot aspirateur connecté qui envoie toutes les 30s un paquet UDP 6666 en broadcast sur mon lan.
Titre: Paquets UDP APIPA dans la boucle locale Covage 14
Posté par: bolemo le 25 mai 2022 à 17:50:00: Citation de: Steph le 25 mai 2022 à 15:45:33
J'ai un robot aspirateur connecté qui envoie toutes les 30s un paquet UDP 6666 en broadcast sur mon lan.

C'était probablement un appareil IoT de ce type oui !

Deux and plus tard, je ne vois plus cet appareil là, mais ça reste un beau bazar (par exemple : https://lafibre.info/k-net-incident/ca-recommence-spam-eleve-de-trames-ipv6-dans-le-gpon-k-net-covage-14-et-91/)

Covage a amélioré depuis le relais ARP pour les arping (seul le relais répond, et il ne transmets pas au delà, mais comme je reçois des paquets d'ailleurs, d'autres relais transmettent encore…), ce qui est un petit progrès, mais clairement, le manque d'étanchéité de la collecte (enfin du groupement de collectes 14 et 91 ex-Tutor qui sont toutes reliées) reste un gros problème, en particulier avec les fuites LAN/WAN de certaines box.

En dehors des paquets circulant entre l'IP publique et la passerelle pour le traffic internet (qui ne fuient pas de toute façon), seuls les paquets DHCP IPv4 et IPv6 (et les paquets ARP, ICMP sous-jacents) devraient être autorisés à passer au delà du premier switch/routeur de la collecte ; tout le reste devrait être bloqué.