http protocol isn't working on my computer

http isn't working on my computer, but https is. I thought it had to do with after I rebuilt world with fewer options.

I looked up if there were Internet blackouts in my area, and there were, but then later I realized that only http wasn't working, and that my Roku was working fine.

I thought that maybe they changed the settings src.conf(5) from previous versions, that an unencrypted service like telnet, talk or ctm were needed. I also thought that maybe they moved ssl base system dependencies into ssh. I went to the appropriate place under /usr/src by using grep on Makefiles for the programs I suspected that were needed. Then I installed ssh, telnet, talk and ctm from the source code. portsnap and other base programs used to fetch files needed for FreeBSD still didn't work.

Then I used another device to try to access an http site. I got the same service provider message, while https still works on it. It's my computer, I refreshed my other device.

* I'll update this later.
 
I'm quite new to the BSDs but to me it sounds like you have done a lot of needless things that are completely unrelated. Installing SSH or Telnet?

Let's start with the basics.
  1. Why do you think HTTP isn't working on your computer? What do you try, what do you expect to see and what are the results you're actually observing?
  2. Have you tried different websites and different browsers?
  3. Can you do a tcpdump()?
 
The problem is either in the base system, or it's the network. I tried to access a http address on my phone, and this time the problem occurred there too, when I set it to my wifi.

Here's the reasoning, when I run portsnap, it fails on the http web addresses. http:// is the prefix and freebsd.org is the base name, yet https:// with freebsd.org works. I type http addresses into my phone and on my browser, and it takes me to my internet access provider screen. It's taken me to that screen in the past, when there was a network problem, and when the account was fine, but then it wasn't selective on Internet protocol. This is odd, because https sites work on my computer. I go to DuckDuckgo to look for http websites, and it takes me to that screen. https websites take me to the actual site. I'm sure about this from my computer about http not working and https working.

This addresses questions 1 and 2, but my phone will have this problem inconsistently. It will take me more effort to effort to install another browser, even w3m, to see it there. but this is from the base system and on my only browser. pkg, and make fetch don't work either, because they rely on http it seems. svnup works.

The third question. I ran tcpdump, and my head spins from a lot of output, even when I turn everything off. If I post that, I may give too much information about my location that will be public. I know I asked for assistance. Understanding troubleshooting a network is a difficult topic for me. I was wondering of the possibilities of an Internet provider causing that, or if something changed from this version to a last one, that worked one time and not another. I also get a banner on the top of my screen saying I need to log in to use the network. I rebooted my router before and cleared the device list. I think it's the provider network.

It's odd. I can ping these web address. The ping command doesn't seem to allow http:// or https:// at the beginning. ping works on http://, and that everything through other programs that is meant for http:// goes to a login page, when https works is actually suspicious, to tell the truth. https is meant to protect against fake login pages, and perhaps it is doing well at that.

The message "You must log in to this network before you can access the Internet" keeps popping up and going away on my browser. Either my computer is fine, or I messed up my system in ways I don't understand, in ways that shouldn't have broken it, because I've rebuilt world on previous versions of FreeBSD, with the same options, and didn't get these problems.

I'll shut off my computer for now.

It happens on my phone too, when I click on any http website from duckduckgo.com. This is far fetched, but that is a hallmark of a phishing like scam, or an Internet attack on the internet provider's infrastructure, that only http is being redirected, and not https.
 
That sounds like a problem with your internet provider, not with your FreeBSD machine.

It is very unlikely that you accidentally disabled HTTP but not HTTPS. If the latter works, then your network setup works in general. Actually there are not many ways to selectively disable HTTP only. You could add a firewall rule to block port 80, but that doesn't happen by accident.
 
Maybe there is a router setting to only allow https, and to block http?

The message "you must log in to this network before you can acces the internet" keeps popping up.
This happens to me sometimes, when my wlan automatically connects to a nearby hotspot (from telekom), instead of my router.
ifconfig wlan0 |grep ssid shows you to which network you are connected to.

Ping uses icmp protocoll, which is different from http protocoll. You can't mix the two.
 
Maybe there is a router setting to only allow https, and to block http?

This happens to me sometimes, when my wlan automatically connects to a nearby hotspot (from telekom), instead of my router.
ifconfig wlan0 |grep ssid shows you to which network you are connected to.

Ping uses icmp protocoll, which is different from http protocoll. You can't mix the two.
I didn't change my router settings.
My computer's Internet is through ethernet wire. It has no wifi card.
What you reminded me about ping using icmp further supports that the problem is limited to http protocol.
 
it takes me to my internet access provider screen
It sounds like your Internet service provider intercepts HTTP traffic and simply shows your their page. What does its page say? I'm sure it has information on what to do to fix the issue, e.g. pay your bill, login again if it's some kind of DSL setup....

