Auteur Sujet: [Demi-Résolu] Icotera - Déconnexion / Micro-coupures - Problème LAN/WAN (Lu 33032 fois)

Superpicsou · « **Réponse #204 le:** 22 avril 2022 à 09:23:00 »

Si jamais l'ingé qui m'a appelé l'autre jour passe par là et lit ces lignes :

Vous pouvez me faire un update de la situation par rapport à ma box ? Soit par téléphone soit ici.
Depuis les dernières testes sur le panel j'ai toujours l'image de la netgear et je n'ai pas accès à l'onglet 'info'. J'ai toujours

Citer

La KBOX est actuellement injoignable, réessayez ultérieurement

Merci.
Des bisous.

bolemo · « **Réponse #205 le:** 24 avril 2022 à 18:41:05 »

Un petit point sur la situation des fuites K-Box/Icotera.

Mesure des fuites impliquant des adresses APIPA sur quelques secondes. Il y en a quand même pas mal.
L'échantillon montre 3 K-Box impliquées et un appareil Siemens.

Code: [Sélectionner]

root@HERMES:~$ tcpdump -i ethwan -e "net 169.254.0.0/16"                                                             
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
17:43:56.407340 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:57.121992 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:57.407403 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:57.720180 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:58.121929 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:58.720117 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:59.122179 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:43:59.720024 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:00.150452 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype IPv4 (0x0800), length 1514: 169.254.1.2.52310 > 169.254.1.1.2325: UDP, bad length 1818 > 1472
17:44:00.150483 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype IPv4 (0x0800), length 380: 169.254.1.2 > 169.254.1.1: udp
17:44:00.412588 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:01.412682 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:02.112120 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:02.412432 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:02.725209 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:03.112057 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:03.725147 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:04.112120 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:04.725053 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:05.417618 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:06.417712 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:07.117149 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:07.417618 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:07.730239 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:08.117056 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:08.730145 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:09.117149 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:09.730239 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:10.427709 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:10.861229 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype IPv4 (0x0800), length 1514: 169.254.1.2.52310 > 169.254.1.1.2325: UDP, bad length 1818 > 1472
17:44:10.861261 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype IPv4 (0x0800), length 380: 169.254.1.2 > 169.254.1.1: udp
17:44:11.427646 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:12.122335 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:12.427740 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:12.765228 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:13.122148 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:13.765322 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:14.122335 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:14.765259 00:1e:80:93:04:b0 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:15.432738 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:15.859230 00:11:33:55:77:cc (oui Unknown) > 00:11:33:55:77:bb (oui Unknown), ethertype ARP (0x0806), length 60: Reply 169.254.1.2 is-at 00:11:33:55:77:cc (oui Unknown), length 46
17:44:16.432832 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:17.127365 00:1e:80:93:0b:58 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:44:17.432738 00:1e:80:a8:40:14 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
^C
44 packets captured
44 packets received by filter
0 packets dropped by kernel

En revanche, les paquets impliquant des IPv4 privées sont absent… Une bonne nouvelle, et donc à priori une avancée du côté de K-Net sur ce problème.

Code: [Sélectionner]

root@HERMES:~$ tcpdump -i ethwan -e "(broadcast or multicast) and (net 192.168.0.0/16 or net 10.0.0.0/8 or net 172.16.0.0/12) and not (net 172.16.100.9/32 or net 10.2.0.211/32)"                                      
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes

-> silence, aucun paquet reçu.

Les deux adresses que je retire de l'écoute 172.16.100.9 et 10.2.0.211 sont le serveur DHCP de K-Net et le relais/passerelle Covage, qui envoient et reçoivent des paquets broadcast/multicast normaux (principalement les négociations DHCP avec les clients).

pju91 · « **Réponse #206 le:** 24 avril 2022 à 19:04:38 »

Citation de: bolemo le 24 avril 2022 à 18:41:05

Un petit point sur la situation des fuites K-Box/Icotera.

Mesure des fuites impliquant des adresses APIPA sur quelques secondes. Il y en a quand même pas mal.
L'échantillon montre 3 K-Box impliquées et un appareil Siemens.

S'agit-il vraiment de fuites ?
Ne pourrait-il pas s'agir simplement de box qui ne sont pas configurées côté serveur DHCP (ou ACL Covage) et qui finissent pas s'autoconfigurer en APIPA ?
Je ne connais pas l'algorithme pour les adresses MAC des K-Box, mais j'ai constaté qu'il y a une différence de 2 entre la MAC LAN et la MAC WAN de ma box.
S'il y a une règle connue (ex chez moi : 10 côté WAN et :12 côté LAN), ça permettrait de confirmer ce que j'ai écrit. D'autant plus qu'un paquet avec une adresse APIPA ne doit pas être routé (en théorie).

