Cannot log in to my university internet in Fedora 37 KDE

Ask Fedora
22

Hi, I cannot access 143.54.2.20 (Linux).

$ ping 143.54.2.20
PING 143.54.2.20 (143.54.2.20) 56(84) bytes of data.
From 192.168.0.1 icmp_seq=22 Destination Net Unreachable
From 192.168.0.1 icmp_seq=83 Destination Net Unreachable
From 192.168.0.1 icmp_seq=296 Destination Net Unreachable
From 192.168.0.1 icmp_seq=326 Destination Net Unreachable
From 192.168.0.1 icmp_seq=357 Destination Net Unreachable
...

I had a little chat with the network internet here and he said the basically just disable DHCP in the router and change thes router IP so the last few numbers can refer to our floor and room number. I still haven’t figure it out how to acess my router. Maybe I can ask him that.

I’ll update you when I have more info.

23

Thanks for the update. Presumably this works fine from Windows or another Linux distro? It doesn’t make sense to me: you’re obviously having router problems rather than just the original DNS issues. But the router is just receiving and forwarding packets: it doesn’t (shouldn’t) matter which OS or machine they come from, unless there is something significantly broken with the installation. Not to sound like a Microsoft tech support type, but have you tried re-installing? Maybe a different version of Fedora: 36 instead of 37, GNOME instead of KDE, just in the interests of science.

It’s a conundrum. but I for one would love to know what’s going on.

I just tried resolving your university’s domain again and now there’s an IPv6 address record returned:

$ nslookup ufrgs.br
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   ufrgs.br
Address: 143.54.2.20
Name:   ufrgs.br
Address: 2804:1f20:0:1::20

$ ping 2804:1f20:0:1::20
PING 2804:1f20:0:1::20(2804:1f20:0:1::20) 56 data bytes
64 bytes from 2804:1f20:0:1::20: icmp_seq=1 ttl=31 time=324 ms
64 bytes from 2804:1f20:0:1::20: icmp_seq=2 ttl=31 time=346 ms
64 bytes from 2804:1f20:0:1::20: icmp_seq=3 ttl=31 time=369 ms
^C
--- 2804:1f20:0:1::20 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3003ms
rtt min/avg/max/mdev = 323.520/346.002/368.828/18.498 ms

Can you reach the IPv6 address at all?

24

If I load the site https://ufrgs.br in a browser it gets redirected a couple of times to http://www.ufrgs.br/ufrgs/inicial (no TLS (https) which is a bit odd…)

Anyway, can you e.g. curl http://www.ufrgs.br/ufrgs/inicial or curl http://[2804:1f20:0:1::20]/ufrgs/inicial or curl http://143.54.2.20/ufrgs/inicial? I’m guessing that you should be able to do the last one but the other two should fail (because they both end up using IPv6 addressing and that seems to be problematic - see below)

I just tried this while using Wireshark to analyze network traffic:

wget --verbose --header="host: www.ufrgs.br" --user-agent="Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0" http://[2804:1f20:0:1::20]/ufrgs/inicial

(user agent and host headers taken from inspecting the request in Firefox)

http://www.ufrgs.br/ufrgs/inicial is the home page from the university site after a couple of redirects (ufrgs.br → www.ufrgs.br → …). Even though I used https as the protocol in the initial request in Firefox, the university server is only accepting unencrypted HTTP/1.1 requests (the second redirect is changing the location to the /ufrgs virtual host and effectively downgrading the connection from TLS 1.2 or 1.3 to cleartext HTTP/1.1. That just seems wrong in 2023; it may be misconfigured. Someone at the university should check).

If I try using the IPv6 address I get an ICMP destination unreachable (port unreachable) packet in response to the connect request (SYN).

