1

After getting my Arch laptop to connect to my phone's hotspot, I was having trouble connecting to any websites that were't cached (for the most part, anything but Google).

I looked a little, and found that even though it was deprecated, ntpdate worked to update my time correctly:

sudo ntpdate -u time.nist.gov

That gave me the correct time. But I was still having issues connecting, this time supposedly with DNS, or so Chromium was telling me. Still couldn't connect to anything other than Google, but at least the date issue had been fixed... or not.

I looked back at my clock and the time was back where it was before, two hours ahead. I checked systemctl and ntpd was still running, and it evidently thought it was the correct time.

Why does ntpd think the time is correct, and why would I still be having DNS issues?

Improve this question

1 Answer 1

Reset to default
1

It turns out, in my case, that because my phone was maintaining a connection to a proxy in a timezone two hours ahead, when my laptop (that 'didn't know' it was connected to a proxy server) was trying to connect to websites, it was sending the wrong time for my timezone.

Upon disconnecting from PIA (the proxy service) on my phone, everything went back to normal.

Improve this answer
2
  • This seems very strange. If I connect to an office of ours the other side of the world and use that as my egress point, I don't have any issues accessing websites (apart from latency, that is). Was your proxy aggressively rewriting every HTTP header?
    – Chris Davies
    Commented Nov 15, 2017 at 14:27
  • To be honest, I'm not sure. I didn't want to follow it all the way back from Chromium -> Linux -> Mobile Hotspot -> Proxy. It's entirely possible though. I used the Private Internet Access Android app if anyone is interested in checking/can replicate the issue.
    – Trevor Sears
    Commented Nov 15, 2017 at 15:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .