Resolved: can't fetch mail

[Jack <ostroffjh users sourceforge net>]

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