51–60 of 86 posts
I remember postponing my payments to the ISP, which hadn't blocked ICMP for anybody, by using ptunnel: http://www.cs.uit.no/~daniels/PingTunnel/ It was pretty much usable circa 2008... btw, in debian (and probably, derivatives), it is just apt-get away from being installed.
Can someone explain to a non-network person the significance of being able to tunnel IP traffic over ICMP?
Not the first of its kind, just look-up in Wikipedia: https://en.wikipedia.org/wiki/ICMP_tunnel Any captive portal these days block also ICMP. Most firewalls block ICMP these days, because the days of blacklisting are over and ICMP is not the one who is getting white listed. Why? The only way these days is to misuse DNS. But even that works less and less reliable.
I agree that some captive portals/firewalls do block ICMP but still I've seen many in my country which don't.
Earlier quoted context omitted.
1500 is the MTU of Ethernet, it's often not sustainable on end to end connection (especially when you add frame overheads) if you are using that high of a payload size you'll get considerably worse performance than say limiting it to around 500 bytes, you are welcomed to try it. Also with how global traffic is managed smaller packets tend to get priority since they can be qued quicker backbone connectivity uses much…
What do you mean by "it's often not sustainable"? Throughput on a server is higher at higher packet size, so if you're doing a download I'd expect the server to send 1500 byte packets. It's pretty easy to saturate a link with 1500 byte packets, and it's much harder to do so at lower packet sizes (from the server's perspective) since the per-packet processing costs start to dominate over the per-byte costs. Admittedly…
Earlier quoted context omitted.
After reading the product page, this product seems too good to be true (OSS, supports every OS and every type of VPN). Is there some kind of catch? How come I've never heard of it until now?
I know among the pfsense group originally there was skepticism that it wasn't back doored by a government agency (not because there was proof), because of the fact it had such a great feature set while being so new a project. Now that it's open sourced, I'm interested to see if people pick it up. It definitely looks legit.
A few years back, I was assigned to work at a BigCorp's premises. They had really tight network security: all outward connections were blocked except through a dedicated HTTP proxy. This was bad news, since stuff like SSH are absolutely essential in my job. After few days of mobile tethering, I realized I could ask their HTTP proxy to open an HTTPS connection to a server outside the network, but instead of sending HT…
Maybe this is why Microsoft Azure never allowed ICMP travseral through their outer firewall despite frequent request from users....
Not the first of its kind, just look-up in Wikipedia: https://en.wikipedia.org/wiki/ICMP_tunnel Any captive portal these days block also ICMP. Most firewalls block ICMP these days, because the days of blacklisting are over and ICMP is not the one who is getting white listed. Why? The only way these days is to misuse DNS. But even that works less and less reliable.
Earlier quoted context omitted.
What do you mean by "it's often not sustainable"? Throughput on a server is higher at higher packet size, so if you're doing a download I'd expect the server to send 1500 byte packets. It's pretty easy to saturate a link with 1500 byte packets, and it's much harder to do so at lower packet sizes (from the server's perspective) since the per-packet processing costs start to dominate over the per-byte costs. Admittedly…
I don't know about cable, but DSL usually uses PPPoE. It has on overhead of 8 bytes, lowering the MTU of those connections to 1492 bytes.
Also from a more high level point of view if you think about it the small packets are the most critical ones and they are at least as far as responsiveness goes DNS is limited to 512bytes over UDP, TCP 3-way handshake packets are tiny and those are the packets that need to get to and back from their destination as fast as possible, delays in data transfers means slower speeds, delays of handshakes mean that your application can fail or hang. Other important traffic such as VOIP[0] also uses very small packet sizes for this same reason most critical services need to transfer very little data (per given unit of time) but need to update data as frequently as possible to provide the illusion of real time and to mask the latency, same goes for other things like online/multi-player gaming and so on and on and on. Pretty much if you want your service to be as responsive as possible limit your packet size to the smallest size possible and increase your PPS this will ensure that your packets get quicker to their destination. [0]VOIP Packet Sizes http://www.cisco.com/c/en/us/support/docs/voice/voice-qualit...
The only time you would want to use large packets is pretty much when you can have a buffer, this means that you need to handle less packets per second which lowers CPU consumption (across the entire path) so video streaming and such can use pretty much as large of an MTU as they want unless they start getting fragments.
Earlier quoted context omitted.
Normally, an ethernet or wifi restricts an MTU of 1500. I use ping packets accordingly
1500 is the MTU of Ethernet, it's often not sustainable on end to end connection (especially when you add frame overheads) if you are using that high of a payload size you'll get considerably worse performance than say limiting it to around 500 bytes, you are welcomed to try it. Also with how global traffic is managed smaller packets tend to get priority since they can be qued quicker backbone connectivity uses much…
It's the de-facto MTU of much of The Internet. Baby Jumbo (MTU >1500 but Edit:
> Also with how global traffic is managed smaller packets tend to get priority...
Do you have a reliable citation for this? I would expect that core and near-core devices would handle so much traffic, that they all would be using MTUs far higher than 1500 bytes per frame.
Earlier quoted context omitted.
I don't know about cable, but DSL usually uses PPPoE. It has on overhead of 8 bytes, lowering the MTU of those connections to 1492 bytes.
It doesn't matter the MTU setting on your end for WAN and ISP / interlink grade networks is meaningless they don't use Ethernet, FDDI frame size is 4500 (ATM is about double that) bytes (minus what ever overhead, but usually 4200 and change) ISP/WAN routers don't care about how many mbit/s they transfer but how many packets they route at per given unit of time, as packets get packed into a single frame the smaller th…
It absolutely does matter and is quite meaningful. :)
If you set your edge router's Internet-facing MTU to 9k, and the upstream equipment's MTU is smaller than that, then either your packets will be dropped, or PTMU Discovery will try to figure out the MTU of the path. (Better hope everyone along the path is correctly handling ICMP! :) )
> The only time you would want to use large packets is pretty much when you can have a buffer...
Or if you have high-volumes of data to move and want to dramatically increase the data:Ethernet_frame_boilerplate ratio. :)
> Also ... if you think about it the small packets are the most critical ones... [because they need to be dispatched as quickly as possible.]
Yes, but a larger MTU shouldn't affect this. Set whatever socket options are required to get those packets on their way as soon as they're created, and your system shouldn't wait to fill an Ethernet frame before sending that packet.