I then tried using Google's DNS servers. I use wicd and I'm not certain I did it correctly as I left "DNS doman" and "Search domain" blank. However, the servers got into resolv.conf and I can still access other pages so I guess it is using Google's DNS. philosophypages.com, however, is still no go.
Before I changed it, I noticed that resolv.conf was using a LAN address for nameserver. I was surprised by this but as everything works I guess it must somehow be correct.
Thanks very much to jasonwryan for the script. Think I had better try that next. A work around is definitely looking appealing right now even if it doesn't really "solve" the issue. It is driving me slightly nuts, though, as I can't understand what it might be. I was thinking firewalls etc. but since both machines are affected, that seems less likely. (The other machine has much more vanilla config than mine which rules out a great many configuration issues, though obviously not all.)
EDIT: Or should I be telling the airport base station to use something different rather than the computer?
]]>Regarding the website, it works here although those "*" in traceroute mean that the whole network after 206.251.128.138.ptr.us.xo.net is administered by an idiot which decided to block UDP... I'll try tracerouting it with pings or from a windows machine...
No need for windows, just the privileges for ICMP or TCP syn traces:
> sudo traceroute -I www.philosophypages.com
...
17 206.251.128.150.ptr.us.xo.net (206.251.128.150) 175.169 ms 175.168 ms 175.074 ms
18 leviathan.cnchost.com (207.155.252.18) 179.669 ms 176.011 ms 175.988 ms
> sudo traceroute -T www.philosophypages.com
...
17 206.251.128.146.ptr.us.xo.net (206.251.128.146) 182.617 ms 175.698 ms 179.401 ms
18 warrior.cnchost.com (207.155.252.219) 180.658 ms !X 178.463 ms !X 178.741 ms !X
If you have ssh to outside your network, you can use "ssh -ND XXXXX remote.server.com" as a normal (non-root) user to open a SOCKS4 proxy port XXXXX on your system. Then, instruct firefox in the internet settings to use socks4, e.g. user@localhost.localdomain:XXXXX. Of course, that's a mere workaround...
]]>I need to learn more about this stuff. I'm sure as a work around I could somehow use ssh since my work machine can connect to the site fine and I'm running a ssh server on that. Alas, my networking skills are not what they might be. Off to read...
cat Scripts/tunnel
#!/bin/bash
SSH_HOST="cfr@work"
up(){
ssh -f -N -D 8080 -M -S /tmp/ssh_tunnel_%h.sock -o ExitOnForwardFailure=yes $SSH_HOST && \
printf '%s\n' "ssh tunnel started successfully" || \
printf '%s\n' "ssh tunnel failed to start"
}
down(){
ssh -S /tmp/ssh_tunnel_%h.sock -O exit $SSH_HOST
}
if [[ "$1" = "up" ]]; then
up && chromium --proxy-server="socks://127.0.0.1:8080" &
elif [[ "$1" = "down" ]]; then
down
else
printf '%s\n' "Tunnel is not running…"
fi
$ ping -c 1 philosophypages.com
PING philosophypages.com (207.155.252.97) 56(84) bytes of data.
64 bytes from elephant.cnchost.com (207.155.252.97): icmp_seq=1 ttl=235 time=162 ms
--- philosophypages.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 162.130/162.130/162.130/0.000 ms
It seems weird that I can ping it but not connect to it with http. Anyway, off to look into DNS switching...
I need to learn more about this stuff. I'm sure as a work around I could somehow use ssh since my work machine can connect to the site fine and I'm running a ssh server on that. Alas, my networking skills are not what they might be. Off to read...
]]>I know setting MTU manually is not usually necessary but my ISP appears to have set things up in a buggy way so if I'm at home I get a much lower MTU if I use "auto" which prevents me accessing AUR over ssl. Hence the need to specify something sane. On campus, it is fine. (That network has other problems just not this one.) Before anybody mentions it, the ISP is not my choice and the decision is not in my hands so switching to a saner ISP is not an option.
This is a cable connection (via a wireless LAN).
I thought it could not be DNS since the hostname is resolved correctly? Is the thought that it could be DNS somehow further down the line? Anyway, I can definitely look into this.
I figured, the website redirects your request somehow...
$ ping -c 1 philosophypages.com
PING philosophypages.com (207.155.252.18) 56(84) bytes of data.
64 bytes from leviathan.cnchost.com (207.155.252.18): icmp_seq=1 ttl=237 time=194 ms <------ !!!
--- philosophypages.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 194.597/194.597/194.597/0.000 ms
Regarding MTU, ISP's are usually very broken. MTU=1500 is the default for ethernet these days. For instance, without any MTU info provided by my DHCP server, I have on the client
$ cat /sys/class/net/wlan0/mtu
1500
This is set by the kernel. OTOH, Comcast (in my case) provides a *completely* wrong MTU info for the broadband cable connection:
% /usr/sbin/dhcpcd -U wan | grep mtu
interface_mtu=576
which is the protocol minimum corresponding to a dialup connection. All router makers I know (cisco, dlink, ...) ignore this and set MTU=1500. Of course, after several enlightening discussions with Comcast tech support, I just added "nohook mtu" to dhcpcd.conf... sigh.
]]>EDIT: I did set the log level in shorewall to 2 and kept an eye on the log files but nothing is being logged in journalctl as being dropped, well nothing except random external packets to a torrent port.
SOLVED: Apparently I had a problem with conntrack, amongst other things. I used firewall builder instead of shorewall to create new iptables rules and when the script is run iptables complains about STATE method should be replaced with conntrack. Well for now the STATE method still works. O, and squid.conf: workers 4 tries to bind too many times and crashes itself, stick to 1 process.
]]>This is a cable connection (via a wireless LAN).
I thought it could not be DNS since the hostname is resolved correctly? Is the thought that it could be DNS somehow further down the line? Anyway, I can definitely look into this.
]]>Regarding the website, it works here although those "*" in traceroute mean that the whole network after 206.251.128.138.ptr.us.xo.net is administered by an idiot which decided to block UDP... I'll try tracerouting it with pings or from a windows machine...
Since you can access other websites fine, I wonder whether the issue is somehow related to DNS. Can you try changing your DNS servers?
]]>I guess it is not an extension problem because it affects lynx as well.
Anyway, I just tried setting MTU to 1400 but I'm still getting no connection in both firefox and lynx. In firefox, the attempt to connect never even seems to time out - firefox seems to just keep trying to connect forever. In lynx, the connection will time out eventually and tell me the connection wasn't possible.
I x'ed out the ips in the output only because Virgin apparently use ips and addresses which are a function of your account number.
]]>