Resolved: can't fetch mail



I don't see that I ever posted a follow-up, so better late than never. I boot my PC to command line, and eventually start X (KDE.) The network doesn't actually get set up until the KDE session takes care of it. However, lately, it seems it has been connecting to enp0s2 (which IS the persistent name of my ethernet card) but in that state, the network isn't actually connected to anything. I have to explicit tell the widget (network manager, I think) to connect to "Wired connection 1" instead. That fully brings up the network. Before I do that, attempting to fetch mail fails, as Balsa doesn't think the network is actually up. After that, fetching mail works fine. So - it's not a Balsa problem at all. What is odd is that once I connect to Wired connection 1, the other enp0s2 disappears from the list of available networks. Something funny within the network manager, I suppose.

On 2022.06.07 15:33, Jack via balsa-list wrote:
Well, temporarily resolved, though not actually solved. First, it took me two tries to realize that the g_network functions are in glib, not gtk, but I got it recompiled with debug info. Tracing through from balsa_window_init, I got totally lost in all the g_ functions, but at one point noticed (displaying local variables in the debugger) that there had been a g_network_changed signal, and the network now showed as available, and I successfully downloaded my approx 120 queued messages. Unless something in compiling with -ggdb also changed something else, and I can figure what it was, I might have to chalk this up to "phase of the moon and blue magic dust."

On 2022.06.07 14:06, Jack Ostroff via balsa-list wrote:
Good timing - I'm finally digging into this right now.  My smtp test send was through gmail, so not local.  I'm now compiling gtk with debug symbols to see if I can find why it might think the network is missing, or at least trace into those g_network calls. The "route" command DOES show a "default" route to my router, to which I have a wired connection.  I also do NOT see any network-changed messages.  "grep -i network" on the output gives me:

(process:8898): GLib-GIO-DEBUG: 17:43:34.475: Failed to initialize portal (GNetworkMonitorPortal) for gio-network-monitor: Not using portals (process:8898): GLib-GIO-DEBUG: 17:43:34.478: _g_io_module_get_default: Found default implementation networkmanager (GNetworkMonitorNM) for ?gio-network-monitor? (balsa:8879): GLib-GIO-DEBUG: 17:43:34.700: Failed to initialize portal (GNetworkMonitorPortal) for gio-network-monitor: Not using portals (balsa:8879): GLib-GIO-DEBUG: 17:43:34.702: _g_io_module_get_default: Found default implementation networkmanager (GNetworkMonitorNM) for ‘gio-network-monitor’ ** (balsa:8879): DEBUG: 17:43:34.702: Networkis unavailable (Sun 05 Jun 2022 05:43:34 PM EDT)

Of course I do not have an example from when it used to work just fine.  All I can assume now is that something else I upgraded early last week is causing a problem, but I won't be surprised if I'm surprised at how stupid the problem is, once I find it.

Update later today.

Jack

On 6/7/22 13:54, Albrecht Dreß via balsa-list wrote:
Hi Jack!

Am 05.06.22 23:54 schrieb(en) Jack Ostroff via balsa-list:
** (balsa:8879): DEBUG: 17:43:34.702: Networkis unavailable (Sun 05 Jun 2022 05:43:34 PM EDT)

That message is printed by function print_network_status() in src/main-window.c.  Balsa uses a GNetworkMonitor (returned by calling g_network_monitor_get_default()) to check if the network is available or not.  If you see this message only /once/, it is most like being emitted from balsa_window_init() (in the same source file) using the return value of calling g_network_monitor_get_network_available().  The docs say

<quote>
Checks if the network is available. "Available" here means that the system has a default route available for at least one of IPv4 or IPv6. It does not necessarily imply that the public Internet is reachable.
</quote>

We connect to the “network-changed” of the monitor, which should print a similar message whenever the network state changes.

but I have no idea if this really indicates some network problem or is just a red herring (false lead) as balsa is able to send messages by smtp.  Next step will be to debug and look for a backtrace from the place that message is printed.

In libbalsa/server.c (libbalsa_server_test_can_reach*) we have additional functions for checking if a remote server is reachable, which internally call g_network_monitor_can_reach_async() and g_network_monitor_can_reach_finish().  I can only guess that there /might/ be an issue with your network or the gio configuration. SMTP may work if you use a local MTA (localhost or 127.0.0.1) as that address should always be reachable.

Best, Albrecht.
_______________________________________________
balsa-list mailing list
balsa-list gnome org
https://mail.gnome.org/mailman/listinfo/balsa-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]