If a ping to a specific IP times out, I wouldn't say the IP is blocked. It could be that ICMP specifically is blocked, following some network rules on the firewall. This is pretty common in entreprise networks to not allow endpoint discovery. I could be missing something and happy to be corrected here, but I was surprised to read that.
I find it's important to remember, too, that a failed PING tells you nothing other than your echo request did not receive a response. If the remote host received your request, and if it responded, are both things a failed PING can't tell you, because both of those things could be true but you still end up with a failed PING.
I've seen technicians get tripped up in troubleshooting thinking that a failed PING tells them more than it does. When the possibility of asymmetric return paths is involved it's always important to remember how little a failed PING actually tells you.
And that can be a lot more subtle than you might think. I've had a persistent very hard to debug false alarm triggered on pings sometimes not making it and most of the time they did. But very rarely that would happen three times in a row and that was the threshold for raising an alarm. We spent days on this. Finally, the root cause was tracked down to a BNC 'T' connector at the back of a media adapter that filtered out the header of some percentage of ICMP packets. It is one of the weirdest IT problems I've ever encountered and it makes me wonder how much of what we rely on is actually marginal.
I've always assumed that in situations like this, a traceroute is better. You can get more information simply by reaching the next stage in the trace, even if you're given zero information beyond "I'm now at the next server".
I had an experience recently setting up a third-party VPN where the echo responses were being delivered to the correct (host,interface) but with the wrong destination address (not the same as made the request)
I’ve had to explain this over and over throughout my career. The only way to know if something is accessible is to try the exact endpoint and protocol. Even application-aware firewalls will mess with things at times.
Yes, you need to test the exact protocol you want to use. This means tcping/curl, TLS with proper certificates and SNI domains, etc.
However, just as you make sure that the power supply actually supplies power before dismantling something that refuses to work down to the last washer, repairing network problems should start with the basics. Simple test that does not work, or shows something nonsensical, is a great hint that you forgot something, or should start digging elsewhere.
Every time I've had to fight with path MTU discovery not working I've cursed the people who block all ICMP, though. If ICMP echo / echo-reply is the problem just block that. At the very least, allow destination unreachable / fragmentation needed thru (type 3, code 4).
I've worked in gigs that wanted that. They were all about segmentation, but wanted ICMP echo / response available throughout.
Edit: I wonder if any "enterprise" firewalls do ICMP echo proxying. Having the firewall replace the payload would remove some of the tunneling capability (thought I assume you could still finagle a side channel by just timing the packets) but would also eliminate some of the utility (since being able to craft the payload provides a way to test for specific bit patterns in packets causing problems).
> We affirm our strict adherence to all relevant regulations and service terms throughout this project.
Except if you bypassed payment and used the service in a manner that was not intended, most likely you were by definition not undertaking "strict adherance" to service terms ?
Yeah I am a bit confused about posts like this. It’s bragging about breaking the law. There was a particularly bad one a few months ago where a kid had hacked Monster’s employee training site, and was sharing all this internal media in the post. I don’t understand how they don’t end up getting in some seriously annoying trouble with law enforcement.
Well I looked it up just now and the post was deleted, I guess maybe he did get in trouble. https://news.ycombinator.com/item?id=44997145
I wouldn't go as far as 'breaking the law', and I agree with the author that the contractual terms ($31 for wifi) are a shitty offer to a captive audience. But I'm also tired of pseudolegalism being employed as figleaf for bragging about the ability to bypass access controls and presumably making everything run a bit slower for all the other passengers (the author mentions that they gave up using it after a while because the bandwidth was so limited).
Yes, long flights are miserable and air travel is a bit of a ripoff. I choose to cope by treating it as an internet break and enjoying a dense book.
IMO a certain amount of youthful indiscretion that takes the form of challenging systems and structures feels like it's both tolerable and important. Agitation prevents calcification.
Could also just be lack of knowledge. Weren't we all a bit more risky and playful with other people's websites when we were kids and the internet was still accessed via modems? Remember talking about that with both other kids and adults without getting in trouble, but it was also decades ago. Once I saw others getting in real big trouble (like prison), then I kind of tried to find more beneficial ways of learning programming and computers.
Say you're on a plane from Canada to Hong Kong (random example), which country's laws would be applicable here? The country where the airplane is registered?
> which country's laws would be applicable here? The country where the airplane is registered?
For all intents and purposes it is the country of registration of the aircraft.
There are one or two exceptions to the rule, but they would not be applicable in this scenario. Mostly stuff relating to air safety. For example, if the aircraft did something against the aviaition laws of the country being overflown. Or hijackings etc.
It depends on which jurisdiction region wants to enforce the law. If someone wants to enforce a law, and it succeed, then the law of that jurisdiction region applies.
> The only downside was that although we broke through the network restrictions and could access any website, the plane’s bandwidth was extremely limited, making web browsing quite painful.
Unfortunately this is also the downside of paying. Many times I have paid for internet, only to find it unusably bad. To be fair, I just flew a transcontinental flight on Air Canada the other day and the wifi was fine.
This is likely another layer of security that they didn't break through:
To prevent chat apps from consuming lots of bandwidth typically your connection is severely bandwidth restricted until you pay. If they didn't then someone could simply stream movies from their chat apps.
I don't think so, compared to transcontinental, which lately (before Starlink) has been using the cell towers on the ground + satellite backhaul -- even paying would probably still result in a garbage experience.
I’ve been the unfortunate one who paid and endured the slow-barely-usable/mostly unusable speeds. However, that was before the Starlink era. So if you’re gonna pay for WiFi, it’s worth checking if the flight is equipped with Starlink.
Yeah, I just flew WestJet from Canada to Honolulu and was amazed; full 1080p YouTube with no hiccups and I was able to play some (non-latency sensitive) online games, all over the Pacific. This was fully intentional; there wasn't any back-of-the-seat iPad for watching movies or anything, they straight up tell you to use your own device and watch Netflix. I did some research after and found a lot of airlines in NA are going to be rolling out satellite internet in the next year or two.
For some reason, being fully connected at 50mbps+ on a plane seems more futuristic sci-fi to me than everything AI.
Dan Kaminski popularized this in 2007-8 or so. Not that it didn't exist here and there, but he made the perhaps first public version of a dns tunnel (ozyman). he inspired iodine and others and was a fairly well known guy.
Dan passed away in 2021, rip.
if you search for it its hard to find. his blog is down (hea dead...), and many companies and people talked about it on his behalf to drive traffic (hi duo sec..), so you can see the internet forget, rediscover, and rewrite some history even in a few years.
I haven't used iodine, but this seems simpler. Iodine wraps requests with actual DNS requests. In this case that wasn't needed, because port 53 wasn't filtered at all. So all they needed was a simple proxy on port 53.
iodine automatically checks several modes a "simple" proxy on port 53 being one of them. If you're trying to sneak traffic through this kind of block, it is really the first tool to try.
> Since acwifi.com is accessible but github.com is not, is it possible that the network has imposed restrictions on the DNS server, only resolving domain names within a whitelist (such as instant messaging domains)?
> If this is the case, can I modify /etc/hosts to disguise my server as acwifi.com, so that all request traffic passes through my server before reaching the target website (github.com)?
But by putting the host in /etc/hosts, you're skipping asking the planes DNS server, so how are you "disguising" an external server? And why go through the effort of proxying through acwifi.com instead of going straight to the example of github.com
It could be that they allow any HTTP/HTTPS request that has
Host: acwifi.com
regardless of whether the IP address destination of the request is valid for acwifi.com.
You see these sorts of shenanigans being used to get around country-wide firewalls. Plenty of deep packet inspection is unable to handle edge cases like the "Host:" header being misleading, having it fragmented into two TCP packets, etc. See "domain fronting".
it's extremely unlikely that the plane wifi would be configured that way. trying to use a host file to make github.com respond on acwifi.com was definitely a red herring. It led to figuring out 53 was open, but was definitely not how the filtering was working
I refuse to believe that anything important for flying the plane is actually hooked up to the system providing Netflix to passengers.
People do get nervous, and in theory you could probably break some kind of informational system utility if you kernel panic the box that booms up to the satellite receiver, but unless you're trying to get root on the plane's routers I don't believe there's a need to feel brave.
The braver part is publishing the results of this stuff online under your own name.
yeah, you're not interfering with anything flying the plane through the IFE system, and it won't be the same bandwidth they use for comms either (there might be some semi-sensitive passenger information stored on the in-flight server, but entirely different techniques would be needed to bypass whatever security that's wrapped in).
But "hacking" on an aircraft isn't going to be looked on particularly sympathetically by courts
I wouldn’t expect that either given the little that I know about the rigorous software requirements for aviation.
But I assume that neither of us has anywhere near enough expertise to “refuse” to believe that any computer/software system could be used in dangerously absurd ways even accidentally.
If you move to an empty seat to prevent WiFi signal strength triangulation, and assuming the cabin has no cameras, you didn't auth to the network with identifiable information, actually encrypt your Xray proxy connection (which OP didn't), and you have MAC randomization on, there's next to no way the airliner would be able (or even care) to identify that you did what was described in the article. Sure, they could use DPI and behavioral analysis to detect you were misusing the network, but if they're doing that, they would just block this sort of "backdoor" from the get-go.
I'll echo the article's disclaimer:
This reply is intended solely for educational and research purposes. I affirm the strict adherence to all relevant regulations and service terms.
I highly doubt any airline staff are on your flight (or even remotely) counter-hacking one in a billion passengers messing around with the in-flight WiFi. That $30.75 they're not getting doesn't justify anyone looking into it.
I once merely mentioned the words “Heart Attack” on a plane and was kicked off by the flight attendants. No context, they just heard the words and forced me off.
There are things that trigger them because of laws and regulations like mentioning “bomb” (even if you’re describing something fantastic).
So messing with the gogo flight entertainment is up there with flirting with terrorism charges.
I'm pretty "curious" when it comes to public networks. I'll scan coffee shops, stadiums, hotels, bus hotspots, anything I can connect to. Some networks are set up well, others not so much.
I would never in a thousand years run a sweep on an airplane network. That's massively risky, to the point you might never be allowed on a jet again. Anything to do with aviation I am on my absolute best behaviour.
Imagine if anything essential/of value/useful was exposed on the passengers WiFi, this story could have been a huge scoop. But alas, everything is heavily separated.
"All new is something already known, but well forgotten."
Escaping locked down networks by tunneling things over DNS is one of these things. We've used it back in 00's to get out of restrictive hotel networks. Not even WiFi, but the actual wired Ethernet ones.
I have done similar things on several long flights.
Very often, there is at least one large cloud provider or CDN (e.g. Microsoft/Azure or Amazon/AWS or Google/GCP) that is whitelisted by the in-flight Internet gateway so that it can serve static pages, and I
can get access to all the sites hosted by that provider simply by using domain fronting (which the author of this post describes as "disguise domain":
https://ramsayleung.github.io/en/post/2025/a_story_about_byp...)
Readit News
I've seen technicians get tripped up in troubleshooting thinking that a failed PING tells them more than it does. When the possibility of asymmetric return paths is involved it's always important to remember how little a failed PING actually tells you.
Deleted Comment
However, just as you make sure that the power supply actually supplies power before dismantling something that refuses to work down to the last washer, repairing network problems should start with the basics. Simple test that does not work, or shows something nonsensical, is a great hint that you forgot something, or should start digging elsewhere.
Edit: I wonder if any "enterprise" firewalls do ICMP echo proxying. Having the firewall replace the payload would remove some of the tunneling capability (thought I assume you could still finagle a side channel by just timing the packets) but would also eliminate some of the utility (since being able to craft the payload provides a way to test for specific bit patterns in packets causing problems).
Except if you bypassed payment and used the service in a manner that was not intended, most likely you were by definition not undertaking "strict adherance" to service terms ?
Yes, long flights are miserable and air travel is a bit of a ripoff. I choose to cope by treating it as an internet break and enjoying a dense book.
Not law per se. More like contractual obligations taken upon by connecting to the flight's WiFi.
https://web.archive.org/web/20250823174801/https://bobdahack...
For all intents and purposes it is the country of registration of the aircraft.
There are one or two exceptions to the rule, but they would not be applicable in this scenario. Mostly stuff relating to air safety. For example, if the aircraft did something against the aviaition laws of the country being overflown. Or hijackings etc.
Wake me up the first time someone gets into legitimate trouble over a little harmless computer fun like this. Until then..who cares?
Unfortunately this is also the downside of paying. Many times I have paid for internet, only to find it unusably bad. To be fair, I just flew a transcontinental flight on Air Canada the other day and the wifi was fine.
To prevent chat apps from consuming lots of bandwidth typically your connection is severely bandwidth restricted until you pay. If they didn't then someone could simply stream movies from their chat apps.
For some reason, being fully connected at 50mbps+ on a plane seems more futuristic sci-fi to me than everything AI.
Maybe planes can offer gambling while over the ocean?
For the exec who pitches this at a board meeting: you're welcome (cries)
Dan passed away in 2021, rip.
if you search for it its hard to find. his blog is down (hea dead...), and many companies and people talked about it on his behalf to drive traffic (hi duo sec..), so you can see the internet forget, rediscover, and rewrite some history even in a few years.
> Since acwifi.com is accessible but github.com is not, is it possible that the network has imposed restrictions on the DNS server, only resolving domain names within a whitelist (such as instant messaging domains)?
> If this is the case, can I modify /etc/hosts to disguise my server as acwifi.com, so that all request traffic passes through my server before reaching the target website (github.com)?
But by putting the host in /etc/hosts, you're skipping asking the planes DNS server, so how are you "disguising" an external server? And why go through the effort of proxying through acwifi.com instead of going straight to the example of github.com
You see these sorts of shenanigans being used to get around country-wide firewalls. Plenty of deep packet inspection is unable to handle edge cases like the "Host:" header being misleading, having it fragmented into two TCP packets, etc. See "domain fronting".
People do get nervous, and in theory you could probably break some kind of informational system utility if you kernel panic the box that booms up to the satellite receiver, but unless you're trying to get root on the plane's routers I don't believe there's a need to feel brave.
The braver part is publishing the results of this stuff online under your own name.
But "hacking" on an aircraft isn't going to be looked on particularly sympathetically by courts
But I assume that neither of us has anywhere near enough expertise to “refuse” to believe that any computer/software system could be used in dangerously absurd ways even accidentally.
I'll echo the article's disclaimer: This reply is intended solely for educational and research purposes. I affirm the strict adherence to all relevant regulations and service terms.
I once merely mentioned the words “Heart Attack” on a plane and was kicked off by the flight attendants. No context, they just heard the words and forced me off.
There are things that trigger them because of laws and regulations like mentioning “bomb” (even if you’re describing something fantastic).
So messing with the gogo flight entertainment is up there with flirting with terrorism charges.
I would never in a thousand years run a sweep on an airplane network. That's massively risky, to the point you might never be allowed on a jet again. Anything to do with aviation I am on my absolute best behaviour.
I was on airplane with large aggressive dog, that was harassing other passengers. I was worried it would ampute my limb mid flight.
I voluntary left before take off, dog stayed!
Well now you have a chance to tell your side - were you merely sitting and just uttered the words "heart attack" for no externally apparent reason?
Escaping locked down networks by tunneling things over DNS is one of these things. We've used it back in 00's to get out of restrictive hotel networks. Not even WiFi, but the actual wired Ethernet ones.
I have done similar things on several long flights.
Very often, there is at least one large cloud provider or CDN (e.g. Microsoft/Azure or Amazon/AWS or Google/GCP) that is whitelisted by the in-flight Internet gateway so that it can serve static pages, and I can get access to all the sites hosted by that provider simply by using domain fronting (which the author of this post describes as "disguise domain": https://ramsayleung.github.io/en/post/2025/a_story_about_byp...)