Weird behavior while connected to wifi captive portals

ANormalLadd · 2025-05-02 06:24:59

So I was in my college connected to the wifi which uses Cisco captive portals. This system tends to have a bad habit of forgetting you accepted the terms and conditions of connecting to the wifi and requiring you to accept again.
This happened while I was running

pacman -Syy

after updating my mirrorlist.
I then ran

pacman -Syu

which resulted in a

error: could not open file /var/lib/pacman/sync/core.db: Unrecognized archive format

Checking the contents of core.db revealed that pacman just straight up overwrote core.db (along side my other repos extra, multilib, etc) with the html of the captive portal page.

This seems like really weird behavior and I'm not sure if this is a pacman issue or a network issue on my college's behalf. I'd think pacman would confirm that what the mirror is responding with is actually valid. It could be a case of the college network responding with the captive portal intermittently.

LMK what y'all think

Cheers

Last edited by ANormalLadd (2025-05-02 06:29:10)

seth · 2025-05-02 16:20:52

I'd think pacman would confirm that what I'd think pacman would confirm that what

"man pacman", what does the second "y" actually do?
Still surprised?
So why are you adding it there?

Trilby · 2025-05-02 16:29:09

While using a double -y flag is most likely useless, and not a great idea, it's really not relevant to the question at hand. Using it twice does not make pacman any more likely to overwrite the dbs with captive portal nonsense than it would otherwise. The double -y only means pacman doesn't use the modification date in deciding whether or not to download a fresh copy.

It could be a worthwhile feature for pacman to confirm it's getting a db before overwriting the old one - but it's arguably not worth it. This is not critical data: if you get a bad db file, it will not be used - as can be seen by the quoted error message. It's also easy to fix on the next sync after your network connection is sorted.

So sort out your connection, then resync - and this is one time where using two -y's is appropriate. But there's also generally no reason to split it from the update (and some risks to splitting). So fix your network, then just `pacman -Syyu`.

seth · 2025-05-02 17:11:39

Depends on how those portals respond to the curl time restriction (never had the pleasure), but they may very well just ignore it and be "now" all the time.

You can automatize this by "file -b --mime-type /var/lib/pacman/sync/core.db" and if that's not "application/gzip" warn yourself and schedule a -Syyu (which is now actually required)

ANormalLadd · 2025-05-02 18:59:43

seth wrote:

I'd think pacman would confirm that what I'd think pacman would confirm that what
"man pacman", what does the second "y" actually do?
Still surprised?
So why are you adding it there?

I was checking which mirror actually fetched the quickest so I was forcibly syncing my repos when trying different mirrors.

I was more curious about pacman writing what ever response it got into the db files.

Trilby wrote:

It could be a worthwhile feature for pacman to confirm it's getting a db before overwriting the old one - but it's arguably not worth it. This is not critical data: if you get a bad db file, it will not be used - as can be seen by the quoted error message. It's also easy to fix on the next sync after your network connection is sorted.

This was exactly what I was wondering about. It obviously doesn't really matter, I knew what the issue was and it's quite simple to just accept the captive portal and resync my repos. I just thought it's a little interesting how pacman handled receiving new repo db's.

Cheers

Last edited by ANormalLadd (2025-05-02 19:00:18)

Arch Linux

#1 2025-05-02 06:24:59

Weird behavior while connected to wifi captive portals

#2 2025-05-02 16:20:52

Re: Weird behavior while connected to wifi captive portals

#3 2025-05-02 16:29:09

Re: Weird behavior while connected to wifi captive portals

#4 2025-05-02 17:11:39

Re: Weird behavior while connected to wifi captive portals

#5 2025-05-02 18:59:43

Re: Weird behavior while connected to wifi captive portals

Board footer