quentin/wpj428
2
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Some more tests

Browse source
This commit is contained in:
Quentin 2021-04-18 20:05:38 +02:00
parent db32405d11
commit a0fccea2dd
Signed by: quentin
GPG key ID: A98E9B769E4FF428
1 changed files with 49 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
doc/udp-df.md
View file

@ -50,15 +50,61 @@ Then I try to send a packet through scapy:
# X.. Reserved # X.. Reserved
# .X. Don't fragment # .X. Don't fragment
# ..X More 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",flags=0b010)/UDP(sport=2373,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=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. 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). (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? 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 ## Some possible workarounds