Citation de: bolemo le 24 avril 2022 à 18:41:05

En revanche, les paquets impliquant des IPv4 privées sont absent… Une bonne nouvelle, et donc à priori une avancée du côté de K-Net sur ce problème.
Code: [Sélectionner]
root@HERMES:~$ tcpdump -i ethwan -e "(broadcast or multicast) and (net 192.168.0.0/16 or net 10.0.0.0/8 or net 172.16.0.0/12) and not (net 172.16.100.9/32 or net 10.2.0.211/32)" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes-> silence, aucun paquet reçu.

bonne nouvelle effectivement.

bolemo · « **Réponse #207 le:** 24 avril 2022 à 19:13:34 »

Citation de: pju91 le 24 avril 2022 à 19:04:38

S'agit-il vraiment de fuites ?
Ne pourrait-il pas s'agir simplement de box qui ne sont pas configurées côté serveur DHCP (ou ACL Covage) et qui finissent pas s'autoconfigurer en APIPA ?
Je ne connais pas l'algorithme pour les adresses MAC des K-Box, mais j'ai constaté qu'il y a une différence de 2 entre la MAC LAN et la MAC WAN de ma box.
S'il y a une règle connue (ex chez moi : 10 côté WAN et :12 côté LAN), ça permettrait de confirmer ce que j'ai écrit. D'autant plus qu'un paquet avec une adresse APIPA ne doit pas être routé (en théorie).

C'est peut-être les mêmes fuites (APIPA côté LAN qui fuie) ou un troisième bogue…
Dans tous les cas ces paquets ne devraient pas être émis sur le GPON. Je n'ai pas encore essayé de les étudier en détail ni de mesurer sur un plus bogue période.

L'appareil Siemens est soit sur un LAN qui fuit, soit derrière l'ONT (switch…).

Bonne idée pour la différence MAC LAN/WAN… S'il y avait une règle, ça aiderait bien ; je verrai ça dès que j'en ai le temps.

Sinon, le silence des fuites d'adresses privées est très agréable.

bolemo · « **Réponse #208 le:** 24 avril 2022 à 19:49:20 »

