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 !