I suggest you contact your ISP first. Especially since it happends both on your FreeBSD machine and on your mobile phone.
 
So. I disconnected my phone from wifi, bypassing my home Internet connection, and clicked on an http site, and it worked. Then I connected to wifi, and refreshed, and the real page stayed, when I clicked to a link from it to the same base address, the site went to the real page.

When I connected to wifi, and clicked on the same http link from a new tab from that https search engine, I got the error message saying log in. So, it's not FreeBSD.

It sounds like your Internet service provider intercepts HTTP traffic and simply shows your their page. What does its page say? I'm sure it has information on what to do to fix the issue, e.g. pay your bill, login again if it's some kind of DSL setup....

I suggest you contact your ISP first. Especially since it happends both on your FreeBSD machine and on your mobile phone.
An ISP is not supposed to do that for a selective traffic that's vulnerable and not across the board. That's underhanded behavior, and it's doubtful it's them.

It's like a phishing attack, or network error or blackout on their side. Https is meant to block 3rd party fakes. Https has 3 points to verify a connection, two connections of the Internet, and the issuer which verifies. 2 parts only can be spoofed on the handshake. Self signed https only has 2 verification points, a third party makes it harder to get around. An attempted spoofer can't handshake with three sites so far apart. With self signed, the attacker can ask for the password, then the connection to the spoofer is secure, which amounts to false security. A third party authentic issuer watches that, and the spoofer would have to fool both which is nearly impossible. Http has neither of those roadblocks.

Maybe some drunk driver ran over an Internet box in my neighborhood, and https is being prioritized by the ISP?
 
Maybe your ISP is running (or trying to run) some kind of transparent proxy? Maybe something is wrong on their side.
Anyway, as several people have suggested: You should communicate with your ISP. Probably they are the only ones who can solve the problem, or at least explain it.
 
Keep in mind that HTTP and HTTPS are the same protocol: HTTPS is just tunneled using TLS encryption. The basic protocol is identical.

Agree this sounds like an ISP issue - especially given the fact you get a web page from your ISP.
 
An ISP is not supposed to do that
Well, I guess it depends on the kind of contract you have with them. Without seeing the exact page you're seeing when you try to access an HTTP page and without a tcpdump capture, there is not much we can do to help.
 
Well, I guess it depends on the kind of contract you have with them.
I will check with my ISP. That kind of contract wouldn't make sense, but the error has happened before when my status was fine, and it was a problem for the neighborhood.
Without seeing the exact page you're seeing when you try to access an HTTP page and without a tcpdump capture, there is not much.
I've been aware, that I can only be helped better by how much information I release. I will come around when I learn more. I can sit like this for a week or so.

I've looked online about it, and some said it was a spoofing scam, and then others said it was a legitimate server provider account login. It could be either or a combination of both. I believe it could be a spoof page, designed to look like a real page, I've seen an example in the past of the web address bar being spoofed.
 
I've seen such things before, on not-so-serious provider uplinks. It seems to become a (bad) habit of providers to intercept HTTP traffic and do whatever kind of stuff there. This may not happen with HTTPS, because that is encrypted, and more difficult to intercept.
Furthermore, there are many sites that do no longer offer HTTP, and will try to switch the browser to HTTPS on the fly.

It is quite simple to do HTTP manually without a browser and see what exactly happens, but then it needs a little bit of experience with TCP to understand what shows up.

Open a terminal, and enter
Code:
 $ telnet freebsd.org 80
GET /crap HTTP/1.0
<enter>

You should see the following:
Code:
$ telnet freebsd.org 80
Trying 96.47.72.84...
Connected to freebsd.org.
Escape character is '^]'.
GET /crap HTTP/1.0

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 09 Sep 2019 18:19:43 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
Location: https:///crap

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
Connection closed by foreign host.

This is raw HTML code, and they just tell us that they do not do HTTP, and we should instead use HTTPS.
A browser would then automatically retry the same request with HTTPS.

So, in order to do some reliable testing, you will need to know an URL that does actually work with HTTP. You can try this one http://188.40.204.31/download/Untitled-0-inc.jpg - it just send a picture of some satanic child abuse.
 
I've seen such things before, on not-so-serious provider uplinks. It seems to become a (bad) habit of providers to intercept HTTP traffic and do whatever kind of stuff there. This may not happen with HTTPS, because that is encrypted, and more difficult to intercept.
Furthermore, there are many sites that do no longer offer HTTP, and will try to switch the browser to HTTPS on the fly.

It is quite simple to do HTTP manually without a browser and see what exactly happens, but then it needs a little bit of experience with TCP to understand what shows up.

Open a terminal, and enter
Code:
 $ telnet freebsd.org 80
GET /crap HTTP/1.0
<enter>