If I try using the IPv4 address (http://143.54.2.20/ufrgs/inicial) then I can download the home page from your university server.

It seems that there’s a configuration issue that’s being uncovered when using Fedora: the university server is accepting IPv4 HTTP requests on port 80 but not IPv6 requests, probably because the server is not configured to serve pages from port 80 if reached via IPv6. I am guessing that other OSs are somehow defaulting to IPv4 traffic and that’s getting through unhindered. The question is a) why, if this is the case, is Fedora behaving differently and b) why, if this is the case, is the university server acting differently depending on the network stack that it’s bound to.

The university is using nginx which I’m not very familiar with. As far as I know it’s a reverse-proxy and this is probably significant, but I don’t enough about it to be able to say for sure.

You really need someone at the university who is familiar with the configuration to help you figure out what is going on. I’m betting that it is a peculiarity of Fedora interacting with how this nginx server is configured, and you’re the only person who is doing something different. Probably everyone else is using Windows or maybe Ubuntu?

It’s turning into a bit of a detective mystery (for me at least) and I’m eager to know what is going on!

Addendum: I just tried using the university home page URI in a wget request while sniffing the net:

wget --verbose --header="host: www.ufrgs.br" --user-agent="Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0" http://www.ufrgs.br/ufrgs/inicial

This is slightly different but significant because DNS is involved in the request. This is what I see on the net:

  1. DNS IPv6 name resolver request for www.ufrgs.br (AAAA query record)
  2. DNS IPv4 name resolver request for www.ufrgs.br (A query record)
    On modern systems these two requests go out virtually simultaneously because we now live in a mixed IPv6 and IPv4 world. The ordering is down to how the resolver is coded; it may be significant.
  3. An IPv6 RR packet (AAAA response) is returned from DNS (my router in this case) with the university’s IPv6 address
  4. An IPv4 RR packet (A response) is returned from DNS with the univerity’s IPv4 address (these two items are basically the info that comes out of the nslookup ufrgs.br we did earlier)
  5. A TCP connection (SYN) request is made to the ufrgs.br IPv6 address
  6. An ICMPv6 desintation unreachable (port unreachable) packet is returned (not a RST or FIN meaning that port 80 isn’t bound to the IPv6 stack at the server end)
  7. A TCP connection request is made to the urfgs.br IPv4 address.
  8. A TCP SYN-ACK response is returned from the server: the connection has been made
  9. Standard three-way handshake ACK from my computer to the university server
  10. The HTTP/1.1 (cleartext!) GET /ufrgs/inicial request is made
  11. The data is returned in a series of packets on the HTTP/1.1 connection
  12. The connection close is initiated by the client (FIN) (because the application exits)
  13. The university server finishes closing the connection (FIN-ACK)

So basically: we resolve the name, get an IPv6 and IPv4 response, in that order, try to connect to the IPv6 address on port 80 but that port is not bound to the IPv6 interface at the server so the request is denied via an ICMPv6 destination unreachable packet and we then fall back to the IPv4 address on which port 80 is bound to the interface and the request succeeds.

The ordering of whether to choose the IPv4 or IPv6 responses from the DNS server is likely significant yet a matter of chance: it likely depends on the choice made by the engineer who wrote the resolver code whereas a different implementation could perform the operations in the opposite order. I’m guessing that e.g. Windows checks the IPv4 address first but Fedora is checking the IPv6 address first. If this is the case then it doesn’t answer why your observed behavior is different from mine, namely that my installation falls back to attempting to make an IPv4 connection whereas either yours isn’t, or there’s yet another issue as to why your IPv4 request isn’t being routed to the server correctly.

And at the bottom of it all is why the IPv4 and IPv6 stacks on the (nginx) server installation at your university are different: even though the server is telling browsers to connect to the HTTP server using HTTP/1.1 on port 80 (in cleartext!), it isn’t configured that way for the IPv6 stack.

Once again, good luck!

25

