diff --git a/doc/udp-df.md b/doc/udp-df.md
index 56c6360..4b8a0c9 100644
--- a/doc/udp-df.md
+++ b/doc/udp-df.md
@@ -50,15 +50,61 @@ Then I try to send a packet through scapy:
 # X.. Reserved
 # .X. Don't fragment
 # ..X More fragment
-send(IP(dst="212.47.253.12/30",flags=0b010)/UDP(dport=2372)/Raw(load='does ... work\n'))
-send(IP(dst="212.47.253.12/30",flags=0b000)/UDP(dport=2372)/Raw(load='does not work\n'))
+send(IP(dst="212.47.253.12",flags=0b010)/UDP(sport=2373,dport=2372)/Raw(load='does ... work\n'))
+send(IP(dst="212.47.253.12",flags=0b000)/UDP(sport=2373,dport=2372)/Raw(load='does not work\n'))
 ```
 
 I did not observed this bug when I was using a TP-Link+Huawei e3372h, so it probably does not come from my ISP.
 (But it *still* could come from it as we activated IPv6 + 5G).
 
 Still, for now a question is not yet answered: do the bit must be set in both direction or only one?
-Additional tests are thus required
+Additional tests are thus required.
+
+## Additional tests
+
+On the server, we run a small UDP echo server with scapy:
+
+```python
+sniff(
+  filter="udp and port 2732", 
+  count=1, 
+  prn=lambda p: send(
+    IP(src=p[IP].dst, dst=p[IP].src, flags=0b000)/
+    UDP(sport=p[UDP].dport, dport=p[UDP].sport)/
+    Raw(load='answer\n')))
+```
+
+And on the other side, we simply use netcat:
+
+```
+nc -u rayonx.machine.deuxfleurs.fr 2732
+```
+
+On the server, we observe:
+
+```
+# sudo tcpdump -i ens2 -vv udp and port 2732
+tcpdump: listening on ens2, link-type EN10MB (Ethernet), capture size 262144 bytes
+20:03:08.137728 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 33)
+    37-169-5-150.coucou-networks.fr.26054 > rayon-x.2732: [udp sum ok] UDP, length 5
+20:03:08.207393 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 35)
+    rayon-x.2732 > 37-169-5-150.coucou-networks.fr.26054: [udp sum ok] UDP, length 7
+```
+
+On the local machine, we observe:
+
+```
+$ sudo tcpdump -vv udp and port 2732
+tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
+20:03:08.125724 IP (tos 0x0, ttl 64, id 38908, offset 0, flags [DF], proto UDP (17), length 33)
+    lheureduthe.lan.46395 > 12-253-47-212.instances.scw.cloud.g5m: [udp sum ok] UDP, length 5
+20:03:08.246560 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 35)
+    12-253-47-212.instances.scw.cloud.g5m > lheureduthe.lan.46395: [udp sum ok] UDP, length 7
+```
+
+We see that our response UDP packet:
+  - has been received despite the fact it has no flag
+  - has been rewritten with the DF flag
 
 ## Some possible workarounds