You should see the following:
Code:
$ telnet freebsd.org 80
Trying 96.47.72.84...
Connected to freebsd.org.
Escape character is '^]'.
GET /crap HTTP/1.0

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 09 Sep 2019 18:19:43 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
Location: https:///crap

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
Connection closed by foreign host.

This is raw HTML code, and they just tell us that they do not do HTTP, and we should instead use HTTPS.
A browser would then automatically retry the same request with HTTPS.

So, in order to do some reliable testing, you will need to know an URL that does actually work with HTTP. You can try this one http://188.40.204.31/download/Untitled-0-inc.jpg - it just send a picture of some satanic child abuse.
I would thumb down the part about the chosen web address. From reading about it, I know it's not trouble, but it looks like trouble. Maybe an image like from a decent proposal?
telnet freebsd.org 80
Code:
Trying [IP6 address].
telnet: connect to address [same IP6 address, I believe FreeBSD's] Connection refused
Trying 96.47.72.84...
telnet: connect to address 96.47.72.84: Connection refused
telnet: Unable to connect to remote host

It's a scammer. On the "login page" I looked up the listed number online, and many say it's a phishing scam. According to what others have said on the Internet, that number asks for details over the phone, which it shouldn't.

I think people assumed it was with the provider, that's understandable. It could have been, but I've seen that error before, but this time selective, when my provider status was fine in the past, I later heard someone ran over those Internet boxes around that week a few years ago.

The only way it makes sense that a provider selectively block http, is if they're trying to phase out http, or if they're lowering prioritization for http, because maybe that attracts more attacks and bad traffic than https. It wouldn't be decent behavior for an ISP to force me to that page when using http intentionally. Http is where an illegitimate attack would go for. If my provider is going to do something, it would do it to all protocols, not just the weakpoint, and it would do it to other unsecured protocols too, not only the unsecured one where data it wants can be sent back.

Basically, everything through http without the s, does this. No matter where I find it from my search engine or those basically listed for connections from programs in the base system.

As I said above, when I used my phone through another Internet account, not through wifi, http worked. When I switched to wifi, then clicked a tab, that webaddress from the link to the same basic website also worked. The link from the legit page, and also not from the search engine, caused it to direct properly. Doing everything from the wifi on the phone, caused that stupid fake login page for http.

I now wonder if the problems the provider had a few years back was also a phishing scam that was done less consistently, and caused the ISP problems.
 
I would thumb down the part about the chosen web address. From reading about it, I know it's not trouble, but it looks like trouble. Maybe an image like from a decent proposal?

Nope. Tilburg Incubate 2014, venue newspaper.

Code:
[cmd]telnet freebsd.org 80[/cmd]
[code]Trying [IP6 address].
telnet: connect to address [same IP6 address, I believe FreeBSD's] Connection refused
Trying 96.47.72.84...
telnet: connect to address 96.47.72.84: Connection refused
telnet: Unable to connect to remote host

It's a scammer. On the "login page" I looked up the listed number online, and many say it's a phishing scam. According to what others have said on the Internet, that number asks for details over the phone, which it shouldn't.

There's a bunch of questions with that explanation:
1. Where does the regular HTTP traffic get the "connection refused"?
2. How and where is the connection hijacked so that a "login page" could appear?

One might assume that Your machine is compromized, but that is somehow unlikely with a locally built world.
But maybe something else? The outbound router?

As I said above, when I used my phone through another Internet account, not through wifi, http worked. When I switched to wifi, then clicked a tab, that webaddress from the link to the same basic website also worked.

That could come from cache inside the browser.

The link from the legit page, and also not from the search engine, caused it to direct properly. Doing everything from the wifi on the phone, caused that stupid fake login page for http.

So it's not Your computer that is compromized, but something further along the uplink. What is the next component where the computer is wired to and where the wifi is served from?
 
Some routers can get viruses. A friend had a Mikrotik router that was infected with a coinhive miner, all http request on his devices were redirected. Maybe you have a similar problem, a factory reset and firmware upgrade(if there is one) should fix it.
 
So, I rebooted my device. And then portsnap temporarily worked for 15 seconds. Then, it went back to failing.

Along the lines of what PMc was saying: the problem is likely still outside of the firewall, because it's trying to gain access to my firewall by spoofing.

I tried rebooting my router, changed and perhaps re-leased the IP adresss, then I reset it to factory defaults. It gave me back the same IPv6 web address. The same problem persists. I have to look into upgrading firmware, which it doesn't do automatically from the router panel.

curl -vs http://freebsd.org
Code:
*   Trying 96.47.72.84:80...
* TCP_NODELAY set
* Connected to freebsd.org (96.47.72.84) port 80 (#0)
> GET / HTTP/1.1
> Host: freebsd.org
> User-Agent: curl/7.65.3
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location:https://[[fake_webaddress].html
* no chunk, no close, no size. Assume close to signal end
<
* Recv failure: Connection reset by peer
* Closing connection 0
<HTML><BODY></BODY></HTML>
curl -vs6 http://freebsd.org for IPv6 gave a similar output.
This part of the error is in the output of the IPv4 option of curl, but not of the IPv6 version:
Code:
* Recv failure: Connection reset by peer

Kind of telling, but kind of expected.

It's not the same service in the fake webaddress that I'm using. It's the same fake page address I get in my browser.

I was thinking of using traceroute and traceroute6, but the protocol that is not http, might not give the location or error of the problem.

I hope this helps people identify about that fake spoofing attempt.

About the topic of refreshing. There was a refresh issue, but when I got into a legitimate website on my phone, by bypassing the wifi router, then by going back to the wifi router, I was able to link to a different webpage, under the same domain, but a completely different page (not itself as a whole cached, never traveled to before page). Perhaps the legitimate page data (headers, links, css, php) was cached, that got the default over the spoofing attempt when switching back to the home router. It loads faster, so got the default. when coming from another legitimate search engine, the spoof can hijack the connection, because it's quicker.
 
Why don't you call your ISP and ask them about it? Why don't you upload a screenshot of the page your ISP is showing you?

I really do not understand why you are keep trying to "troubleshoot" this issue by rebooting your devices. Also, I do not understand what you mean with "trying to gain access to your firewall by spoofing"? There is no indication anyone is trying to gain access to your router or firewall. It sounds like an issue at your ISP so please just contact them.
 
curl -vs http://freebsd.org
Code:
...
< HTTP/1.1 302 Found
< Location:https://[[fake_webaddress].html
What exactly is that “fake_webaddress”? Is it an IP address that belongs to your ISP, or something else?

Either your router is compromised, or some other component between you and your ISP.
 
It is, https://myattwg.att.com/UverseAccount.html
which is the exact address in my browser.
AT&T - Account

AT&T High Speed Internet

Important Message from AT&T

Your account needs immediate attention. Residential customers can log in with your myAT&T user ID and password to be back to browsing the internet as quickly as possible. If you are not registered with myAT&T and a Residential customer, please call us at 1-800-288-2020. All Small Business customers must call us at 1-800-321-2000.

To ensure that you reach the right department, it is important that you provide your billing telephone number when prompted.
I'm confused, the number 1-800-288-2020 shows up in search engines with claims saying it's a scam account. I think the other number is real, but it's just used as a decoy, as it's a business number and the targets are residential customers. They say that web address is real, but my suspicion is that the webaddress is spoofed, and most of what is to att.com on my computer will redirect there. I think the certificate is spoofed too, because once I am redirected there, it's not from the regular internet itself, which cannot be spoofed. and the cache is going to keep that one, the first one accessed.

I really don't know, it could be real, but it doesn't make any sense. The Internet says that number is fake, but why would such a phony scam number be in existence since 3 years ago. I think they thought the page was real, and didn't look into the number as a clue. Some say, that number is real, but I suspect those are parts of the scammers themselves. Most say that number is fake, that their card gets charged, they're asked for information they shouldn't, that the real AT&T company says it's a phony account. It also doesn't make sense for that to be a scam, because for so many years, that would have been taken down, unless people were too blind to see it.

If my router got compromised, it was through the phone, when it keeps saying do I want to log in to the router's wifi, but that access is only for the connection, and not for administrative use, and that password was reset afterwards. On later attempts, the phone said earlier, the connection is untrusted.

tommiie , the type of error doesn't make sense, and I was listening to others' suggestions. It is possible, I am making a big deal out of something little. I just want to make sense of it. To call the suspicious posted number would be a mistake. I'm getting around to it., I just wanted to investigate a little first.
 
Last edited:
That web page looks legit. The address definitely belongs to AT&T. I think you should try calling them.
 
Wow. That's cute. AT&T has now gone scammer. This looks like dawn of the apocalypse.
I would love to get this into some popular media, like WIRED or such.

We had that already with PayPal - they have sent out advertisement crap by an associated commercial SPAM distributor (and deeply hidden in their terms&conditions they say that they do so), and their own SPAM department identifies these messages as a scam.
 
!'m confused, the number 1-800-288-2020 shows up in search engines with claims saying it's a scam account.

Doesn't seem so. Seems to be an AT&T customer care number.

But then, the whole make-up looks like a scam - although it probably isn't.

What appears to be the case, AT&T is trying to economize on postage stamps for proper customer communication, and instead hijacks the HTTP traffic to make the customers call them.
I would consider this as strictly inacceptable, and would instead send them a bill for security cleaning the computer. (I doubt they will pay that without a lawsuit, but at least a bill might be the only thing they would properly read.)
 
Back
Top