J'ai essayé, et je peux stopper ces fuites  APIPA (enfin ⅔) en envoyant cette trame 

Désolé mais là, tu m'as troué le cul.

Bravo !

00:11:33:55:77:bb
[...]
un appareil Siemens

Nope.

Bravo bolemo, je n'y croyais pas à cette possibilité de "stopper" les fuites !!!

La fragilité des K-Box, en tout cas avec cette version de firmware, me sidère.
Ca forme un cocktail "explosif" avec le design pourri du réseau Covage 14&91.
Malheureusement, si Covage + K-Net + Icotera ne font pas le nécessaire ensemble pour corriger, ça restera très instable pour les clients K-Box de ce réseau 14&91.

Par ailleurs, je te confirme que, en lançant des captures LAN régulièrement, je n'ai jamais vu de trafic étranger à mon LAN. La seule fois où j'ai regardé côté WAN, c'était "propre".

On n'a pas de nouvelles du technicien support Icotera (en Pologne), mais ça vaudrait le coup de documenter tout ce que tu as fait (même s'il a refusé de continuer la discussion avec nous, il ne voulait échanger qu'avec K-Net).

Et un petit crontab qui va bien devrait protéger notre collecte 

* * * * * /opt/bolemo/scripts/sendrawpacket.py ethwan /mnt/optware/apipa-fix-packet2.dat
J'envoie le paquet « stop » toutes les minutes, en prévention.

Je viens de regarder ton grafana, ça a l'air de bien fonctionner ... Merci pour ceux concernés !

Je pense vraiment que ce paquet « stop » empêche l'émission des paquets APIPA à leur source, mais ne résout pas le problème de fuite que je pense plus large qu'il paraît…

Pour l'instant. J'ai même repéré un paquet qui a stoppé la dernière K-Box qui fuyait en APIPA, c'est donc ce dernier que j'utilise maintenant.
J'ai modifié pour envoyer un paquet toutes les 5 minutes.

Tout ce que j'espère, c'est que d'envoyer régulièrement ce paquet (qui est un APIPA) ne vient pas perturber la connexion d'autres personnes.

Par contre, cela ne change rien pour ce mystérieux 00:11:33:55:77:cc (qui envoie des ARP Reply et en UDP des statistiques de connexion à 00:11:33:55:77:bb. Son interface est wlan0, donc un appareil Wifi… un répéteur ? une box TV peut-être ? VincentO2, un indice ?)

root@HERMES:~$ tcpdump -i ethwan -Q in -Aq ether src 00:11:33:55:77:cc
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
13:50:24.725477 IP 169.254.1.2.52310 > 169.254.1.1.2325: UDP, bad length 1817 > 1472
E...G. .@............V ..!l.....wlan0...........~....................  Statistics...
    up_time: 11136740s
    ch_utilization: 0
    tx_time:       0
    rx_time:       0
    tx_packets:    2763785
    tx_bytes:      3864269157
    tx_mgnt_pkts: 2594160
    tx_ucast_pkts: 5345192
    tx_mcast_pkts: 6717
    tx_bcast_pkts: 6036
    tx_retrys:     255743
    tx_fails:      8416
    tx_drops:      9443
    tx_dma_err:    0
    rx_dma_err:    0
    tx_dma_status: 0
    rx_dma_status: 0
    rx_packets:    589139
    rx_bytes:      118714590
    rx_mgnt_pkts: 28221815
    rx_ucast_pkts: 569188
    rx_mcast_pkts: 21693
    rx_bcast_pkts: 28220073
    rx_retrys:     37815
    rx_crc_errors: 0
    rx_errors:     0
    rx_data_drops: 72
    rx_mc_pn_drops: 0
    rx_decache:    14444
    rx_fifoO:      0
    rx_rdu:        6
    rx_reuse:      3252069
    beacon_ok:     108749418
    beacon_er:     358
    beacon_dma_err:0
    freeskb_err:   0
    dz_queue_len:  0
    check_cnt_tx:  0
    check_cnt_adaptivity:  0
    check_cnt_fw:  0
    check_cnt_rx:  0
    cnt_sta1_only: 0
    cnt_sta2_only: 0
    cnt_sta1_sta2: 0
    cnt_mu_swqoverflow:  137523
    cnt_mu_swqtimeout:  11704
    VO drop: 0
    VI drop: 0
    BE drop: 0
    BK drop: 0
    reused_skb:    0
    skb_free_num:  31
    rx_enqueue_cnt:    0
    rx_rdu_dis_int:    0
    tx_avarage:    0
    rx_avarage:    0
    cur_tx_rate:   1
    swq enable:    1
    swq hw timer:   1
    use hal:    1
    use outsrc:    1
    rf_lock:   
13:50:24.725508 IP 169.254.1.2 > 169.254.1.1: udp
E..mG...@...........    false
    IQK total count: 15
    Check IQK: 0
    check spur: 0
    adaptivity_enable: 0
    amsdu_to_pkt:     0
    amsdu_check_pkt:     0
    swq_enque_pkt:    2732977
    swq_xmit_out_pkt:    2732977
    swq_real_enque_pkt:    1983846
    swq_real_deque_pkt:    1983846
    swq_residual_drop_pkt:    0
    swq_overflow_drop_pkt:    0
...


Concernant les fuites mDNS Synology, elle ne semblent pas liées à un problème K-Box (pas un problème de LAN qui fuie) :
La source des paquets est l'IP publique du client, et avec un portscan, je trouve des ports ouverts, et j'ai pu accéder rapidement à l'interface http (oui, même pas https) d'un routeur Syno nommé L-Routeur tournant sous Synology SRM 1.2 ! 
J'ai essayé admin/admin qui HEUREUSEMENT n'a pas fonctionné, mais les possesseurs de routeurs Synology, merci de vérifier vos configs et vos accès externes !

Incident spam DHCPv6 en cours depuis 1h45 ce matin.
Toujours en cours.

Cela déclenche des fuites APIPA, qui sont intermittentes (probablement mon paquet « stop » qui les arrête, et pour une raison quelconque, le spam DHCPv6 les redémarre, et ainsi de suite…)