Ce qui provient des adresses APIPA des K-Box, c'est des requêtes ARP.
Les deux K-Box ont la MAC 00:1e:80:93:0b:58 et 00:1e:80:93:04:b0 (la troisième n'est plus là… peut-être que son possesseur a lu mon post et fait quelque chose entre temps).
Elles ont toutes deux l'adresse 169.254.1.3 et cherchent à joindre 169.254.1.1 en ARP.

L'appareil Siemens ne communique pas seulement en broadcast ou multicast, mais aussi en unicast ! (donc peut-être directement connecté au GPON ?)
Il a pour MAC 00:11:33:55:77:cc et pour IP 169.254.1.2.
On le voit répondre en ARP à une requête ARP (que je ne reçois pas) envoyée par 00:11:33:55:77:bb (un autre appareil Siemens) :

Code: [Sélectionner]

19:35:18.098780 00:11:33:55:77:cc > 00:11:33:55:77:bb, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 169.254.1.2 is-at 00:11:33:55:77:cc, length 46

Et il communique depuis le port 52310 en udp vers cet autre appareil Siemens ayant pour MAC 00:11:33:55:77:bb et pour IP 169.254.1.2, qui reçoit en udp sur le port 2325
Un échantillon montre que ce sont principalement des statistiques réseau qui sont transmises :

Code: [Sélectionner]

        0x0050:  8bdb 0120 2053 7461 7469 7374 6963 732e  .....Statistics.
	0x0060:  2e2e 0a20 2020 2075 705f 7469 6d65 3a20  .......up_time:.
	0x0070:  3838 3234 3331 3773 200a 2020 2020 6368  8824317s......ch
	0x0080:  5f75 7469 6c69 7a61 7469 6f6e 3a09 3135  _utilization:.15
	0x0090:  0a20 2020 2074 785f 7469 6d65 3a20 2020  .....tx_time:...
	0x00a0:  2020 2020 300a 2020 2020 7278 5f74 696d  ....0.....rx_tim
	0x00b0:  653a 2020 2020 2020 2030 0a20 2020 2074  e:.......0.....t
	0x00c0:  785f 7061 636b 6574 733a 2020 2020 3236  x_packets:....26
	0x00d0:  3130 3535 360a 2020 2020 7478 5f62 7974  10556.....tx_byt
	0x00e0:  6573 3a20 2020 2020 2033 3639 3038 3038  es:......3690808
	0x00f0:  3738 310a 2020 2020 7478 5f6d 676e 745f  781.....tx_mgnt_
	0x0100:  706b 7473 3a20 3139 3437 3337 340a 2020  pkts:.1947374...
	0x0110:  2020 7478 5f75 6361 7374 5f70 6b74 733a  ..tx_ucast_pkts:
	0x0120:  2034 3534 3639 3032 0a20 2020 2074 785f  .4546902.....tx_
	0x0130:  6d63 6173 745f 706b 7473 3a20 3637 3030  mcast_pkts:.6700
	0x0140:  0a20 2020 2074 785f 6263 6173 745f 706b  .....tx_bcast_pk
	0x0150:  7473 3a20 3433 3238 0a20 2020 2074 785f  ts:.4328.....tx_
	0x0160:  7265 7472 7973 3a20 2020 2020 3231 3433  retrys:.....2143
	0x0170:  3333 0a20 2020 2074 785f 6661 696c 733a  33.....tx_fails:
	0x0180:  2020 2020 2020 3534 3133 0a20 2020 2074  ......5413.....t
	0x0190:  785f 6472 6f70 733a 2020 2020 2020 3731  x_drops:......71
	0x01a0:  3039 0a20 2020 2074 785f 646d 615f 6572  09.....tx_dma_er
	0x01b0:  723a 2020 2020 300a 2020 2020 7278 5f64  r:....0.....rx_d
	0x01c0:  6d61 5f65 7272 3a20 2020 2030 0a20 2020  ma_err:....0....

Peut-être un routeur et son satellite, mal paramètres (parce que en APIPA) et qui fuient sur le LAN ?

bolemo · « **Réponse #209 le:** 25 avril 2022 à 01:14:13 »

J'ai parlé trop vite pour les fuites d'adresses privées qui sont parties…
Ma commande initiale ne les capte pas les IP en 224.xxx (mdns)

Donc en ayant ajusté la commande, on voit encore des fuites qui implique des adresses privées :

Code: [Sélectionner]

root@HERMES:~$  tcpdump -i ethwan -tnev "ether[6:2] == 0x001e and ether[8:1] == 0x80" | grep -e " 192.168." -e " 10." -e " 172.16." -B1
tcpdump: listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33548, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.55782 > 224.0.0.251.5353: 11533 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33549, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.57556 > 224.0.0.251.5353: 11534 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33551, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.44442 > 224.0.0.251.5353: 11535 PTR (QM)? 192.168.1.243.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33552, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.47410 > 224.0.0.251.5353: 11536 PTR (QM)? 192.168.1.243.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33553, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.40434 > 224.0.0.251.5353: 11537 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33554, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.59524 > 224.0.0.251.5353: 11538 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33557, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.59130 > 224.0.0.251.5353: 11539 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 33558, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.56713 > 224.0.0.251.5353: 11540 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
--
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34182, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.35433 > 224.0.0.251.5353: 11541 PTR (QM)? 192.168.1.209.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34183, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.59909 > 224.0.0.251.5353: 11542 PTR (QM)? 192.168.1.209.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34184, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.42246 > 224.0.0.251.5353: 11543 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34186, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.50066 > 224.0.0.251.5353: 11544 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34187, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.48482 > 224.0.0.251.5353: 11545 PTR (QM)? 192.168.1.243.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34188, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.47755 > 224.0.0.251.5353: 11546 PTR (QM)? 192.168.1.243.in-addr.arpa. (44)
--
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34189, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.60920 > 224.0.0.251.5353: 11547 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34190, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.47587 > 224.0.0.251.5353: 11548 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34192, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.45269 > 224.0.0.251.5353: 11549 PTR (QM)? 192.168.1.120.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34193, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.42585 > 224.0.0.251.5353: 11550 PTR (QM)? 192.168.1.120.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34196, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.51903 > 224.0.0.251.5353: 11551 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 1, id 34197, offset 0, flags [DF], proto UDP (17), length 72)
    92.118.99.232.51611 > 224.0.0.251.5353: 11552 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
^C122 packets captured
123 packets received by filter
0 packets dropped by kernel

pju91 · « **Réponse #210 le:** 25 avril 2022 à 08:46:51 »

Citation de: bolemo le 25 avril 2022 à 01:14:13

J'ai parlé trop vite pour les fuites d'adresses privées qui sont parties…
Ma commande initiale ne les capte pas les IP en 224.xxx (mdns)

