| Summary: | Wired interfaces fail to reconnect after disconnect from VPN in 2.6.40-4.fc15.x86_64 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bradley Scalio <bscalio> | ||||||
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 15 | CC: | dcbw, jklimes, kpj104 | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-08-07 19:49:25 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
Bradley Scalio
2011-08-15 10:49:43 UTC
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 |