VPN issues about mop HOT 15 CLOSED

Unfortunately, latest iteration functions perfectly on my system.
That said I am not going to dismiss this issue.

from mop.

Thanks! It's just such a strange issue that I'd like to rule out that it's something I somehow done myself may be even on the OS level...

Will try to investigate it a bit in the coming days, hopefully on some other platforms. Right now, only have an older Ubuntu 21.10 nearby, where it behaves the same, but since it also was my own laptop, and the software / settings are pretty much the same, it doesn't say much :)

from mop.

At a glance, mop starts a routine for retrieving quotes, but when OP vpn is blocking query1.finance.yahoo.com, mop's quote fetch call waits until it times out. The main loop (in main.go) spins without any throttling. "go quotes.Fetch()" runs in the background here:

	case <-quotesQueue.C:
		if !showingHelp && !paused && len(keyboardQueue) == 0 {
			go quotes.Fetch()
			redrawQuotesFlag = true
		}

but if you follow the redrawQuotesFlag around, you'll get to layout.go where you see:

	if ok, err := quotes.Ok(); !ok { // If there was an error fetching stock quotes...
		return err // then simply return the error string.
	}

... which is a blocking call and eventually returns the Client.Timeout error you were seeing.

mop needs better error handling / reporting all around to surface these problems better.

To solve, it probably needs a channel to signal completion of the fetch call, e.g.

done := make(chan bool)
go func() {
    quotes.Fetch()
    done <- true
}()

and in layout:

select {
case <-done:
    if ok, err := quotes.Ok(); !ok {
        return err
    }
default:
    // no quotes yet, do something else
}

I'm not in front of a code editor so that's just a guess.

from mop.

Indeed, my production machine has Windows 11.

from mop.

Tried this with my VPN (NordVPN) with a couple different countries on / off, no repro yet, sorry. I'll keep looking.

from mop.

Quite strange indeed!
Cordially speaking, if you are able to investigate and submit a patch, I would be very happy to merge.
Otherwise, we are at mercy of a more knowledgeable go developer.

from mop.

@brandleesee,

Unfortunately, I'm not even a programmer, leave alone knowing Go :)

But just in case, you did test this, too? Can confirm?

from mop.

@spudone thanks for the comprehensive explanation
if you are willing to submit a patch - whenever you are comfortable - pls do

from mop.

@spudone

Thanks, that's interesting!

But when you say

OP vpn is blocking query1.finance.yahoo.com

...it actually isn't, though, is it? I mean:

• After I stop the VPN connection, every other piece of software continues to work as expected, and I can use curl (with a cookie and a crumb), for instance, to manually request query1.finance.yahoo.com just fine.
• And it happens only on disconnecting VPN, never on connecting, which in terms of the alleged blocking should be the same?

Another interesting thing is that mop indeed seems not to experience this issue on Windows (@brandleesee, do you use Windows by any chance?)

On the other hand, I was able to reproduce it with Ubuntu 16.04 on some old 32bit laptop and also with the latest Debian in VirtualBox. Unfortunately, the MacBook I have is too old, and mop's macOS build (even adjusted with MACOSX_DEPLOYMENT_TARGET and -mmacosx-version-min) simply fails to launch there :)

So, because of those differences, maybe, it's not even mop's problem but some upstream library's, what do you think?

(Just for the record, it's easy to observe the "freeze" if the clock is on in mop: after some 5 seconds after disconnecting the VPN, it just stops updating, just as it stops responding to the hotkeys or updating the data -- and stays like that for some 15 minutes more or less.)

from mop.

The freeze behavior is why I went looking for a blocking call. Sorry if I misunderstood the OP. I thought "blacklisting" meant those hosts were unreachable. But the quotes call is still relevant - and I think that's the place causing the interface to freeze.

Even if the finance host is reachable, the http client call may still get tied up for other reasons. With a VPN, you get into the possibility of a different DNS server. The http client in mop might have the old one cached and then fail if the VPN change (on or off) makes it unreachable. I'd have to dig around and I'm not sure if I have a clean repro.

As I think about it more, the DNS seems likely. Consider:

1. Start with VPN off. You're connecting with your normal DNS. No issues.
2. Turn VPN on. The VPN is probably now switching you over to its own private DNS. But that's fine because you're connected. Everything is still good.
3. Turn VPN back off. If the private DNS is cached in mop (or elsewhere), it will now be unreachable and you'll see the problem.

from mop.

@spudone

Thanks a lot! I do suspect this is something on my side, yes... Partly because this is such a weird issue :)

Just for the record, what is your OS?

from mop.

Linux (KUbuntu LTS). I have a Windows 11 machine available but haven't tried it yet.

By the way, I have seen occasional issues with VPNs getting an http 429 response (Too many requests), but that will result in a different error.

from mop.

Thanks again, @spudone!

Don't know, maybe we should close this until a repro is available :)

from mop.

I am closing this since it cannot be reproduced while its general direction seems more inclined towards the VPN/OS.
With that said, please continue discussions on this thread especially if further investigations point it towards mop.
And should an alteration in the code be deemed necessary, I am open to consider itl.

from mop.

Something that has come to mind is that in Windows 11, I use cmd to run mop. I believe this can also be achieved using powershell but, please, do not quote me on that.

My argument is that maybe the app used on Linux/Ubuntu could possibly also be worth consideration or investigation. I am aware of the terminal emulators that come packaged on installing the operating system (such as xterm) and others installed afterwards (like tilix etc).

Just putting this idea here should it be a worthwhile ally to pursue.

from mop.