[Users] Claws Mail Can't Connect to Internet With Specific Internet Connection

Thu Oct 13 14:59:13 UTC 2022

Hello Dustin,

Waoh !!! Thanks so much for the detailed report, with all your findings !

Yes, V4 and V6 can cause what you have experienced. The exact reason is yet
to be understood, and some reasons could be:
 - system update (on your machine) that triggered some IPv6 autoconf and
   then your machines "thinks" it can use a broken IPv6,
or
 - IPv6 from your ISP was working perfectly but something went wrong, and
   because no one really cares, it is still broken now and you are affected,
or
 - someone changed some IPv6 filtering rules and only the ones (few
   apparently) using IPv6 are affected, no enough to ring a bell somewhere
   and have it fixed.

traceroute has an option (-4 or -6) to select which IP version you want the
traceroute to be done. telnet does too, and openssl (BTW, openssl is not
using telnet under the hood ;).
So, if you really want to go further, you can activate these options when
testing the LAN access. You should see a real difference, and that should
help highlight the problem.

As an example, from $HOME: 
269 [14:56] rol at riri:~> traceroute -4 cisco.com
traceroute to cisco.com (72.163.4.185), 30 hops max, 60 byte packets
 1  livebox.home (192.168.1.254)  0.317 ms  0.262 ms  0.272 ms
 2  80.10.253.25 (80.10.253.25)  2.261 ms  2.199 ms  2.463 ms
 3  * * *
 4  ae77-0.ncidf103.rbci.orange.net (80.10.45.250)  2.873 ms  2.902 ms  2.901 ms
 5  ae41-0.niidf101.rbci.orange.net (193.252.159.42)  2.924 ms  2.923 ms  2.901 ms
 6  193.252.137.10 (193.252.137.10)  13.892 ms  10.737 ms  10.608 ms
 7  ae-a5.edge7.Paris1.Level3.net (4.68.127.233)  17.044 ms  11.024 ms  10.931 ms
 8  ae4.15.edge5.Dallas3.level3.net (4.69.208.233)  133.954 ms  133.942 ms ae3.5.edge5.Dallas3.level3.net (4.69.208.229)  114.599 ms
.....

270 [14:56] rol at riri:~> traceroute -6 cisco.com
traceroute to cisco.com (2001:420:1101:1::185), 30 hops max, 80 byte packets
 1  livebox.home (2a01:cb00:f83:9900:b6a5:efff:fed3:100e)  2.328 ms  2.033 ms  1.992 ms
 2  2a01cb08a00402000193025300770168.ipv6.abo.wanadoo.fr (2a01:cb08:a004:200:193:253:77:168)  15.731 ms  15.730 ms  15.662 ms
 3  2a01:cfc4::b (2a01:cfc4::b)  15.763 ms  15.647 ms  15.536 ms
 4  * * *
 5  xe-9-1-1.edge3.Amsterdam1.Level3.net (2001:1900:5:3::205)  20.158 ms  20.137 ms  20.130 ms
 6  lo0.0.edge5.Dallas3.level3.net (2001:1900::3:135)  115.093 ms  114.502 ms  114.508 ms

As you can see, one is showing IPv4 addresses when the other is using IPv6
addresses and one is indicating a path via Amsterdam when the other doesn't
(though this is _only_ an _indication_ based on rDNS, so nothing really
reliable).

Paul

On Thu, 13 Oct 2022 20:01:06 +0600
Dustin Miller <dustbiz at gmail.com> wrote:

> On Tue, 11 Oct 2022 19:38:18 +0600
> Dustin Miller <dustbiz at gmail.com> wrote:
> 
> > Claws Mail (CM) 4.1.0 on Linux Mint 20.1
> > 
> > My system has access to two different internet connections:
> >   
> 'LAN': Via LAN cable to a local network that has internet access.
> 
> 'USB: Via a USB dongle wireless device using a SIM card to connect with
> a mobile network.
> 
> CM could not access the internet via LAN for sending / receiving email,
> even though other apps and the system could access it.
> 
> When I disabled LAN and connected USB, then CM and everything else could
> access the internet as expected.
> 
> I used the tools telnet, openssl, traceroute, dig, and nmap on each of
> the connections to note any differences in results. From what I could
> tell, the traceroute, dig, and nmap results didn't show any relevant
> differences and didn't include any warnings or errors. However, both
> telnet and openssl (maybe it uses telnet?) seemed to give successful
> results on USB but not on LAN.
> 
> The only difference I noticed is that on USB these two tools defaulted
> to using IPv4 for address resolution, but on LAN they defaulted to using
> IPv6, and then just stalled at trying to access the host. If I forced
> them to use IPv4 on LAN, then I got the same results as with USB. Based
> on the above, as well as the fact that this CM instance was built with
> IPv6 enabled, my hypothesis was that the issue with CM was the same as
> with these two tools.
> 
> I noted that CM can be configured to build with IPv6 disabled, but I
> wanted to find an easier, less 'permanent' approach to 'forcing' IPv4
> for testing purposes. What I settled on was editing the '/etc/gai.conf'
> file so that there would be a (presumably) system-wide preference for
> using IPv4 rather than IPv6. This solved the problems with the telnet
> and openssl testing commands. It also has solved the CM problem,
> although I needed to restart CM for it to take effect.
> 
> With my limited understanding of these things, my sense is that
> preferring IPv4 to IPv6 is not the ideal long-term solution since IPv6
> is 'the future', but that using a preference setting like this is
> better than disabling IPv6 altogether. I am also not sure of the cause
> of this issue -- perhaps caused by an update to my system, or a change
> in settings on the local network device(s) or the ISP's equipment? At
> this point, I'm also not sure if/when this solution / workaround
> may/will cause an issue with one or more other apps.
> 
> I would guess that this is not a 'proper' CM bug, although if someone
> thinks it smells like one, I'm happy to do some specific testing. I am
> wondering though whether it might not warrant me filing an enhancement
> request on the bug tracker. The basic idea I have in mind is that when
> CM is trying to use IPv6 and it is not successful for whatever reason,
> then instead of just stalling and timing out, it would switch to trying
> to use IPv4 before then going on to time out if that isn't successful
> either. I'm not sure how difficult that would be to implement or if
> there's another better way to approach the issue, but if any developers
> think this sounds like a reasonable enhancement request, I'm happy to go
> ahead and file it.
> 
> I also welcome any input from anyone who thinks I may be missing
> something in regards to this issue, or has any other relevant comments
> or questions to add.
> 
> And again, thanks to each of you who took the time to help me learn
> more about troubleshooting network / routing issues.
> 
> Cheers,
> Dustin
> _______________________________________________
> Users mailing list
> Users at lists.claws-mail.org
> https://lists.claws-mail.org/cgi-bin/mailman/listinfo/users

-- 
Paul Rolland                                E-Mail : rol(at)witbe.net
CTO - Witbe.net SA                          Tel. +33 (0)1 47 67 77 77
18 Rue d'Arras, Bat. A11                    Fax. +33 (0)1 47 67 77 99
F-92000 Nanterre                            RIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it" 

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20221013/95848d89/attachment.sig>