Hey Philip,
I'm trying to do an exercise that will help me determine the MTU of a remote server ,as well as the HOPS, if this is even possible.
I use a lot of VPN and there are some servers dropping the packets or the HOP does. Can't determine if it is part of QOS or mismatched MTU.
Is there a utility that would do that or basic ping is suffient? If so, what would be the correct syntax? I'm using Windows 11 Pro 22H2
As always, thank you
Remote Hosts MTU
To get the number of "hops" you can use a: tracert [host]
To get the largest non-fragmented MTU(packet size), you can use: ping -f -l [packetsize] [host] (where -L is the MTU -28).
For example: ping -f -l 1472 speedguide.net
This means that 1472 bytes packet can travel to that host. You have to add 28 to get the MTU size (20-byte IP and 8-byte ICMP headers), so 1472+28 means 1500 MTU can travel to that host.
To get the largest non-fragmented MTU(packet size), you can use: ping -f -l [packetsize] [host] (where -L is the MTU -28).
For example: ping -f -l 1472 speedguide.net
This means that 1472 bytes packet can travel to that host. You have to add 28 to get the MTU size (20-byte IP and 8-byte ICMP headers), so 1472+28 means 1500 MTU can travel to that host.
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
You don't have to change anything, just see what gets through unfragmented. I imagine it would be 1420 - 28 bytes for headers.
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Same difference, 1420-28=1392+28 
For the OS MTU, it is up to you. If you regularly use VPN, or some other tunnel that lowers it, you may also want to lower it to 1420 in the OS.
For the OS MTU, it is up to you. If you regularly use VPN, or some other tunnel that lowers it, you may also want to lower it to 1420 in the OS.
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
What r ur thoughts on this:
When I'm connected to a VPN with a static IP multi threaded downloading works up to my subscribed speed.
However, if I use dynamic IP, multi threaded downloading is stucked a 10Mbps or 100Mbps.
My line is 500/500
Is it ISP misconfiguration? or Maybe there's something I could do on my end?
When I'm connected to a VPN with a static IP multi threaded downloading works up to my subscribed speed.
However, if I use dynamic IP, multi threaded downloading is stucked a 10Mbps or 100Mbps.
My line is 500/500
Is it ISP misconfiguration? or Maybe there's something I could do on my end?
It shouldn't be related to "static" vs "dynamic" IP, rather different routing if you're connected to a VPN or not.
I've seen this before, where ISPs don't provide enough bandwidth to certain remote locations, and VPN fixes it. When you connect to a VPN you change the route, your ISP is responsible only for the part between you and the VPN server, which is usually in major hubs, with plenty of bandwidth available.
I've seen this before, where ISPs don't provide enough bandwidth to certain remote locations, and VPN fixes it. When you connect to a VPN you change the route, your ISP is responsible only for the part between you and the VPN server, which is usually in major hubs, with plenty of bandwidth available.
It shouldn't be related to "static" vs "dynamic" IP, rather different routing if you're connected to a VPN or not.
I've seen this before, where ISPs don't provide enough bandwidth to certain remote locations, and VPN "fixes" it. When you connect to a VPN you change the route, your ISP is responsible only for the part between you and the VPN server, which is usually in major hubs, with plenty of bandwidth available. The rest of the way is up to the VPN provider.
I've seen this before, where ISPs don't provide enough bandwidth to certain remote locations, and VPN "fixes" it. When you connect to a VPN you change the route, your ISP is responsible only for the part between you and the VPN server, which is usually in major hubs, with plenty of bandwidth available. The rest of the way is up to the VPN provider.
Not much you can do on the client side to change the line your ISP provides, if you're hitting some bandwidth limit it's likely their backbones/interconnects with other networks.
Linux is user friendly, it's just picky about its friends...
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits). I also eat whatever crayons are put in front of me.
๑۩۞۩๑
Philip
I'm doing some experiment right now. So far, every time I execute winsock and Ip reset I get back my bursting speed in VPN after it get stucked in lower speed. What does this tell us? Possibly routing issues that needed to be reset after possible changes in the Networking enviroment of my ISP? Usually this happens after turning off my ONU overnight and turning back on in the morning.
I also would like to try to flush Windows 11 routes and set it back to defualt. Do you happen to know the syntax? Tried "route /f" that really disable my entire network. How ca I do this safely?
I'm doing some experiment right now. So far, every time I execute winsock and Ip reset I get back my bursting speed in VPN after it get stucked in lower speed. What does this tell us? Possibly routing issues that needed to be reset after possible changes in the Networking enviroment of my ISP? Usually this happens after turning off my ONU overnight and turning back on in the morning.
I also would like to try to flush Windows 11 routes and set it back to defualt. Do you happen to know the syntax? Tried "route /f" that really disable my entire network. How ca I do this safely?