Donc en ayant ajusté la commande, on voit encore des fuites qui implique des adresses privées :

Bizarre, ça ne m'avait pas interpelé en regardant ton post précédent. Je pensais qu'avec les conditions de ton filtre tcpdump qui doit garder les multicasts (comme 01:00:5e:00:00:fb) avec une adresse en 192.168/16, les paquets mDNS auraient été conservés.
Et on voit bien sur cette nouvelle trace que ces paquets ont une entête IP correcte, avec un TTL à 1, confirmant d'ailleurs qu'ils ne doivent pas traverser un routeur.

Superpicsou · « **Réponse #211 le:** 25 avril 2022 à 09:15:19 »

De mon côté c'est quand même plus calme.

On passe de ça vendredi en quelques secondes

Code: [Sélectionner]

sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."                                                                                                                                                            130 ↵
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
16:26:16.482212 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:26:16.517714 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:18.482067 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.56 tell 192.168.1.36, length 46
16:26:19.020972 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
16:26:20.760805 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
16:26:21.482139 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.26 tell 192.168.1.36, length 46
16:26:22.706413 7c:26:64:de:d4:bc > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.254 (7c:26:64:de:d4:bc) tell 0.0.0.0, length 46
16:26:22.926856 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.36341 > 224.0.0.251.5353: 21672 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
16:26:23.482125 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:26:24.482088 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:24.482408 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:26.537951 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:28.481897 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:26:29.247672 f0:9f:c2:7c:6a:73 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.26, length 46
16:26:30.481830 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.56 tell 192.168.1.36, length 46
16:26:33.967220 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.33527 > 224.0.0.251.5353: 21680 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
16:26:33.998734 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.41385 > 224.0.0.251.5353: 21682 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
16:26:34.030211 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.34575 > 224.0.0.251.5353: 21684 PTR (QM)? 192.168.1.168.in-addr.arpa. (44)
16:26:35.481786 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:26:36.557669 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:40.482126 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:26:40.482556 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.26 tell 192.168.1.36, length 46
16:26:42.481746 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.56 tell 192.168.1.36, length 46
16:26:42.482187 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:45.169935 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.58670 > 224.0.0.251.5353: 21694 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
16:26:46.577506 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:47.481692 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:26:52.481924 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:26:52.482211 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.26 tell 192.168.1.36, length 46
16:26:54.481830 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.56 tell 192.168.1.36, length 46
16:26:54.482122 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:54.482529 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
16:26:56.597905 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 777: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 735
16:26:56.666724 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.53264 > 224.0.0.251.5353: 21710 PTR (QM)? 192.168.1.202.in-addr.arpa. (44)
16:26:59.481808 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:27:00.886674 f0:9f:c2:7c:6a:73 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.26, length 46
16:27:04.481722 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.58 tell 192.168.1.36, length 46
16:27:06.481741 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.56 tell 192.168.1.36, length 46
16:27:06.617468 60:a4:b7:ef:cc:2e > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 778: 192.168.1.56.60528 > 255.255.255.255.29810: UDP, length 736
16:27:07.537293 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.40481 > 224.0.0.251.5353: 21711 PTR (QM)? 192.168.1.242.in-addr.arpa. (44)
16:27:07.569811 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.39840 > 224.0.0.251.5353: 21713 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
16:27:07.613010 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.39121 > 224.0.0.251.5353: 21716 PTR (QM)? 192.168.1.201.in-addr.arpa. (44)
16:27:11.481740 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.65 tell 192.168.1.36, length 46
16:27:12.481711 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.26 tell 192.168.1.36, length 46
16:27:12.482018 40:3f:8c:85:8a:5a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.1 tell 192.168.1.36, length 46
^C456 packets captured
852 packets received by filter
0 packets dropped by kernel

à ça aujourd'hui en plusieurs minutes

Code: [Sélectionner]

sudo tcpdump -ne ether broadcast or ether multicast |grep "192\.168\.1\."
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
09:14:10.958801 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.52696 > 224.0.0.251.5353: 14241 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
09:14:22.271957 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.58543 > 224.0.0.251.5353: 14257 PTR (QM)? 192.168.1.111.in-addr.arpa. (44)
09:14:33.377681 00:1e:80:9b:2f:90 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 92.118.99.232.34218 > 224.0.0.251.5353: 14264 PTR (QM)? 192.168.1.203.in-addr.arpa. (44)
^C109 packets captured
1237 packets received by filter

