Description of problem: Wired connections do not re-establish after connecting then disconnecting from a VPN. Version-Release number of selected component (if applicable): [root@hp6930p ~]# rpm -qa | grep NetworkManager NetworkManager-glib-0.8.9997-6.git20110721.fc15.x86_64 NetworkManager-vpnc-0.8.999-3.git20110721.fc15.x86_64 NetworkManager-glib-devel-0.8.9997-6.git20110721.fc15.x86_64 evolution-NetworkManager-3.0.2-3.fc15.x86_64 NetworkManager-openswan-0.8.999-2.git20110721.fc15.x86_64 NetworkManager-devel-0.8.9997-6.git20110721.fc15.x86_64 NetworkManager-openconnect-0.8.999-1.fc15.x86_64 NetworkManager-openvpn-0.8.9997-2.git20110721.fc15.x86_64 NetworkManager-gnome-0.8.9997-6.git20110721.fc15.x86_64 NetworkManager-glib-0.8.9997-6.git20110721.fc15.i686 NetworkManager-pptp-0.8.999-2.git20110721.fc15.x86_64 NetworkManager-0.8.9997-6.git20110721.fc15.x86_64 Linux hp6930p 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Always Steps to Reproduce: 1. Connect to eth0 or wired network with internet connectivity 2. Connect to VPN via NM (Cisco UDP VPN) 3. Disconnect from VPN Actual results: You cannot ping either the site's IP or URL; tried if(down|up); service network restart; nothing but a reboot appears to bring the wired network back. This is not a problem when on a wireless network, you can get back just fine from the Cisco UDP VPN connection. Expected results: Additional info: Logs to follow
CONNECTING TO VPN: Aug 15 06:50:09 hp6930p NetworkManager[973]: <info> Starting VPN service 'vpnc'... Aug 15 06:50:09 hp6930p NetworkManager[973]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 2710 Aug 15 06:50:09 hp6930p kernel: [ 1185.369743] tun: Universal TUN/TAP device driver, 1.6 Aug 15 06:50:09 hp6930p kernel: [ 1185.369750] tun: (C) 1999-2004 Max Krasnyansky <maxk> Aug 15 06:50:09 hp6930p NetworkManager[973]: <info> VPN service 'vpnc' appeared; activating connections Aug 15 06:50:09 hp6930p NetworkManager[973]: <info> VPN plugin state changed: 3 Aug 15 06:50:09 hp6930p NetworkManager[973]: <info> VPN connection 'AWIPS' (Connect) reply received. Aug 15 06:50:09 hp6930p lldpad[1297]: evb_ifdown:port tun0 remove failed Aug 15 06:50:09 hp6930p lldpad[1297]: vdp_ifdown:tun0 vdp data remove failed Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> VPN connection 'AWIPS' (IP Config Get) reply received. Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> VPN Gateway: 205.156.52.253 Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Tunnel Device: tun0 Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Internal IP4 Address: 165.92.17.168 Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Internal IP4 Prefix: 25 Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Internal IP4 Point-to-Point Address: 165.92.17.168 Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Maximum Segment Size (MSS): 0 Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Forbid Default Route: no Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Internal IP4 DNS: 140.90.148.33 Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Internal IP4 DNS: 140.90.143.33 Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> DNS Domain: 'noaa.gov' Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> Login Banner: Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> ----------------------------------------- Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> *** WARNING ** WARNING ** WARNING ***#015#012YOU HAVE ACCESSED A UNITED STATES GOVERNMENT HOST. USE OF THIS HOST WITHOUT AUTHORIZATION OR FOR PURPOSES FOR WHICH AUTHORIZATION HAS NOT BEEN EXTENDED IS A VIOLATION OF FEDERAL LAW AND CAN BE PUNISHED WITH FINES OR IMPRISONMENT (PUBLIC LAW 99-474)#015#012*** WARNING ** WARNING ** WARNING *** Aug 15 06:50:10 hp6930p NetworkManager[973]: <info> ----------------------------------------- Aug 15 06:50:10 hp6930p vpnc[2712]: can't open pidfile /var/run/vpnc/pid for writing Aug 15 06:50:11 hp6930p NetworkManager[973]: <info> VPN connection 'AWIPS' (IP Config Get) complete. Aug 15 06:50:11 hp6930p NetworkManager[973]: <info> Policy set 'AWIPS' (tun0) as default for IPv4 routing and DNS. Aug 15 06:50:11 hp6930p NetworkManager[973]: <info> VPN plugin state changed: 4 Aug 15 06:50:11 hp6930p dbus: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Aug 15 06:50:11 hp6930p dbus: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Aug 15 06:50:12 hp6930p ntpd[957]: Listen normally on 6 tun0 165.92.17.168 UDP 123 Aug 15 06:50:12 hp6930p ntpd[957]: 199.4.29.166 interface 10.201.6.61 -> 165.92.17.168 Aug 15 06:50:12 hp6930p ntpd[957]: 173.8.198.243 interface 10.201.6.61 -> 165.92.17.168 Aug 15 06:50:12 hp6930p ntpd[957]: 74.118.152.85 interface 10.201.6.61 -> 165.92.17.168 Aug 15 06:50:12 hp6930p ntpd[957]: 69.50.219.51 interface 10.201.6.61 -> 165.92.17.168 Aug 15 06:50:12 hp6930p ntpd[957]: peers refreshed Aug 15 06:50:13 hp6930p ntpd[957]: 0.0.0.0 0618 08 no_sys_peer DISCONNECTIN FROM VPN: Aug 15 06:50:43 hp6930p vpnc[2712]: select: Interrupted system call Aug 15 06:50:43 hp6930p vpnc[2712]: terminated by signal: 15 Aug 15 06:50:43 hp6930p avahi-daemon[967]: Withdrawing workstation service for tun0. Aug 15 06:50:43 hp6930p lldpad[1297]: evb_ifdown:port tun0 remove failed Aug 15 06:50:43 hp6930p lldpad[1297]: vdp_ifdown:tun0 vdp data remove failed Aug 15 06:50:43 hp6930p lldpad[1297]: evb_ifdown:port tun0 remove failed Aug 15 06:50:43 hp6930p lldpad[1297]: vdp_ifdown:tun0 vdp data remove failed Aug 15 06:50:44 hp6930p NetworkManager[973]: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS. Aug 15 06:50:44 hp6930p dbus: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Aug 15 06:50:44 hp6930p dbus: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Aug 15 06:50:44 hp6930p ntpd[957]: Deleting interface #6 tun0, 165.92.17.168#123, interface stats: received=0, sent=4, dropped=0, active_time=32 secs Aug 15 06:50:44 hp6930p ntpd[957]: 69.50.219.51 interface 165.92.17.168 -> (none) Aug 15 06:50:44 hp6930p ntpd[957]: 74.118.152.85 interface 165.92.17.168 -> (none) Aug 15 06:50:44 hp6930p ntpd[957]: 173.8.198.243 interface 165.92.17.168 -> (none) Aug 15 06:50:44 hp6930p ntpd[957]: 199.4.29.166 interface 165.92.17.168 -> (none) Aug 15 06:50:44 hp6930p ntpd[957]: peers refreshed Aug 15 06:50:50 hp6930p NetworkManager[973]: <info> VPN service 'vpnc' disappeared
HERE IS THE LOG FOR A WIRELESS CONNECTION: You can see NM does reconnect Aug 12 18:08:51 hp6930p NetworkManager[1011]: <info> DNS Domain: 'noaa.gov' Aug 12 18:08:51 hp6930p NetworkManager[1011]: <info> Login Banner: Aug 12 18:08:51 hp6930p NetworkManager[1011]: <info> ----------------------------------------- Aug 12 18:08:51 hp6930p NetworkManager[1011]: <info> *** WARNING ** WARNING ** WARNING ***#015#012YOU HAVE ACCESSED A UNITED STATES GOVERNMENT HOST. USE OF THIS HOST WITHOUT AUTHORIZATION OR FOR PURPOSES FOR WHICH AUTHORIZATION HAS NOT BEEN EXTENDED IS A VIOLATION OF FEDERAL LAW AND CAN BE PUNISHED WITH FINES OR IMPRISONMENT (PUBLIC LAW 99-474)#015#012*** WARNING ** WARNING ** WARNING *** Aug 12 18:08:51 hp6930p NetworkManager[1011]: <info> ----------------------------------------- Aug 12 18:08:51 hp6930p vpnc[15169]: can't open pidfile /var/run/vpnc/pid for writing Aug 12 18:08:52 hp6930p NetworkManager[1011]: <info> VPN connection 'AWIPS' (IP Config Get) complete. Aug 12 18:08:52 hp6930p NetworkManager[1011]: <info> Policy set 'AWIPS' (tun0) as default for IPv4 routing and DNS. Aug 12 18:08:52 hp6930p NetworkManager[1011]: <info> VPN plugin state changed: 4 Aug 12 18:08:52 hp6930p dbus: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Aug 12 18:08:52 hp6930p dbus: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Aug 12 18:08:52 hp6930p ntpd[1012]: Listen normally on 19 tun0 165.92.17.168 UDP 123 Aug 12 18:08:52 hp6930p ntpd[1012]: 149.20.68.17 interface 192.168.1.22 -> 165.92.17.168 Aug 12 18:08:52 hp6930p ntpd[1012]: 69.164.206.65 interface 192.168.1.22 -> 165.92.17.168 Aug 12 18:08:52 hp6930p ntpd[1012]: 64.73.32.134 interface 192.168.1.22 -> 165.92.17.168 Aug 12 18:08:52 hp6930p ntpd[1012]: 216.129.110.22 interface 192.168.1.22 -> 165.92.17.168 Aug 12 18:08:52 hp6930p ntpd[1012]: peers refreshed Aug 12 18:14:08 hp6930p vpnc[15169]: select: Interrupted system call Aug 12 18:14:08 hp6930p vpnc[15169]: terminated by signal: 15 Aug 12 18:14:08 hp6930p avahi-daemon[1022]: Withdrawing workstation service for tun0. Aug 12 18:14:08 hp6930p lldpad[1353]: evb_ifdown:port tun0 remove failed Aug 12 18:14:08 hp6930p lldpad[1353]: vdp_ifdown:tun0 vdp data remove failed Aug 12 18:14:08 hp6930p lldpad[1353]: evb_ifdown:port tun0 remove failed Aug 12 18:14:08 hp6930p lldpad[1353]: vdp_ifdown:tun0 vdp data remove failed Aug 12 18:14:09 hp6930p NetworkManager[1011]: <info> Policy set 'Auto slashdot2' (wlan0) as default for IPv4 routing and DNS. Aug 12 18:14:09 hp6930p dbus: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Aug 12 18:14:09 hp6930p dbus: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Aug 12 18:14:10 hp6930p ntpd[1012]: Deleting interface #19 tun0, 165.92.17.168#123, interface stats: received=0, sent=12, dropped=0, active_time=318 secs Aug 12 18:14:10 hp6930p ntpd[1012]: 216.129.110.22 interface 165.92.17.168 -> (none) Aug 12 18:14:10 hp6930p ntpd[1012]: 64.73.32.134 interface 165.92.17.168 -> (none) Aug 12 18:14:10 hp6930p ntpd[1012]: 69.164.206.65 interface 165.92.17.168 -> (none)
FYI ... used the older kernel and it works, disconnecting from VPN reconnects to eth0: Linux hp6930p 2.6.38.8-35.fc15.x86_64 #1 SMP Wed Jul 6 13:58:54 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Aug 15 07:09:04 hp6930p vpnc[2663]: can't open pidfile /var/run/vpnc/pid for writing Aug 15 07:09:05 hp6930p NetworkManager[995]: <info> VPN connection 'AWIPS' (IP Config Get) complete. Aug 15 07:09:05 hp6930p NetworkManager[995]: <info> Policy set 'AWIPS' (tun0) as default for IPv4 routing and DNS. Aug 15 07:09:05 hp6930p NetworkManager[995]: <info> VPN plugin state changed: 4 Aug 15 07:09:05 hp6930p dbus: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Aug 15 07:09:05 hp6930p dbus: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Aug 15 07:09:06 hp6930p ntpd[978]: Listen normally on 6 tun0 165.92.17.168 UDP 123 Aug 15 07:09:06 hp6930p ntpd[978]: 216.144.229.211 interface 10.201.6.61 -> 165.92.17.168 Aug 15 07:09:06 hp6930p ntpd[978]: 38.117.195.101 interface 10.201.6.61 -> 165.92.17.168 Aug 15 07:09:06 hp6930p ntpd[978]: 204.235.61.9 interface 10.201.6.61 -> 165.92.17.168 Aug 15 07:09:06 hp6930p ntpd[978]: 69.36.227.90 interface 10.201.6.61 -> 165.92.17.168 Aug 15 07:09:06 hp6930p ntpd[978]: peers refreshed Aug 15 07:09:07 hp6930p ntpd[978]: 0.0.0.0 c628 08 no_sys_peer Aug 15 07:09:24 hp6930p vpnc[2663]: select: Interrupted system call Aug 15 07:09:24 hp6930p vpnc[2663]: terminated by signal: 15 Aug 15 07:09:24 hp6930p lldpad[1357]: evb_ifdown:port tun0 remove failed Aug 15 07:09:24 hp6930p lldpad[1357]: vdp_ifdown:tun0 vdp data remove failed Aug 15 07:09:24 hp6930p avahi-daemon[988]: Withdrawing workstation service for tun0. Aug 15 07:09:24 hp6930p lldpad[1357]: evb_ifdown:port tun0 remove failed Aug 15 07:09:24 hp6930p lldpad[1357]: vdp_ifdown:tun0 vdp data remove failed Aug 15 07:09:25 hp6930p NetworkManager[995]: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS. Aug 15 07:09:25 hp6930p dbus: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Aug 15 07:09:25 hp6930p dbus: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Aug 15 07:09:25 hp6930p ntpd[978]: Deleting interface #6 tun0, 165.92.17.168#123, interface stats: received=0, sent=4, dropped=0, active_time=19 secs Aug 15 07:09:25 hp6930p ntpd[978]: 69.36.227.90 interface 165.92.17.168 -> (none) Aug 15 07:09:25 hp6930p ntpd[978]: 204.235.61.9 interface 165.92.17.168 -> (none) Aug 15 07:09:25 hp6930p ntpd[978]: 38.117.195.101 interface 165.92.17.168 -> (none) Aug 15 07:09:25 hp6930p ntpd[978]: 216.144.229.211 interface 165.92.17.168 -> (none) Aug 15 07:09:25 hp6930p ntpd[978]: peers refreshed Aug 15 07:09:30 hp6930p NetworkManager[995]: <info> VPN service 'vpnc' disappeared ^C
Just to clarify since I posted a lot of logs which I probably should've uploaded as attachments: [1] Connect to eth0/wired network [2] Connect to VPN (Cisco UDP) [3] Disconnect from VPN You cannot connect back to the wired connection. There may be a workaround but I tried NM restart, network restart, llpad restart and while they all show a connection on eth0 valid, I cannot ping the IPADDR assigned to me, nor outside addresses. This was on kernel 2.6.40-4.fc15.x86_64, when I used the older kernel, 2.6.38.8-35 I was able to reconnect just fine.
Any updates on this, no 2.6.40 kernel seems to allow a reconnect to the eth0 interface. Only the 2.6.38 and downstream kernels work, anything upstream of that fails to allow a reconnect to eth0 after disconnect from the VPN.
I had a 2.6.40-3 and not only did it not work after a wired connection, but also wireless connection. I guess this one updated because I was using 2.6.38 after editing my grub.conf knowing about this bug Aug 24 07:43:52 raykj kernel: [ 0.000000] Linux version 2.6.40.3-0.fc15.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.6.0 20110603 (Red Hat 4.6.0-10) (GCC) ) #1 SMP Tue Aug 16 04:10:59 UTC 2011
*** Bug 746197 has been marked as a duplicate of this bug. ***
Have not tried this via vpnc cmdline, will give that a try to isolate the problem to the NM or kernel ... it appears that in F16, my testing shows that the connections on disconnect back from VPN to the "internet" works sometimes except always fails for google sites ... I am sure there are others but that's mainly what I have. Tried clearing cache/cookies etc ... but still can't even dig the google URL or IPs, but others like yahoo work sometimes ... if I am on VPN for a period over 15 minutes, then coming back seems to break all network connections, can't dig any URL or IP just some more information ... on CentOS6, using NM and VPNC works just fine. Thanks
Cmd line vpnc also has the problems Cisco Compat VPN connections upstream of2.6.40.3-0.fc15 when disconnecting from VPN after some activity while on VPN, you can no longer dig or connect to anything outside of the VPN.
Does it work with later kernels, like say 2.6.40.6-0.fc15 ? I've been using vpnc on that kernel for a while and haven't had problems. Next thing to do is run 'route -n' after disconnecting and see what that says. After that, try removing lldpad with 'yum remove' or 'rpm -e' and see if that makes a difference; most users shouldn't need that program running but some more complicated configurations do; it might be interfering.
Thank you for the response! I'm not sure what the corresponding numbers are for fc16 ( I know the .40 kernels start to match the 3.0 kernels) but with these kernels -- including an update last night -- it doesn't work: 3.1.0-0.rc10.git0.1.fc16.x86_64 3.1.0-1.fc16.x86_64 3.1.0-5.fc16.x86_64 route -n shows the same before and after connecting Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0 I'll try removing lldpad today and see if that makes a difference. When I disconnect I can still ping my gateway and if I ssh into the router I can traceroute and dig to www.google.com but I can't do it from my F16 box. Also, when I run tcpdump I don't see much traffic going to and from router during the dig. I do, however, see a lot of arp who has for my VPN ip -- so I wonder if it is something in the arp cache. I've tried flushing it to no avail, however.
I checked and I do not have lldpad installed [kevinj@raykj ~]$ rpm -qa | grep lldpad [kevinj@raykj ~]$ sudo yum search lldpad [sudo] password for kevinj: Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit adobe-linux-x86_64 | 951 B 00:00 google-chrome | 951 B 00:00 updates/metalink | 20 kB 00:00 updates-debuginfo/metalink | 16 kB 00:00 =================================================================== N/S Matched: lldpad ==================================================================== lldpad-debuginfo.x86_64 : Debug information for package lldpad lldpad-devel.i686 : Development files for lldpad lldpad-devel.x86_64 : Development files for lldpad lldpad.x86_64 : Intel LLDP Agent Name and summary matches only, use "search all" for everything. [kevinj@raykj ~]$ rpm -q lldpad package lldpad is not installed Also, it might be unique to using --nat-mode cisco-udp withing vpnc
A little more information. After disconnecting, I can ping and get to my router (default route above). Any other ping shows nothing but an arp, and the rest dropped by the kernel: [root@raykj ~]# tcpdump -vv tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes ^C08:00:02.141377 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 165.92.17.248 tell raykj, length 28 1 packets captured 164 packets received by filter 133 packets dropped by kernel At this point I was pinging the IP I received from running a traceroute to www.google.com from my router. What other information can I get for you?
Hello? How can we continue to troubleshoot this?
(In reply to comment #13) > A little more information. After disconnecting, I can ping and get to my > router (default route above). Any other ping shows nothing but an arp, and the > rest dropped by the kernel: > > > [root@raykj ~]# tcpdump -vv > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 > bytes > ^C08:00:02.141377 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 165.92.17.248 tell raykj, length 28 > > 1 packets captured > 164 packets received by filter > 133 packets dropped by kernel > Drop packets reported by tcpdump doesn't necessarily mean a problem. Rather it indicates that tcpdump doesn't keep up due to name resolution or parsing packets, for example. To avoid it, use -n to switch resolution off and -w to save packets to a file. See e.g.: http://loopkid.net/articles/2008/06/25/tcpdump-packets-dropped-by-kernel http://prefetch.net/blog/index.php/2011/06/09/one-way-to-avoid-tcpdump-packets-dropped-by-kernel-messages/ > What other information can I get for you? Would you get gather the following data after the problem occurs? 1) # iptables -nvL 2) # ethtool -S eth0 3) $ netstat -s 4) $ cat /etc/resolv.conf 5) $ rpm -q kernel 6) What NIC/driver do you have? Are there any errors regarding it in dmesg? PS: I see no problem with kernel-2.6.40.6-0.fc15.x86_64
See also bug 713315 that fixed a packet dropping problem with e1000e driver.
Jirka, Thanks for the post. Here is the information you are requesting. Yes, the e1000e is one of the two interfaces on which this problem occurs. It happens on both my wlan and eth connections, however a friend of mine has a RealTek RTL8139 and does NOT see this issue. [kevinj@raykj ~]$ sudo iptables -nvL [sudo] password for kevinj: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 79045 59M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 579 39224 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 393 398K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT 66353 packets, 12M bytes) pkts bytes target prot opt in out source destination [kevinj@raykj ~]$ sudo ethtool -S wlan0 no stats available ** I'll perform this on eth0 today. I've done this before, and not seen any packet dropping [kevinj@raykj ~]$ sudo netstat -s Ip: 81445 total packets received 5 with invalid addresses 0 forwarded 0 incoming packets discarded 79666 incoming packets delivered 66552 requests sent out 64 outgoing packets dropped 985 dropped because of missing route 5 fragments received ok 2 fragments failed 220 fragments created Icmp: 2982 ICMP messages received 0 input ICMP message failed. ICMP input histogram: destination unreachable: 746 redirects: 2236 784 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 784 IcmpMsg: InType3: 746 InType5: 2236 OutType3: 784 Tcp: 2828 active connections openings 0 passive connection openings 55 failed connection attempts 193 connection resets received 3 connections established 66106 segments received 55711 segments send out 359 segments retransmited 0 bad segments received. 263 resets sent Udp: 9992 packets received 585 packets to unknown port received. 0 packet receive errors 10380 packets sent 0 receive buffer errors 0 send buffer errors UdpLite: TcpExt: 2 packets pruned from receive queue because of socket buffer overrun 2 ICMP packets dropped because socket was locked 880 TCP sockets finished time wait in fast timer 1514 delayed acks sent Quick ack mode was activated 176 times 250 packets directly queued to recvmsg prequeue. 13788 packets directly received from backlog 543579 packets directly received from prequeue 41972 packets header predicted 427 packets header predicted and directly queued to user 9317 acknowledgments not containing data received 2571 predicted acknowledgments 2 times recovered from packet loss due to SACK data 8 congestion windows recovered after partial ack 1 TCP data loss events 2 fast retransmits 3 retransmits in slow start 79 other TCP timeouts 140 packets collapsed in receive queue due to low socket buffer 170 DSACKs sent for old packets 1 DSACKs sent for out of order packets 4 DSACKs received 35 connections reset due to unexpected data 79 connections reset due to early user close 51 connections aborted due to timeout TCPDSACKIgnoredNoUndo: 2 TCPSackShiftFallback: 60 IPReversePathFilter: 99 IpExt: InMcastPkts: 106 OutMcastPkts: 280 InBcastPkts: 257 OutBcastPkts: 244 InOctets: 60040669 OutOctets: 11565623 InMcastOctets: 343353 OutMcastOctets: 346766 InBcastOctets: 36445 OutBcastOctets: 33428 [kevinj@raykj ~]$ cat /etc/resolv.conf # Generated by NetworkManager domain hsd1.va.comcast.net. search hsd1.va.comcast.net. nameserver 68.87.73.246 nameserver 68.87.71.230 [kevinj@raykj ~]$ rpm -q kernel kernel-3.1.0-1.fc16.x86_64 kernel-3.1.0-5.fc16.x86_64 kernel-3.1.0-7.fc16.x86_64
[kevinj@raykj ~]$ ethtool -i eth0 driver: e1000e version: 1.4.4-k firmware-version: 1.8-3 bus-info: 0000:00:19.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes [kevinj@raykj ~]$ ethtool -i wlan0 driver: iwlagn version: 3.1.0-7.fc16.x86_64 firmware-version: 8.83.5.1 build 33692 bus-info: 0000:02:00.0 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no
Oddly enough I can not reproduce on my wired interface this morning (e1000e) after being able to do so on my wireless (iwlagn) earlier in the morning --I'll continue to try, but it is an interesting fact...
Ok, I reproduced on the wired interface: [kevinj@raykj ~]$ sudo iptables -nvL [sudo] password for kevinj: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 136K 113M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 3 240 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 273 18908 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 2157 1062K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT 98944 packets, 18M bytes) pkts bytes target prot opt in out source destination [kevinj@raykj ~]$ sudo ethtool -S eth0 NIC statistics: rx_packets: 35343 tx_packets: 19999 rx_bytes: 21355416 tx_bytes: 4342045 rx_broadcast: 2559 tx_broadcast: 312 rx_multicast: 160 tx_multicast: 167 rx_errors: 0 tx_errors: 0 tx_dropped: 0 multicast: 160 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 6 tx_tcp_seg_failed: 0 rx_flow_control_xon: 9 rx_flow_control_xoff: 9 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 21355416 rx_csum_offload_good: 11421 rx_csum_offload_errors: 0 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 1 rx_smbus: 4 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 [kevinj@raykj ~]$ sudo netstat -s Ip: 141303 total packets received 9 with invalid addresses 0 forwarded 0 incoming packets discarded 136406 incoming packets delivered 99120 requests sent out 780 dropped because of missing route 1 fragments dropped after timeout 261 reassemblies required 5 packets reassembled ok 1 packet reassembles failed 12 fragments received ok 1 fragments failed 528 fragments created Icmp: 11705 ICMP messages received 0 input ICMP message failed. ICMP input histogram: destination unreachable: 498 redirects: 11207 810 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 810 IcmpMsg: InType3: 498 InType5: 11207 OutType3: 810 Tcp: 2766 active connections openings 0 passive connection openings 87 failed connection attempts 191 connection resets received 1 connections established 98025 segments received 79160 segments send out 875 segments retransmited 0 bad segments received. 354 resets sent Udp: 26407 packets received 271 packets to unknown port received. 0 packet receive errors 18752 packets sent 0 receive buffer errors 0 send buffer errors UdpLite: TcpExt: 7 packets pruned from receive queue because of socket buffer overrun 1075 TCP sockets finished time wait in fast timer 22 packets rejects in established connections because of timestamp 1493 delayed acks sent 1 delayed acks further delayed because of locked socket Quick ack mode was activated 101 times 1518 packets directly queued to recvmsg prequeue. 224317 packets directly received from backlog 3588402 packets directly received from prequeue 61667 packets header predicted 2675 packets header predicted and directly queued to user 10771 acknowledgments not containing data received 4264 predicted acknowledgments 1 times recovered from packet loss due to fast retransmit 26 times recovered from packet loss due to SACK data Detected reordering 6 times using SACK Detected reordering 1 times using reno fast retransmit Detected reordering 6 times using time stamp 9 congestion windows fully recovered 26 congestion windows partially recovered using Hoe heuristic 3 congestion windows recovered after partial ack 0 TCP data loss events 1 timeouts after SACK recovery 48 fast retransmits 5 forward retransmits 5 retransmits in slow start 183 other TCP timeouts 2 sack retransmits failed 492 packets collapsed in receive queue due to low socket buffer 78 DSACKs sent for old packets 23 DSACKs received 62 connections reset due to unexpected data 150 connections reset due to early user close 97 connections aborted due to timeout TCPDSACKIgnoredNoUndo: 9 TCPSackShiftFallback: 653 IPReversePathFilter: 653 IpExt: InMcastPkts: 159 OutMcastPkts: 623 InBcastPkts: 1698 OutBcastPkts: 302 InOctets: 115453709 OutOctets: 17863426 InMcastOctets: 871802 OutMcastOctets: 817271 InBcastOctets: 177302 OutBcastOctets: 41374 [kevinj@raykj ~]$ cat /etc/resolv.conf # Generated by NetworkManager domain hsd1.va.comcast.net. search hsd1.va.comcast.net. nameserver 68.87.73.246 nameserver 68.87.71.230
Upgraded the kernel yesterday to 3.1.1-1 [kevinj@raykj ~]$ uname -r 3.1.1-1.fc16.x86_64 Still seeing the issue. Also attempted to run with the most recent e1000e driver from http://sourceforge.net/projects/e1000/ Both attempts did not solve the issue. Any movement on this?
Problem still occurring -- what other information can I obtain? [kevinj@raykj ~]$ uname -r 3.1.2-1.fc16.x86_64 [kevinj@raykj ~]$ ethtool -i eth0 driver: e1000e version: 1.4.4-k firmware-version: 1.8-3 bus-info: 0000:00:19.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes [kevinj@raykj ~]$ ethtool -i wlan0 driver: iwlagn version: 3.1.2-1.fc16.x86_64 firmware-version: 8.83.5.1 build 33692 bus-info: 0000:02:00.0 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no
I'd say that's not a driver specific problem as it happens both on wireless and wired interfaces. Also, ethtool statistics don't show any errors. However, there are destination unreachable ICMP packets showed in netstat output. So, I would rather say there is a routing problem. Would you again post 'route -n' and 'ifconfig -a' when the problem occurs? Check if the IP and routing table is properly configured on your gateway as well. Attaching wireshark or tcpdump capture (tcpdump -n -i <interface> -s 65535 -w <file>) of pinging and web accessing would be helpful too. What do you get on ping: ping 192.168.1.1 ping 8.8.8.8
Created attachment 541071 [details] pcap of ping after disconnecting from vpn Adding attachment of ping after disconnecting from VPN
Created attachment 541072 [details] pcap of web try using firefox after vpn disconnect adding pcap of web browser try (firefox) after vpn disconnect
[kevinj@raykj ~]$ dig www.cnn.com ; <<>> DiG 9.8.1-P1-RedHat-9.8.1-4.P1.fc16 <<>> www.cnn.com ;; global options: +cmd ;; connection timed out; no servers could be reached [kevinj@raykj ~]$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 [kevinj@raykj ~]$ ifconfig -a eth0 Link encap:Ethernet HWaddr F4:CE:46:06:31:6D inet addr:192.168.1.126 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::f6ce:46ff:fe06:316d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:384325 errors:0 dropped:0 overruns:0 frame:0 TX packets:127738 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:71107939 (67.8 MiB) TX bytes:17862701 (17.0 MiB) Interrupt:22 Memory:d8800000-d8820000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:19603 errors:0 dropped:0 overruns:0 frame:0 TX packets:19603 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1653499 (1.5 MiB) TX bytes:1653499 (1.5 MiB) wlan0 Link encap:Ethernet HWaddr 00:21:6A:7A:3E:C0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:109572 errors:0 dropped:0 overruns:0 frame:0 TX packets:71005 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:106707485 (101.7 MiB) TX bytes:12993285 (12.3 MiB) [kevinj@raykj ~]$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.47 ms 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.396 ms 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.422 ms 64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=0.424 ms ^C --- 192.168.1.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3001ms rtt min/avg/max/mdev = 0.396/0.679/1.474/0.459 ms [kevinj@raykj ~]$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=51 time=19.6 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=51 time=18.1 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=51 time=19.9 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=51 time=18.3 ms ^C --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 18.189/19.031/19.991/0.800 ms [kevinj@raykj ~]$ ping 72.14.204.104 PING 72.14.204.104 (72.14.204.104) 56(84) bytes of data. From 192.168.1.126 icmp_seq=1 Destination Host Unreachable From 192.168.1.126 icmp_seq=2 Destination Host Unreachable ^C --- 72.14.204.104 ping statistics --- 5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 4000ms pipe 2
Hmm, weird, pinging 8.8.8.8 is successful and 72.14.204.104 not. Would you post routing table and ARP cache for both cases (1) when you are connected to the VPN and (2) when you disconnected: $ route -n $ ip neigh show Try also if flushing ARP table help when the problem occurs: # ip neigh flush all
Here it the info **** BEFORE CONNECTING ***** Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0 [kevinj@raykj ~]$ sudo ip neigh show 192.168.1.1 dev eth0 lladdr 68:7f:74:44:53:30 REACHABLE 192.168.1.138 dev eth0 lladdr 00:11:11:5d:38:82 STALE 192.168.1.1 dev wlan0 lladdr 68:7f:74:44:53:30 STALE ***** WHILE CONNECTED ***** Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 165.92.17.128 0.0.0.0 255.255.255.128 U 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0 205.156.52.253 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0 [kevinj@raykj ~]$ sudo ip neigh show 192.168.1.1 dev eth0 lladdr 68:7f:74:44:53:30 REACHABLE 192.168.1.138 dev eth0 lladdr 00:11:11:5d:38:82 STALE ****** AFTER CONNECTED ****** [kevinj@raykj ~]$ sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0 [kevinj@raykj ~]$ sudo ip neigh show 165.92.17.200 dev eth0 INCOMPLETE 165.92.17.248 dev eth0 FAILED 192.168.1.1 dev eth0 lladdr 68:7f:74:44:53:30 REACHABLE 192.168.1.138 dev eth0 lladdr 00:11:11:5d:38:82 STALE [kevinj@raykj ~]$ sudo ip neigh flush all [kevinj@raykj ~]$ sudo ip neigh show 165.92.17.200 dev eth0 FAILED 165.92.17.248 dev eth0 INCOMPLETE 192.168.1.1 dev eth0 FAILED 192.168.1.138 dev eth0 FAILED Interestingly enough, when I use my Verizon Wireless Air Card, I am able to connect and disconnect from VPN and then use the internet afterward just fine. But, no matter the network I connect to using wired or wireless, when disconnecting I can not resolve any hosts.
Here is the same information from when I use the air card: *** CONNECTED TO VPN **** [kevinj@raykj ~]$ sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 66.174.112.192 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 165.92.17.128 0.0.0.0 255.255.255.128 U 0 0 0 tun0 205.156.52.253 66.174.112.192 255.255.255.255 UGH 0 0 0 ppp0 [kevinj@raykj ~]$ cat /etc/resolv.conf # Generated by NetworkManager search awips.noaa.gov er.awips.noaa.gov cr.awips.noaa.gov sr.awips.noaa.gov wr.awips.noaa.gov pr.awips.noaa.gov nameserver 165.92.25.1 nameserver 165.92.25.2 nameserver 66.174.95.44 # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 69.78.96.14 [kevinj@raykj ~]$ ip neigh show [kevinj@raykj ~]$ sudo ip neigh show *** DISCONNECTED AFTER VPN **** [kevinj@raykj ~]$ dig www.google.com ; <<>> DiG 9.8.1-P1-RedHat-9.8.1-4.P1.fc16 <<>> www.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4806 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 13349 IN CNAME www.l.google.com. www.l.google.com. 266 IN A 72.14.204.104 www.l.google.com. 266 IN A 72.14.204.147 www.l.google.com. 266 IN A 72.14.204.99 www.l.google.com. 266 IN A 72.14.204.105 www.l.google.com. 266 IN A 72.14.204.103 ;; AUTHORITY SECTION: google.com. 60654 IN NS ns1.google.com. google.com. 60654 IN NS ns4.google.com. google.com. 60654 IN NS ns3.google.com. google.com. 60654 IN NS ns2.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 85915 IN A 216.239.32.10 ;; Query time: 358 msec ;; SERVER: 66.174.95.44#53(66.174.95.44) ;; WHEN: Thu Dec 15 22:42:31 2011 ;; MSG SIZE rcvd: 220 [kevinj@raykj ~]$ sudo route -n [sudo] password for kevinj: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 66.174.112.192 0.0.0.0 UG 0 0 0 ppp0 66.174.112.192 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 [kevinj@raykj ~]$ sudo ip neigh show [kevinj@raykj ~]$
Well this seems to have been solved somehow in the 3.1.6-1.fc16.x86_64 kernel and it continues to work in the 3.1.7-1.fc16.x86_64 kernel.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping