correct , ICMP is not UDP and not TCP, but still it is CONNECTION LESS !!! which is a connection less. the order of the packet is not important !!!
It ainât UDP either, it is the network control messages. But that was not the point. The point is that data on the internet doesnât travel in shortest path. It travels the path that happens to be around. So variables between 10-200ms from test to test and different time of day and server work loads is expected as normal.
of course not. the data in the internet travel based on your location.
anyway , we determined what is the feature that need to develop in OpenWRT.
Spoofing ECHO REPLY. this is the feature.
I think we can sum this up as a 'not great idea'. But hey, if you want to take a shot at knocking something up then it's open source software. You're free to give it a go and contribute to the OpenWRT project.
what a great feeling it make to you personally to come with a statement "THIS is NOT great IDEA"
despite your statement. INDEED it is great IDEA.
no one has developed something like that. it is UNIQ thinking ! IT IS GREAT IDEA !!!
Maybe there's a reason for that... But like I said, if you think it's such a great idea then feel free to develop and contribute it. It's open source software so knock yourself out.
1 Like
I will take it as a personal project. I am student in BSc computer science. I will take it as final project for the degree. not something that I will do right now. but I will work on that as final project for the BSc degree in computer science
I have seen many poor internet connections that use DOCSIS, for example, and depending on the time of day, had very high latencies (well over >100ms).
The APP of the stream provider has no knowledge about the quality of the internet connection and is supposed to block you just because you have a bad internet connection? I somehow doubt that
1 Like
they need to move to Fiber connection. Cables are HISTORY.
Fiber is the future !!!
Lawyers do, and media companies, and so should their customers, however as I said let's leave that aside.
I beg to differ, let's not assume, but actually research whether that idea holds water at all, because my hunch is that your approach will not fool hulu and co. and so any speculation about making this an official feature in OpenWrt is likely moot.
That is the kind of discussion we should start after confirming that the idea works, please.
Unlikely, there are multiple ways of checking RTT including via the TCP or UDP connections our hypothetical remote worker needs ot use to actually work remotely. That said with a single delay measurement you will not be able to pinpoint a location anyway, for triangulation you need to have at least N independent measurements to/from N different locations to get N dimensions correct (and you need more measurements to assess confidence/estimation error). But that assumes precise distance measurements in the first place, which RTT measurements decidedly are not... I am sure with enough known remote endpoints you can pin down the likely area a node is located in, but I am not sure any streaming software goes that extra mile...
I certainly see, that you consider this a great idea, I am not convinced yet.
2 Likes
Indeed UDP does not care about re-ordering, however most applications still do...
1 Like
Well then your hypothesis doesnât even work in Sweden and we have fibers from top to bottom and from left to right and spinning all around us.
I can connect to my homerouter through vpn âand fiberâ and stream movies from home where ever I am in the world and this ping thing never is a problem as far as the streaming service providers are concerned.
Streaming per region non allowed media is only a problem when using the same commercial vpn servers as all other customers.
Please do. I am sure all the posters here will be more than happy to retract their opinions and to laud you on your final degree based on this concept and that it has passed a consensus POC and been merged into OpenWrt as a universal solution for the world to embrace.
2 Likes
So the core of the idea is conceptually not terribly complicated to implement:
- 'catch' select ICMP echo requests (based on source and destination IP addresses)
- create a fake echo response packet
- hold the response for a configurable time and send it back
- the client's ICMP receiver will calculate the RTT not to the intended endpoint, but to the router + the artificial delay
The problem is, that this will only 'fool' applications using ICMP echo requests to asses RTT, but my gut feeling is, this is going to be a small set of applications (one being the 'ping' binary) and is IMHO unlikely to contain the described streaming applications. But that is just why I personally do not think this to be a great idea or something I will spend any more time on.
4 Likes
Yes, thanks for the tip.
Just trench the road for 10km and pull fiber optic cables nothing easier than that.
How stupid the millions of users are who rely on DSL, DOCSIS, LTE and 5G.
Simply switch to fiber optics - nothing easier than that.
Fiber optics is the future!
They already installed fiber optic cables here 30 years ago - it's called OPAL
Couldn't be used for internet for almost 30 years and lay there unused - your future. lol
2 Likes
Look into tc qdisc replace wan root netem help probably you can add noise to your home net to make it so bad it is indistinguishable from VPN. Next - TCP measures rtt all the time.
With some Port Forwarding and NAT Rules you can achive low latency. But for it to work good, it is important to know destination address, or your client should have static IP.
ilija@HP850:~$ ping amazone.com -c 1
PING amazone.com (75.2.51.62) 56(84) bytes of data.
64 bytes from ab38615dc944e506b.awsglobalaccelerator.com (75.2.51.62): icmp_seq=1 ttl=63 time=2.53 ms
--- amazone.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.528/2.528/2.528/0.000 ms
ilija@HP850:~$ ping google.com -c 1
PING google.com (142.250.186.46) 56(84) bytes of data.
64 bytes from fra24s04-in-f14.1e100.net (142.250.186.46): icmp_seq=1 ttl=63 time=2.57 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.565/2.565/2.565/0.000 ms
ilija@HP850:~$ ping facebook.com -c 1
PING facebook.com (157.240.252.35) 56(84) bytes of data.
64 bytes from edge-star-mini-shv-01-fra3.facebook.com (157.240.252.35): icmp_seq=1 ttl=63 time=2.30 ms
--- facebook.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.304/2.304/2.304/0.000 ms
Have a nice day!
You don't read !!!
you have replied without even reading the content of the thread.
WOW , doing a static configuration when you know the destination !
this is not the IDEA at all !!!
why ? because you reroute all the traffic and not for specific PROTOCOL and this is not my IDEA at all. this is known and this is something very easy to do if you know the destination. you modify the /etc/hosts file and fake the destination IP address for the specific FQDN.
and this is not what I meant at ALL , START READING !!! because you were not READING at all.
my IDEA is to reroute a specific SOURCE !!! to any destination for SPECIFIC PROTOCOL only !!!!
OR another way to rephrase IT. without rerouting the traffic at all , catch the packets of specific PROTOCOL from SPECIFIC source and filter those packets , and SPOOF the reply
This is a pretty massive manipulation, have you bothered yet to test whether this actually helps with your proposed use-case? Like checking whether tyical streaming apps actually emit ICMP echo requests at all?
1 Like
Hi. Thank you for your reply. I did indeed read your thread. My idea was to catch ICMP packets (specific protocol) from some specific source going to some specific IP, route them to some known IP, let thet IP answer it, rewrite source MAC and there you have it. It has nothing to do with /etc/hosts.
For example i forwarded all my ICMPs (Ping) to my own server and my server answerd with those times. Then my router rewrites MAC and it seems that original server answerd PING request. But my method means that all ICMP messages to or from specific IP are forwarded. This is then of course very massive manipulation, like moeller0 said.
Have a nice day!
1 Like