Faudrait que je test en repassant en 192.168.1.1 voir si ya toujours des perturbation.
Par contre j'ai toujours des soucis d'accés à l'interface 'info' de ma box depuis les tests des ingés.

pju91 · « **Réponse #212 le:** 25 avril 2022 à 09:58:30 »

Citation de: Superpicsou le 25 avril 2022 à 09:15:19

Faudrait que je test en repassant en 192.168.1.1 voir si ya toujours des perturbation.
Par contre j'ai toujours des soucis d'accés à l'interface 'info' de ma box depuis les tests des ingés.

Je serais toi, je resterais sur le numéro de réseau que tu as configuré. Tu as peut-être mieux à faire que débugger les problèmes K-Net.
Est-ce juste la partie "info" du panel qui bloque ? Ou tous les onglets ?
Pour info, chez moi, il faut actuellement plus de 20 secondes pour que l'onglet "info" s'affiche. Ca reste en "récupération des informations" un bon moment !

bolemo · « **Réponse #213 le:** 25 avril 2022 à 14:00:06 »

Citation de: pju91 le 25 avril 2022 à 08:46:51

Bizarre, ça ne m'avait pas interpelé en regardant ton post précédent. Je pensais qu'avec les conditions de ton filtre tcpdump qui doit garder les multicasts (comme 01:00:5e:00:00:fb) avec une adresse en 192.168/16, les paquets mDNS auraient été conservés.
Et on voit bien sur cette nouvelle trace que ces paquets ont une entête IP correcte, avec un TTL à 1, confirmant d'ailleurs qu'ils ne doivent pas traverser un routeur.

En fait, le filtre « net » de tcpdump regarde seulement la source et la destination, qui ici sont 92.118.99.232 et 224.0.0.251, donc aucune n'est dans domaine privé.

Le TTL est intéressant… L'appareil Covage se comporte comme un simple relais pour tout ce qui est broadcast et multicast, ce qui est assez logique pour les transactions DHCP (IPv4 et IPv6).
En revanche, il laisse passer des paquets unicast comme ceux APIPA !?, mais heureusement pas ceux des clients connectés à leur passerelles (traffic internet).

Le problème de fuite (qu'elles quelles soient : DHCPv6, APIPA, mdns…) est double à mon avis :

1) La source du problème avec les K-Box qui fuient.
C'est un problème sérieux à résoudre (et apparemment bien pris sérieusement par K-Net)

2) Le fait que des paquets passent entre clients sur même GPON.
Comme Covage dispose d'un relais local DHCP qui gère les transactions pour le compte du serveur K-Net (un relais quoi), je ne comprends pas pourquoi ils laissent passer les paquets broadcast et multicast sur le GPON entre clients, ainsi que quelques paquets unicast. Comme ils filtrent déjà la plupart des paquets unicast, pourquoi ne pas améliorer le filtrage pour avoir une étanchéité totale entre les clients ?
Dans ce cas, même avec des fuites, elles seraient contenues puisqu'il y aurait une étanchéité entre clients.
Depuis 2 ans, il y a eu des progrès… Je pouvais faire un arping sur tous les clients (K-Net) du GPON et obtenir leur adresses MAC et les associer à leur IP. Donc je pouvais activement chercher et trouver tous les clients. Depuis, Covage a amélioré cela et si je peux toujours faire les arpings et trouver les IP publiques K-Net existantes sur mon GPON, l'adresse MAC retournée est toujours celui de la passerelle Covage, donc la MAC des clients et protégée de recherches actives (la recherche passive reste possible en écoutant les transactions DHCP impliquant du broadcast ou du multicast, excluant les DHCPv4 renew qui sont unicast)

Les problèmes existent parce que les points 1 et 2 existent simultanément.

Question aux experts réseau et infrastructure : y-a-t'il une difficulté technique ou une raison particulière empêchant Covage de réaliser une étanchéité totale entre clients sur un même GPON ?

Superpicsou · « **Réponse #214 le:** 25 avril 2022 à 14:00:49 »

Citation de: pju91 le 25 avril 2022 à 09:58:30

Pour info, chez moi, il faut actuellement plus de 20 secondes pour que l'onglet "info" s'affiche. Ca reste en "récupération des informations" un bon moment !

J'ai directement le message

Citer

pLa KBOX est actuellement injoignable, réessayez ultérieurement

bolemo · « **Réponse #215 le:** 25 avril 2022 à 14:03:04 »

Citation de: Superpicsou le 25 avril 2022 à 14:00:49

La KBOX est actuellement injoignable, réessayez ultérieurement

Bah, ils on connecté l'interface sur la même architecture que la téléphonie…