-- Leo's gemini proxy
-- Connecting to thrig.me:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
An #openbsd user did sometime complain,
> After logging in, pinging openbsd.org gives: signature mismatch from 199.185.178.80: icmp_seq=0. However, `pkg_add vim` worked nicely. I'm not sure if the internet is working well.
A common foible is to assume that because ping isn't working, everything must be broken. This is not true; everything else could be perfectly fine. The reason might even be found in the fine manual.
> Note - if you are using the (default) SLiRP user networking, then ping (ICMP) will not work, though TCP and UDP will. Don't try to use ping to test your QEMU network configuration!
Other reasons might include overly zealous firewalls, though there one might expect the packet to be dropped, not a signature mismatch--maybe it's a zealous and buggy firewall? Such are not unknown. Even with a zealous firewall that blocks ICMP echo requests (or the responses, or both), all sorts of other protocols and ports could be open. Or maybe pings are rate limited and your system happened to be beyond the limit when you tested it. In this case one might try the same thing and expect a different result (Einstein).
That pkg_add works indicates that HTTPS works and likely also DNS, too. Everything else could be broken--maybe the hypothetical firewall only allows DNS and HTTPS. Package requests could be done by IP address, in which case DNS could also be blocked. Unlikely, but possible.
ICMP is more likely to be blocked in IPv4 than in IPv6. Some firewalls will try to block as much as possible, or maybe do block most everything until you interact with the captive portal at the coffee shop. Tunneling over DNS or other such tricks may be possible.
Carefully. Maybe start at the physical layer; if the wifi is dead or a cable is loose there's little point in testing anything else. Check the documentation or with coworkers to see if there are any special rules or other things you need to know about. There may not be documentation, but so these things go.
ping is a good tool, provided not too much weight is put on a negative result.
DNS requests can be made; memorize or write down the IP addresses of public DNS servers. Various protocols such as DHCP may tell you the local DNS servers and routers. Or these might be documented somewhere.
$ cat /etc/resolv.conf
nameserver 127.0.0.1 # resolvd: unwind
#nameserver 192.168.42.1 # resolvd: iwx0
lookup file bind
$ netstat -r | grep default
default 192.168.42.1 UGS 10 5421 - 12 iwx0
Note that DNS requests can be cached, which is what that unwind thing does. Test 192.168.42.1 directly, in addition to public DNS servers. Learning what normal looks like can help when things are broken. You could also test 127.0.0.1 to see if it differs from the other two, especially if there have been recent DNS changes. DNS servers may have a negative cache to even more complicate matters, which can be a problem if you test if a record exists (it does not), create that record, and then hit the negative cache from the earlier test.
$ host -t A example.com 192.168.42.1
Using domain server:
Name: 192.168.42.1
Address: 192.168.42.1#53
Aliases:
example.com has address 93.184.216.34
$ host -t A example.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
example.com has address 93.184.216.34
You may need something like dig(1) if it's a tricky DNS problem involving recursion or authority. Sometimes you do need a tool with all the gadgets. Usually not.
Make network requests--Gemini, HTTP, HTTPS, SSH, etc (some may be problematic, especially if you make too many of them too quickly). Coffee shops might have a captive portal that some of these tests will be redirected to, if they are not blocked. A tool that shows the redirects might be good.
$ lwp-request -PSud http://openbsd.org
GET http://openbsd.org
301 Moved Permanently
GET https://www.openbsd.org/
200 OK
NTP might be open, maybe your system is syncing its time with some local or internet time server? Monitoring that the time is synced might be good, especially if a system has a bad battery and is prone to reset to the year 2000, which may not be a good date for that big git commit.
$ ntpctl -s status
5/5 peers valid, constraint offset -1s, clock synced, stratum 4
Or run tcpdump and see what is going on. Maybe exclude your SSH sessions from this, or other such protocols that generate lots of packets. This can be educational, or risky if there's a security vulnerability in tcpdump. Maybe test from an unimportant system that you reinstall often?
You can also fool around with nmap(1), which could get you in trouble (nmap used to crash SGI IRIX systems) or ping all the local addresses on a subnet to see what is out there. Maybe check with the networking and security groups first?
Start slow.
It may help to show how only ping can be blocked in a firewall. This may not be a good idea. It may be a good idea to use a test system to play around with a custom firewall, or to have a means to restore the previous firewall configuration automatically after some amount of time. Locking yourself out of your own systems is a real problem, and it's worse if you do not have physical access.
block in quick log inet proto icmp all icmp-type echoreq
...
There might also be a probability of the request being blocked, or rate limiting rules to limit how many pings a system will reply to in a given amount of time. The firewall documentation may have details on that sort of complication.
-- Response ended
-- Page fetched on Wed May 22 02:18:45 2024