email client problems on wake from suspend

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.

Which email client are you using?

FWIW, I note that your service provider has a help forum…
http://forums.cox.com/forum_home/internet_forum/f/5.aspx

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.

Thanks to everyone who tried to help.

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.

ip a before suspend


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.”.