I am running Leap 42.2 with KDE. My email client works cleanly after a fresh boot. The incoming server is set to imap.cox.net and the outgoing server is set to smtp.cox.net. After returning from suspend the imap server still works normally but the smtp server won’t accept outgoing mail. I receive an error message “An error occurred while sending mail: The mail server sent an incorrect greeting: eastrmimpo109.cox.net cox connection refused from xxx.254.255.154.” Almost certainly an authentication issue.
Just logging out and logging back in doesn’t fix the problem. The computer requires a complete reboot to fix the issue.
Any suggestions on how to track this down would be appreciated.
It rejects you before any authentication takes place, more like your computer does not obtain valid IP address after resume. The IP you “helpfully” truncated looks suspiciously similar to IPv4 atuo-IP 169.254.0.0/16.
Just logging out and logging back in doesn’t fix the problem. The computer requires a complete reboot to fix the issue.
Which confirms hypothesis that it is network configuration. Show output of “ip a” and “ip r” before and after resume.
There is more than one attempt to assist in this thread and these are the answers to the various questions. I have used 3 different email clients attempting to track down this problem. I normally use SeaMonkey Mail but I have also tried Trojita and Zimbra Desktop. They all produce the same error message. The error message comes before authentication and the login so I suspect an authentication issue.
Cox has superb technical support but I know from past experience they don’t support Linux. I searched their forums for a clue but didn’t bother contacting support.
I was out of ideas to try when I posted the original message but I also use the Torguard VPN client. Even though the Internet access works cleanly after resume I decided to disconnect the VPN client before entering suspend. I manually restart the VPN client after resume and the email service so far has worked correctly with this procedure. I think my next step needs to be to contact Torguard support.
So, it’s your VPN that breaks following a suspend/resume cycle (and that is to be expected). You should have mentioned this in your opening post, and posting the ‘ip a’ and ‘ip r’ output before and after suspending as requested would have helped us identify this issue too.
kim@linux-um77:~> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:97:5a:90:4a:0b brd ff:ff:ff:ff:ff:ff
inet 192.168.1.235/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::ba97:5aff:fe90:4a0b/64 scope link
valid_lft forever preferred_lft forever
3: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.221.1/24 brd 192.168.221.255 scope global vmnet1
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fec0:1/64 scope link
valid_lft forever preferred_lft forever
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.94.1/24 brd 192.168.94.255 scope global vmnet8
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fec0:8/64 scope link
valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 48000 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.35.0.54 peer 10.35.0.53/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fd00:1234::1/64 scope global
valid_lft forever preferred_lft forever
ip r before suspend
kim@linux-um77:~> ip r
0.0.0.0/1 via 10.35.0.53 dev tun0
default via 192.168.1.1 dev eth0 proto dhcp
10.35.0.1 via 10.35.0.53 dev tun0
10.35.0.53 dev tun0 proto kernel scope link src 10.35.0.54
96.44.145.130 via 192.168.1.1 dev eth0
128.0.0.0/1 via 10.35.0.53 dev tun0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.235
192.168.94.0/24 dev vmnet8 proto kernel scope link src 192.168.94.1
192.168.221.0/24 dev vmnet1 proto kernel scope link src 192.168.221.1
ip a after resume
kim@linux-um77:~> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:97:5a:90:4a:0b brd ff:ff:ff:ff:ff:ff
inet 192.168.1.236/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::ba97:5aff:fe90:4a0b/64 scope link
valid_lft forever preferred_lft forever
3: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.221.1/24 brd 192.168.221.255 scope global vmnet1
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fec0:1/64 scope link
valid_lft forever preferred_lft forever
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.94.1/24 brd 192.168.94.255 scope global vmnet8
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fec0:8/64 scope link
valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 48000 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.35.0.6 peer 10.35.0.5/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fd00:1234::1/64 scope global
valid_lft forever preferred_lft forever
ip r after resume
kim@linux-um77:~> ip r
0.0.0.0/1 via 10.35.0.5 dev tun0
default via 192.168.1.1 dev eth0 proto dhcp
10.35.0.1 via 10.35.0.5 dev tun0
10.35.0.5 dev tun0 proto kernel scope link src 10.35.0.6
128.0.0.0/1 via 10.35.0.5 dev tun0
173.254.254.114 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.236
192.168.94.0/24 dev vmnet8 proto kernel scope link src 192.168.94.1
192.168.221.0/24 dev vmnet1 proto kernel scope link src 192.168.221.1
After additional testing the VPN client doesn’t seem to be the problem. Some changes in ip r. The route changes but I don’t see any other difference.
Still get the error “An error occurred while sending mail: The mail server sent an incorrect greeting: eastrmimpo209.cox.net cox connection refused from 173.254.254.114.”.