Of course, this doesn’t explain why the /etc/hosts mod didn’t work: if the name resolution was coming from the hosts file as it should have been then there would only have been one IPv4 address returned from the gethostbyname() request in the browser HTTP protocol code and that should have therefore successfully made a connection to the server instance bound to the IPv4 stack. But that apparently didn’t happen: it didn’t work. But then if you only did a dig request then that is going to communicate to the DNS server using the BIND resolver protocol (as far as I’m aware) and not use the shorthand gethostbyname() call e.g. So it might have worked, but maybe we didn’t try navigating to ufrgs.br in the browser, which I think should have worked if my assumptions about what’s going on are correct (probably not!).

(dig can’t use gethostbyname() to resolve names because that call only returns host addresses whereas dig is resolving the name and telling us which name server the response came from: it has to have the raw packets to do that which aren’t provided by gethostbyname())

So I went the extra 1.6 kilometres and fired up Windows 11 and surfed on over to the Universidade Federal do Rio Grande do Sul.

Both Firefox and Edge did the same thing:

  1. Resolve the host name getting IPv4 A and IPv6 AAAA resource records (albeit in the opposite order of Fedora 37, but it turns out this is immaterial).
  2. Make a connect request (SYN) to the IPv6 address
  3. Get the ICMPv6 destination (port) unreachable response
  4. Fall back to making a connect request to the IPv4 address
  5. Connection acknowledged by the server (SYN-ACK)
  6. Web page & all contents transferred
  7. Close connection (eventually when I quit the browsers - connections are keep-alive)

So: what is happening on your Fedora installation where it seems to be making the IPv6 request, getting a host unreachable response and then stopping. Either there is no IPv4 resource record returned from the DNS request(s) when you start the web request in the browser (or otherwise try to resolve the name), or your OS is somehow just deciding not to bother with the IPv4 connection. In which case, why?

As someone who has worked on this code in the past, I should know what’s going on and what bit of code is responsible for making the requests. I’m pretty sure it’s in the browser: the basic procedure is:

  1. resolve the name
  2. if successful choose one of the IP addresses that is returned and try to connect to on a socket
    3a. if that fails go to 2 until there are no more addresses to try at which point give up
    3b. if that succeeded, send the HTTP request and read the response.

So this would imply that at stage 1 the DNS is not returning the IPv4 address or at stage 2 the IPv4 address is not being tried after the IPv6 address connect attempt fails.

My bet would be on 1: the IPv4 address is not being returned from your DNS, or is not being returned from the IP stack to the program via gethostbyname().

Gah! This doesn’t explain why the same requests on Windows 11 work. So I would lose that bet. So: the IPv4 address is likely getting returned, but no attempt to connect to it is made. Why not, if the decision is being made in the browser code? Can you try with another browser - Chrome or Chromium? Not that that is very satisfactory.

The burning questions still remains: why is the university website not using TLS (HTTPS)? And why is the server not listening on port 80?

As ever, Good Luck!

(fedoraproject/disqus/diatribe/whatever this forum software is called wouldn’t let me add a 3rd reply, but didn’t tell me that until I tried to post it, which I found a bit annoying - it could have let me know before I started scribbling.)

26

Thnaks so much for your help, @icantremember .
I have the output you requested:

$ curl http://www.ufrgs.br/ufrgs/inicial
curl: (6) Could not resolve host: www.ufrgs.br

$ curl http://[2804:1f20:0:1::20]/ufrgs/inicial
curl: (7) Failed to connect to 2804:1f20:0:1::20 port 80 after 11 ms: Network is unreachable

$ curl http://143.54.2.20/ufrgs/inicial
curl: (7) Failed to connect to 143.54.2.20 port 80 after 15531 ms: Network is unreachable

I have some more information. The login page, where you connect to the internet, when you are already connected, is:

https://prae-ceu.ufrgs.br:8005/

Once I clicked disconnect, I got redirected to:

https://prae-ceu.ufrgs.br:8005/index.php?zone=ceu_1030_ceu

Once I entered my login info and clicked connect, I got redirected again to:

https://prae-ceu.ufrgs.br:8005/index.php?zone=ceu_1030_ceu&redirurl=http%3A%2F%2Fwww.ufrgs.br%2Fufrgs%2Finicial

