La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: cyayon le 30 juin 2023 à 09:08:22
-
Bonjour à tous,
Je voudrais savoir si vous avez déjà rencontré ce genre de problème.
Ma config : fibre orange 2Gb/s > ONU FS.com > CRS 305 > CCR 2116 > Intel x550 (server Archlinux)
Tout fonctionne parfaitement depuis quelques temps, aussi bien en sortie (server > internet), qu’en entrée (internet > server).
J’héberge qques services sur mon serveur comme des serveurs web (nginx), du WebDAV (rclone), vpn (ovpn et wg), reverse proxy (nginx), domotique (jeedom/ipx800), etc…
Cette je suis parti en vacances qques jours et j’ai remarqué un pb assez curieux,. Mes téléphones (moi, épouse et enfants) sont chez Bouygues Telecom, et lorsque de mon téléphone je voulais joindre l’un de mes services auto-hébergé c’était super lent ou même impossible par moment (14s pour un POST json en HTTPS).
Dans un premier temps, j’ai mis cela sur la mauvaise qualité du réseau 5G / 4G local. Mais même lorsque je captais bien, même problème. Je me suis alors connecté à un wifi, plus de problème tout redevient normal et répond parfaitement. Bien sûr lorsque je suis par chez moi, dans ma région, en 4G ou 5G pas de problème.
Les autres sites web (Google, etc…) fonctionnent parfaitement lorsque je suis en 5G/4G sur mon lieu de vacances. Seuls mes services auto-hébergés ont un problème.
Symptôme révélateur, lorsque je mon monte mon tunnel vpn WireGuard (UDP) hébergé sur Mikrotik CCR2116, plus de problème, tous les services répondent bien. Lorsque je monte mon tunnel WireGuard (UDP aussi) sur mon server (Archlinux), le tunnel monte mais les services fonctionnent très mal ou pas du tout (comme hors tunnel).
J’ai réfléchi un peu (ça m’arrive), et je pense avoir un problème de MTU / MSS.
A partir de mon téléphone (pas facile), j’ai réussi à faire un tcpdump sur le serveur. J’ai pris 2 traces, la premières lorsque mon tel est en wifi (et que tout fonctionne), et une seconde trace lorsque je suis en 5G (fonctionne mal/pas).
J’ai essayé de faire un petit grep de mtu|mss sur les traces (mais sur l’écran de téléphone dans un terminal ssh, pas simple), j’ai vu un mss de 1460 en wifi et 1390 en 5G. Une piste ?
La carte reseau de mon server Archlinux est une Intel x550 en 10Gb sur mon CCR 2116, avec les paramètres MTU par défaut.
Sur CCR 2116 MTU 1500 ; L2 MTU 1584 ; Max L2 MTU 9570
Sur le server : MTU 1500 (ip addr show dev)
Je fais peut être fausse route… Le plus curieux dans tout cela est que lorsque je suis dans ma région en 4G/5G pas de problème. Je ne vois pas pourquoi le même opérateur (Bouygues) aurait des MTU / MSS différents.
Merci pour votre aide…
-
Petit test à partir de mon téléphone (iPhone) pour tenter de déterminer la MTU : Ping -s xxx 1.1.1.1
En 5G, xxxx = 1400 maximum, au dessus ça ne passe pas
En wifi xxxx = 1460 maximum, au dessus ça ne passe pas
Je suis peut à côté de la plaque en focalisant sur la MTU, mais du coup j’ai un gros doute, dois - je modifier la MTU sur l’interface WAN de mon server ou le routeur pour ne pas avoir de problème avec certains clients en mobilité 4G/5G ?
Merci
-
Bonjour
Je ne connais pas bien la mécanique de raoming (si tu es à l'étranger) et donc de la MTU max dont tu disposes.
Tu peux aussi avoir une liaison en PPP et donc perdre une partie de tes 1500 octets.
Préco :
- adresse de service "externe" : réduire la MTU
- adresse de service "interne" rester à 1500
It is generally recommended that the MTU for a WAN interface connected to a PPPoE DSL network be 1492. In fact, with auto MTU discovery, 1492 is discovered to be the maximum allowed MTU. However, having an MTU of 1452 is most optimal.
PS : passer en IPv6 c'est géré par le protocole :)
LeVieux
-
Hello,
Je suis toujours en France, simplement changé de région.
Mon opérateur est Bouygues sur mes mobiles.
Ce qui signifie que je suis en ipv6 natif et il y a un tunnel ipv6 > ipv4 pour atteindre mes services hébergés.
Tout semble bien fonctionner jusqu’au routeur CCR 2116 mais jusqu’au serveur.
-
Hello,
est-ce-que ICMP est filtré sur ton réseau ? C'est nécessaire pour PMTUd, mécanisme je pense important pour les liaisons non standard 1500. Après aucune idée de comment ça se transpose sur un téléphone mobile.
Personnellement sur les liaisons S2S itinérantes que je monte sur des 4G, je dois mettre une MSS calculée à partir de la MTU pour pouvoir faire passer le trafic TCP correctement, en UDP je dois régler la MTU de l'interface physique (avec la technique du ping comme tu expliques)
-
Je vais regarder pour l’icmp.
Ce qui me dérange est que même le tunnel WireGuard en UDP fonctionne mal, enfin ce qui est encapsulé dedans.
Lorsque le tunnel est monté avec le routeur, pas de pb.
Lorsque le tunnel est monté avec le serveur (port forward), les paquets a l’intérieur deconnent aussi.
Comme si le port forward posait pb.
-
Alors, fait très interessant, lorsque je passe par l’ipv6 de mon serveur (enfin l’ipv6 externe que je présente sur mon routeur Mikrotik), tout marche correctement.
Mon téléphone est en 5G chez Bouygues et donc en natif ipv6.
Donc quand je suis en ipv6 de bout en bout pas de problème.
Si c’est le PMTUd, que dois-je ouvrir comme flux (ICMP ?) et surtout jusqu’où ? Routeur ou serveur ?
ÉDIT : J’ai vérifié l’icmpv4 (tous types) est bien ouvert jusqu’au serveur (input et forward), sur le routeur Mikrotik et sur le serveur (nftables). Et bien sûr je n’ai pas de drop dans les logs sur ICMP.
Donc il y a problème lorsque le client (iPhone) a besoin d’encaps ipv4 dans ipv6.
-
Bonjour
Je ne connais pas bien la mécanique de raoming (si tu es à l'étranger) et donc de la MTU max dont tu disposes.
Tu peux aussi avoir une liaison en PPP et donc perdre une partie de tes 1500 octets.
Préco :
- adresse de service "externe" : réduire la MTU
- adresse de service "interne" rester à 1500
It is generally recommended that the MTU for a WAN interface connected to a PPPoE DSL network be 1492. In fact, with auto MTU discovery, 1492 is discovered to be the maximum allowed MTU. However, having an MTU of 1452 is most optimal.
PS : passer en IPv6 c'est géré par le protocole :)
LeVieux
La MTU c’est sûr l’interface et pas l’adresse non ?
-
Donc il y a problème lorsque le client (iPhone) a besoin d’encaps ipv4 dans ipv6.
Sur le mobile, Bouygues fait de l'IPv6-only + NAT64. Le traffic IPv6 est direct, le traffic v4 doit passer par le NAT64.
J'ai déjà constaté des soucis transitoires avec ces NAT64 (sessions qui disparaissent, traceroutes qui ne passent pas, etc.), mais n'ai aucune idée de si cela dépend de la zone géographique ou non. Ce qui est sûr, c'est que Bouygues régionalise son coeur de réseau, donc les équipements et/ou leur configuration n'est pas forcément la même en fonction d'où tu es.
Utiliser IPv6 pour ton tunnel wireguard est clairement la bonne option, peu importe qu'il transporte v6 ou v4 ou les deux.
-
Effectivement, du coup c’est plus clair. J’aurais bien aimé trouver une parade pour le cas où le client fasse de l’encaps.
J’ai lu pas mal de trucs notamment sur le mss clamp, mais je ne sais pas si cela a un rapport direct avec mon pb.
-
Le MSS clamp peut aider si tu le mets en place sur l'interface wireguard : il forcera TCP à utiliser un MSS (et donc un MTU) plus faible peu importe les conditions réseau.
Ceci dit:
- ca n'améliorera pas tes perfs lorsque ton tunnel est monté en v6 (en fait, ca va un peu les diminuer, car tes machines vont utiliser des paquets plus petits que nécessaires)
- on est pas vraiment sûr que le souci de perf constaté provienne d'un mauvais MTU... c'est peut-être le CLAT sur le mobile ou le NAT64 dans le réseau de l'opérateur qui diminue les perfs, ou encore autre chose.
Mon conseil : ne modifier les paquets sur le chemin réseau que lorsque c'est strictement nécessaire.
-
Merci, mais dans le cas présent ça marche presque pas.
Donc on n’est pas dans l’optimisation.
Je pense que le problème vient du NAT64 régional de Bouygues.
D’ailleurs le problème est sur les paquets TCP et UDP, du moins j’en ai l’impression. Et uniquement ceux qui vont jusqu’au server. Ceux qui s’arrêtent au routeur pas de problème.
Ce que je ne comprends pas c’est comment font les sites ipv4 only pour que les clients avec une mauvaise implémentation NAT64 (si je peux dire ainsi), pour que cela fonctionne ?
-
J’ai aussi pensé au NAT64, mais tu indiques des soucis en https sur ton serveur, constates-tu les mêmes soucis sur d’autres services hébergés en IPv4 sur internet ?
Car si c’est que sur ton serveur les dysfonctionnements, par élimination le soucis se trouve plutôt sur ton routeur ou ton serveur ?
edit :
En vrai le NAT64 me pose aussi un soucis chez Orange en 4G : Netflix sur webOS ne charge pas et impossible de rejoindre un "groupe d'ami Xbox" (chat vocal sur Xbox) alors que pourtant l'accès à un VPN IPv4 only (pas de pile IPv6 sur le serveur) se fait sans problème
Pas de soucis Netflix et Xbox avec une SIM Free ou une SIM avec une IP publique IPv4
-
Tous les types de paquets qui sont port-forward vers mon serveurs semblent poser problème.
Les paquets TCP (ssh, https, openvpn, etc…) mais aussi UDP (wireguard et openvpn-udp).
Les paquets qui s’arrêtent au routeur (je n’ai que de l’UDP wireguard sur un autre port), ne posent aucun problème.
Et cela ne concerne que la stack ipv4, les paquets IPv6 passent bien dans tous les cas.
Et cela ne se produit pas lorsque mon téléphone se situe dans la région où j’habite (Haute-Savoie). Cela doit provenir de l’implémentation régionale NAT64 / CLAT de Bouygues de mon lieu de vacances (Avignon).
J’ai remarqué ces params sysctl sur le serveur :
net.ipv4.ip_forward_use_pmtu = 0
net.ipv4.ip_no_pmtu_disc = 1
Je ne sais pas si ça doit être modifié
Très curieux cette histoire…
-
Hello,
Je ne sais pas si tu accèdes à tes services exposés à partir du VPN mas j'ai eu un problème similaire (mais dans l'autre sens : de chez moi vers des sites externes) avec Wireguard. Lorsque j'ouvrais des connexions tcp de mon réseau vers l'extérieur, de nombreuses connexions tombaient en échec.
Sur le Mikrotik j'ai ajouté une règle mangle pour réduire le mss pour toutes les nouvelles connexions sortant vers le VPN :
add action=change-mss chain=forward comment=\
"Change MSS to fix issues with tcp connection timeout through VPN" connection-state=new new-mss=1380 \
out-interface-list=VPN passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1381-65535Peut-être trouveras-tu une piste ...
Bonne journée
-
En fait j’ai des pbs avec les services exposés en direct (port forward) et via le VPN.
Des l’instant où le service termine sur le serveur et non le routeur, il y a problème.
Mais pourquoi faut il modifier le MSS et donc sur TCP alors qu’il y a aussi un pb sur UDP ?
-
Bon, j’ai essayé la regle mangle sur le Mikrotik. Pas mieux.
J’ai pris des traces tcpdump avant hier. Je rentre demain je posterais ici les traces.
-
En fait j’ai des pbs avec les services exposés en direct (port forward) et via le VPN.
Oui j'avais bien compris, j'ai bien précisé que j'avais le problème inverse (LAN vers Internet à travers le VPN WireGuard).
Mais pourquoi faut il modifier le MSS et donc sur TCP alors qu’il y a aussi un pb sur UDP ?
Voici les notes que j'ai gardé. Je ne sais plus d'où elles viennent malheureusement.
It is a known fact that VPN links have a smaller packet size due to encapsulation overhead. A large packet with MSS that exceeds the MSS of the VPN link should be fragmented prior to sending it via that kind of connection. However, if the packet has a Don't Fragment flag set, it cannot be fragmented and should be discarded. On links that have broken path MTU discovery (PMTUD), it may lead to a number of problems, including problems with FTP and HTTP data transfer and e-mail services.
In the case of a link with broken PMTUD, a decrease of the MSS of the packets coming through the VPN link resolves the problem.
Donc a priori le problème provient de l'encapsulation et la fragmentation ce qui ne s'applique pas dans ton cas vu que dans ton sens, on décapsule et le packet est donc plus petit ...
-
Je viens d’essayer avec une VM que j’ai sur le cloud Azure en ipv4 only.
Et bien aucun problème à partir de mon iPhone pour y accéder en SSH, donc en TCP.
Aucun réglage particulier sur cette VM, qui possède en plus uniquement une IP privée. L’IP publique est donc portée par un routeur en amont (géré par Microsoft donc).
Les réglages nécessaires à faire sont donc sur le routeur plutôt que sur le serveur lui-même.
La question est qu’est-ce qu’à bien pu faire Microsoft pour que ça fonctionne ? Qu’ai je raté sur le Mikrotik ?
-
Je viens d’essayer avec une VM que j’ai sur le cloud Azure en ipv4 only.
Et bien aucun problème à partir de mon iPhone pour y accéder en SSH, donc en TCP.
Aucun réglage particulier sur cette VM, qui possède en plus uniquement une IP privée. L’IP publique est donc portée par un routeur en amont (géré par Microsoft donc).
Les réglages nécessaires à faire sont donc sur le routeur plutôt que sur le serveur lui-même.
La question est qu’est-ce qu’à bien pu faire Microsoft pour que ça fonctionne ? Qu’ai je raté sur le Mikrotik ?
Je ne vois qu'une chose à faire : capturer les deux connexions et comparer le fonctionnement ;) ça peut être tellement de chose...
Le fonctionnement des réseaux est tellement complexe qui même si tu fais ça au boulot toute la journée, tu auras besoin d'autres experts pour résoudre le problème...
-
Oui j’ai pris 2 traces avant hier (mais en tcpdump sur le téléphone pas facile). Je les posterais ici demain.
Le problème est que je serais rentré et du coup ça fonctionnera, je ne pourrais plus reproduire le problème :-(
-
Hello,
Voici les 2 traces tcpdump que j'avais prises.
Les 2 traces sont de simple requetes en HTTPS sur le port 444.
La premiere, lte.tcpdump est la trace lorsque j'étais en 5G (en APN full ipv6 only et donc NAT64 DNS64) et que cela ne fonctionnait MAL/PAS. Le fichier contient 2 requêtes qui chacune finit par répondre au bout de 12-13 secondes (chacune). 1ere requete -> 12s -> réponse ; 2eme requete -> 12s réponse.
La seconde, wifi.tcpdump est la trace lorsque j'étais en Wifi (IPv4 only) et que cela ne fonctionnait CORRECTEMENT. Il n'y a qu'une seule requête.
On peut voir que dans le cas lte.tcpdump, le mss est à 1390 et en Wifi mss de 1460.
A part ça, je ne vois pas grand chose.
J'ai pris d'autres traces, notamment des tentatives de montage de tunnel wireguard en UDP. Je posterais ici plus tard si besoin.
Comme prévu, sur le chemin du retour, j'ai pu constater que selon les lieux géographiques, parfois cela fonctionnait bien en 5G/4G. Puis à d'autres endroits, plus du tout. Cela confirme la config très localisée de Bouygues. Dans ma région, que je sois chez moi ou au travail (30km entre les 2), cela fonctionne dans les 2 cas.
-
Ces fichiers sont des captures texte de la sortie de tcpdump. Pourrais-tu refaire tes captures avec l'option -w, pour qu'on ait des dumps expoloitables dans tcpdump ?
J'ai tenté de jeter un oeil rapide, mais les infos que je cherche ne sont pas visibles dans la version texte. Tu peux aussi les envoyer en MP si tu veux.
-
Salut,
Merci bcp pour ta réponse.
Le problème est que je suis incapable de reproduire le problème, car il est très dépendant de la localisation...
Autour de chez moi/travail, je n'ai pas réussi à reproduire le pb. Bouygues semble vraiment avoir des configs différentes selon les endroits.
Si je parviens à reproduire le problème, je referais des captures pcap.
Tu n'aurais pas une piste des fois ?
Merci encore.
-
Difficile à dire sans capture/info lorsque le problème se produit car on ne peut que spéculer :)
Sur mon accès cellulaire bouygues, le MTU semble être de 1450 en IPv6 (à mon domicile). Ca semble pareil si je passe par leur NAT64 pour joindre une destination IPv4... et je n'ai pas de souci particulier de MTU ou de fragmentation de paquets quand je tente de joindre mon infra chez moi, avec un MTU de 1500 bytes.
Le path mtu discovery fonctionne bien en IPv6 et *semble* fonctionner à travers le NAT64, mais je suis comme toi dans le cas non pathologique... Je me souviens par contre d'avoir observé plus d'une fois que le NAT64 de Bouygues posait problème dans certaines zones géographiques (sur la ligne de TGV Paris-Lyon, il me semble).
Je tenterai de faire des captures si ca se reproduit. Mais si tout fonctionne en IPv6, utilise IPv6 et ne creuse pas plus :-)
À mon sens, s'il fallait appliquer du MSS clamping quelque part, ca serait côté accès mobile, pas côté FTTH. Ta connexion FTTH a un MTU de 1500, la baisser artificiellement diminuerait les performances.
-
Merci pour ta réponse.
Ce qui m'interpelle c'est que ma vm de test sur Azure n'est qu'en IPv4 et y accéder ne pose aucun problème (au même endroit).
Comment fait donc microsoft pour contourner le pb ???
En attendant d'y voir plus clair, je suis passé en full ipv6.
Merci en tout cas.
-
Hello :)
Sujet ancien, mais toujours d'actu malheureusement, cette fois sur l'infra mobile d'Orange.
Depuis 2-3 jours (et même peut-être avant, je ne suis pas tout le temps dessus), j'ai remarqué des ratés sur les connexions HTTP avec mon VPN WG sur mon abo sosh. Ça marche 5 minutes puis plus rien, les pages web de mes services internes ne répondent plus avec un délai d'attente dépassé. Le tunnel est en IPv6 avec une MTU classique de 1420.
Une capture montre que les 2 essaient d'échanger, mais seuls les SYN/ACK arrivent à passer, dès que ça veut envoyer les pages, plus rien.
Si je déco/reco ça repart, mais fini par bloquer. Les petits paquets ne sont pas affectés, je peux avoir un flux VoIP à côté et les pages web toujours en échec. Parfois ça se débloque, j'imagine que WG refait une nouvelle connexion, mais c'est au petit bonheur la chance.
Il s'avère que la MTU est comme chez Bouygues, réduite à 1440 v4 / 1460 v6. Pire, elle varie selon la techno, en 2G/3G c'est 1500 v6 / 1440 v4 ! Ça se voit très bien quand on bascule entre les deux : un ping ipv6 coupe en 4G et repart en 3G avec une taille de 1452.
Mais bizarrement seul l'IPv6 semble déconner. J'ai switché il a quelques semaines et finalement laissé en place (pensant que ça marcherait mieux à éviter le NAT64 & cie). Je suis repassé en IPv4 à tout hasard : tout fonctionne nickel même 1h après la connexion du tunnel... voilà pourquoi je n'avais rien remarqué pendant longtemps.
J'ai refait diverses captures pour savoir d'où ça pouvait bien venir, comme si au milieu un équipement jetait l'éponge mais juste sur la partie gros paquets UDP, car vu la MTU, il y a forcément de la fragmentation quelque part.
Et c'est là que j'ai découvert la cause : Le serveur WG ! (et un peu Orange aussi qui n'est pas foutu d'avoir un réseau à 1500 partout...) C'est bien lui qui fait de la fragmentation, suite à la réception d'un packet too big de la part du réseau mobile (je pensais au départ qu'il y avait une magouille dans le cœur de réseau d'orange). SAUF QUE, en quelques minutes, il oublie la consigne et se met à envoyer des paquets de 1452 octets, qui évidemment n'arrivent jamais à destination (vérifié côté smartphone). Mais Orange de son côté, ne renvoie pas non plus de packet too big et la situation se bloque... jusqu'à ce que le tunnel soit déco/reco.
En IPv4, il y a aussi de la fragmentation mais on dirait que la consigne est retenue pendant un très long moment, car il faut que je change volontairement d'IP côté smartphone pour que ça renvoie un ICMP fragmentation needed. Sur une simple déco/reco, les paquets continuent d'êtres fragmentés.
Après avoir fouillé les paramètres de sysctl, j'ai trouvé ceux qui correspondent à la fragmentation, mais c'est presque mêmes valeurs, donc je ne comprends pas cette différence de comportement (et en v6 les valeurs sont plus élevées). D'après ce que j'ai compris ça serait secret_interval qui est important, mais il est à 0 dans les 2 cas.
Si quelqu'un veut bien m'expliquer...
net.ipv4.ipfrag_high_thresh = 4194304
net.ipv4.ipfrag_low_thresh = 3145728
net.ipv4.ipfrag_max_dist = 64
net.ipv4.ipfrag_secret_interval = 0
net.ipv4.ipfrag_time = 30
net.ipv6.ip6frag_high_thresh = 4194304
net.ipv6.ip6frag_low_thresh = 3145728
net.ipv6.ip6frag_secret_interval = 0
net.ipv6.ip6frag_time = 60
Pour le moment, la seule parade efficace que j'ai trouvé consiste à créer une autre instance de WG avec une MTU de 1360 dédiée aux mobiles, ce qui permet de laisser mes autres tunnels à 1420. Et ça fonctionne pas trop mal. Mais j'aimerais bien pouvoir régler ce soucis et n'exploiter qu'un seul tunnel...
Merci
-
Si vous avez un LAN en jumbo virer moi cette merde qui sert à rien :)
Si c'est le cas vos problèmes viennent de là.
-
Pas de jumbo, je l'aurais précisé sinon...
-
J'ai à priori trouvé un truc avec la commande :
# ip route get 2a01:cb1e:31:1a0e:6030:6fff:fefe:d6f8
2a01:cb1e:31:1a0e:6030:6fff:fefe:d6f8 from :: via fe80::d284:b0ff:xxxx:xxxx dev ens18 src 2a01:cb1x:xxx:xxx:407:9264:1a4f:51ad metric 1024 expires 1180sec mtu 1460 hoplimit 64 pref medium
Je vois bien la MTU de 1460 et un compteur de 1800s, sauf que ça à l'air de couper bien avant. Et l'adresse source est la temporaire du système alors que j'utilise une IP définie manuellement pour atteindre le serveur, mais ça n'a peut-être pas d'importance dans ce cas ?
Y'a moyen d'augmenter le compteur pour voir ? Mais je ne sais pas comment... J'ai trouvé le paramètre net.ipv6.route.mtu_expires, que j'ai défini à 3600, mais ça ne change rien.
EDIT : Nouvelle découverte WTF.
La commande ip get montre également la MTU de 1440 en IPv4 avec un compteur de 600s soit en gros le délai bloquant que j'avais remarqué en IPv6.
# ip route get 92.184.112.82
92.184.112.82 via 192.168.2.1 dev ens18 src 192.168.2.45 uid 0
cache expires 585sec mtu 1440
Mais, si sur la première connexion IPv4, le réseau envoie bien un ICMP pour fragmenter, à l'expiration du cache, le serveur se remet à envoyer à 1452, sauf que là stupeur : ils passent sans problème ! Voilà pourquoi ça fonctionne en toutes circonstances.
Est-ce que le PGW d'orange se mettrait à fragmenter à la place du serveur ? Mais alors à quoi ça sert d'envoyer un ICMP frag needed si c'est pour le faire par la suite ? Bizarre leur configuration ???
Serveur :
# tcpdump -i ens18 host 92.184.112.82 or icmp | grep 1452
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens18, link-type EN10MB (Ethernet), capture size 262144 bytes
20:43:49.936537 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:49.936544 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.535838 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.535847 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.535848 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.535849 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.535851 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.719366 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.719374 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.719376 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:51.719377 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:52.110937 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:52.110946 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
20:43:52.302530 IP 192.168.2.45.51820 > 92-184-112-82.mobile.fr.orangecustomers.net.48807: UDP, length 1452
Smartphone :
bangkk:/data/local # tcpdump -i rmnet_data2 udp port 51820 | grep 1452
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on rmnet_data2, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
20:43:51.045121 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:51.055893 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.643632 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.655623 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.668592 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.681658 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.695711 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.832648 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.838669 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.859955 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452
20:43:52.870289 IP ip-publique.abo.wanadoo.fr.51820 > 192.0.0.2.48807: UDP, length 1452