I tried entering those three URLs addresses in the Firefox, but none of them worked (Fedora KDE)

I also did some tests on Windows 11, disconnected (I mean, I havent loged in yet):

ping 2804:1f20:0:1::20

Pinging 2804:1f20:0:1::20 with 32 bytes of data:
Destination net unreachable.
Request timed out.
Destination net unreachable.
Request timed out.

Ping statistics for 2804:1f20:0:1::20:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


curl http://[2804:1f20:0:1::20]/ufrgs/inicial                                                         
curl: (28) Failed to connect to 2804:1f20:0:1::20 port 80 after 21029 ms: Timed out

I can reinstall Fedora or install Fedora Gnome if you want. I can do that tomorrow.
Remenbering, I can connect with every other distro out there, except Fedora KDE (I’m kinda sure I could connect with Fedora GNOME).

Just a bit of curiosity:
A few years ago I had a Playstation 4. I had to use the built-in internet browser to connect to the internet there. I typed ufrgs.br and most of the time my dorm log in page appered. Sometimes, that would not work and I could only login with Wi-Fi. One day, I couldn’t connect with wired at all. It has been three months since I last connected, so I decided to sell it. :frowning:

27

I can’t resolve prae-ceu.ufrgs.br either, which doesn’t surprise me: I imagine the university has a public portal and then internal-only subdomains for the students and faculty.

It really looks like a routing problem, but then why does it work from non-Fedora OSs? It’s maddening!

I was surprised that you couldn’t get to the IPv4 address. That’s the publicly-accessible IPv4 address for the main university website. So now it looks like you can’t get out to the public internet (routing/gateway issues?) to the main site, but you can’t get to the local subdomains either.

I don’t actually think that reinstalling Fedora will make a difference, unless it’s somehow a bad image, and then reinstalling the same one likely wouldn’t help.

I really think you have to talk to the local network admin to figure out what’s going on. You could always install Wireshark - it’s available in the Fedora distro - and capture what’s hitting the net when you try to visit the website. If packets are simply being ignored then it won’t help much. I don’t imagine you’re being flooded with bad packets, but you could be… (I’m reaching here!)

If you want to try the Wireshark route while you’re attempting to find someone local with knowledge of the network, me or others here could take a look and see if there’s anything obviously bad going on.

It’s pretty straightforward: just sudo dnf install wireshark then once it’s installed sudo wireshark (you need root privilege to access the packet filter driver) and choose the network interface you’re communicating on, then click on the shark fin icon and record everything until the request has succeeded or failed (probably quite quickly). It helps if you’re not doing anything else on the net in the interests of brevity and privacy, but modern computers are inveterate chatterboxes with all sorts of packets flying around. Then you just save the file locally and then stick it on the internet somewhere, but - d’oh! - you can’t get to the internet from that machine! (But it does seem like you can get to it via another route).

You can capture traffic for one machine/network adapter from another machine so long as it’s on the same ethernet segment. It’s a bit more tricky though.

28

Is this one of those schemes like you typically get in a coffee shop where you have to connect to a local service which then gives you access to the local addresses served by DHCP on the router? That could be another avenue of investigation, but again, what is unique about Fedora that’s causing it to behave differently if indeed this is a significant issue? There are no VPNs or IP tunneling as far as you’re aware?

What’s the output of resolvectl? You might have gone back to using 127.0.0.53 as your DNS server (after a reboot) which was originally part of the problem. In which case do the:

sudo unlink /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

again and do a

sudo systemctl restart systemd-resolved.service

for good measure.

29

check →
https://www.ufrgs.br/bibliotecas/pesquisa/proxy/#firefox

30

That could be significant! I was wondering (to myself) whether there were any pre-configured setups for e.g. Windows machines, but I was thinking more about Active Directory than proxies. Pre-configured setups that aren’t available to Fedora because it’s not a standard installation on campus.

31

So, I had some work that I needed to do in a Linux (Sockets UNIX), so I use USB tethering from my phone to bring internet to Fedora.
After that, I deleted all connection profiles (settings panel) and created a new one.

There is two files. before.pcapng and after.pcapng.
before.pcapng was made right after I created the new connection profile. The after.pcapng was created after I did the commands below:

$ sudo unlink /etc/resolv.conf
$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
$ sudo systemctl restart systemd-resolved.service

If you want to, you can send me a text so I can mail it to the IT department of my university. I’ll translate. I just can’t guarantee that they will answer. Tomorrow I will be physically there and the IT departament is right above where I attend my classes (Computer Science). I can ask them anything.

If you need more tests, let me know.

32

Unfortunately the pcap files are not downloadable from google docs. Can you make them publicly available? (The only ability is copying the file name)

33

Hmm, I opened the link on incognito tab and I downloaded them with no problem. (upper right button). Let me double check again.

Do you have another place where I can upload the files?

34

Ah, got it now thanks - not familiar with google docs.

35

I looked at both but I don’t see anything related to resolving host names or trying to connect to a TCP service, e.g. a web server.

The traces consist mainly of tons of SSDP (Simple Service Discovery Protocol) and ARP (Address Resolution Protocol) packets (plus a few MDNS - Multicast DNS - and LLMNR - Link Local Multicast Name Resolution - packets that are of no significance as far as I can tell).

Nothing for ufrgs.br or anything that comes out of a browser.

36

I wasn’t on the browser trying to reach any address. A did a new log now, where I have Chrome open trying to acess ufrgs.br, https://prae-ceu.ufrgs.br:8005 and some others related to the login page:

37

It looks like you have a configuration or policy problem. Basically, DNS requests are made to an IPv6 address that always returns request refused which apparently means that the DNS server refuses to resolve the hostname because of a security, policy or abuse issue (I’ve never seen this before - I had to google).

|428|7.470678179|fe80::db94:63c0:c5b9:e640|fe80::360a:33ff:feeb:cc7a|DNS|92|Standard query 0x29e1 AAAA www.ufrgs.br|
|429|7.470842290|fe80::db94:63c0:c5b9:e640|fe80::360a:33ff:feeb:cc7a|DNS|92|Standard query 0xa398 A www.ufrgs.br|
|430|7.478748248|fe80::360a:33ff:feeb:cc7a|fe80::db94:63c0:c5b9:e640|DNS|92|Standard query response 0x29e1 Refused AAAA www.ufrgs.br|
|431|7.479722153|fe80::360a:33ff:feeb:cc7a|fe80::db94:63c0:c5b9:e640|DNS|92|Standard query response 0xa398 Refused A www.ufrgs.br|

There are also DNS requests going to an IPv4 address but these are responded to with an ICMP destination unreachable (port unreachable) error.

|424|7.469817082|192.168.0.113|192.168.0.1|DNS|72|Standard query 0x29e1 AAAA www.ufrgs.br|
|425|7.469973396|192.168.0.113|192.168.0.1|DNS|72|Standard query 0xa398 A www.ufrgs.br|
|426|7.470409876|192.168.0.1|192.168.0.113|ICMP|100|Destination unreachable (Port unreachable)|
|427|7.470410150|192.168.0.1|192.168.0.113|ICMP|100|Destination unreachable (Port unreachable)|

So you can’t resolve names on the IPv6 interface because the server is refusing your requests for some reason, and you can’t resolve names on the IPv4 interface because the DNS server is apparently not configured on the router (even though presumably you’re being given the DNS address of 192.168.0.1)

Every DNS request in the trace is refused (or gets unreachable error) except for these MDNS requests:

1740	19.508046553	fe80::c650:c47e:ff6f:2534	ff02::fb	MDNS	92	Standard query 0x0000 ANY Pipita.local, "QM" question
1741	19.508408601	fe80::c650:c47e:ff6f:2534	ff02::fb	MDNS	226	Standard query response 0x0000 AAAA fd01::fac5:8ac9:4e58:f1c2 AAAA fd0b:d9d8:9e3d:0:5206:544f:13db:bee4 AAAA fd01::f91c:820a:447b:9bf8 AAAA fd0b:d9d8:9e3d:0:f91c:820a:447b:9bf8 AAAA fe80::c650:c47e:ff6f:2534
3376	36.219430765	143.54.169.124	224.0.0.251	MDNS	72	Standard query 0x0000 ANY Pipita.local, "QM" question
3384	36.220322768	143.54.169.124	224.0.0.251	MDNS	222	Standard query response 0x0000 AAAA fd01::fac5:8ac9:4e58:f1c2 AAAA fd0b:d9d8:9e3d:0:5206:544f:13db:bee4 AAAA fd01::f91c:820a:447b:9bf8 AAAA fd0b:d9d8:9e3d:0:f91c:820a:447b:9bf8 AAAA fe80::c650:c47e:ff6f:2534 A 143.54.169.124

No DNS requests work, no IP (v4 or v6) addresses are returned and no connections are attempted.

Even googleapis.com can’t be resolved!

|51|1.469945416|192.168.0.113|192.168.0.1|DNS|78|Standard query 0x9e23 A www.googleapis.com|
|52|1.469991726|192.168.0.113|192.168.0.1|DNS|78|Standard query 0x3bca AAAA www.googleapis.com|
|53|1.470480176|192.168.0.1|192.168.0.113|ICMP|106|Destination unreachable (Port unreachable)|
|54|1.470480239|192.168.0.1|192.168.0.113|ICMP|106|Destination unreachable (Port unreachable)|

Hope this helps!

38

I can’t make sense of this info, sorry. Network is my weak spot. :sweat_smile:
I can still try to ask the IT department something.

If we are out of ideias, I can install other distro. :smiling_face_with_tear:

39

You do need to discuss the problem with your IT support. In the meantime, you can still run Fedora in a VM.

40

You could try although I’m not sure why that would fix the problem. The immediate issue appears to be that the DNS server is denying your request. That implies some sort of access control is failing. What’s that access control? I don’t know but I’d hazard a guess that it’s a credentials check; the credentials are likely determined by your logging into the university system when you start your machine. The only information the DNS server has to go on is your IP address - IPv6 in this case - which either means you’re getting a pre-determined IP address (based on MAC address?) or there’s co-ordination with a DHCP server or other server that’s implementing the security aspect.

These requests aren’t failing for everyone else, obviously? And they’re not failing when you’re running Windows 11?

It’d be interesting to look at a packet trace of a working machine to compare against new.pcapng. I would think there’s another phase to setting up the interface that you’ve implied above regarding logging onto the university system but either which hasn’t been captured in the packet traces supplied so far, or I haven’t gleaned from all the ARP, SSDP, and MDNS traffic flying around. The SSDP packets just appear to be announcements or find requests, unanswered as far as I can tell; there are some UDP packets that are unrecognized but I’m guessing they’re insignificant, if only from their scarcity.

Mr. White is correct: you ideally need to get someone in your university who is familiar with the system on the case rather than the likes of me taking stabs in the dark as to what is or isn’t going on.

I’m very keen to know the answer however! Specifically, what is it about your Fedora installation that’s either surfacing or causing the problem, and why doesn’t anyone else see it. It’s evidently not what I originally thought - the nginx HTTP server not listening on port 80 on the IPv6 interface because you’re not even getting that far. IPv6 is implicated, but it really shouldn’t be in 2023.

Curiouser and curiouser, as Alice said (or Alias[InWendellLand] in this case)

41

You’re probably lucky, being at a university instead of a corporation. If it was the latter the IT bod would just tell you that anything not sanctified by them ist verboten! and to use the Windows system you were told to. I’d expect a university IT department to have more intellectual curiosity. Maybe they’ll write a paper? Or make you write it … :smiley: