Bug 730675 - Wired interfaces fail to reconnect after disconnect from VPN in 2.6.40-4.fc15.x86_64
Summary: Wired interfaces fail to reconnect after disconnect from VPN in 2.6.40-4.fc15...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 15
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 746197 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-15 10:49 UTC by Bradley Scalio
Modified: 2012-08-07 19:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-07 19:49:25 UTC


Attachments (Terms of Use)
pcap of ping after disconnecting from vpn (9.91 KB, application/vnd.tcpdump.pcap)
2011-12-05 20:26 UTC, Kevin Johnson
no flags Details
pcap of web try using firefox after vpn disconnect (58.45 KB, application/vnd.tcpdump.pcap)
2011-12-05 20:27 UTC, Kevin Johnson
no flags Details

Description Bradley Scalio 2011-08-15 10:49:43 UTC
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

Comment 1 Bradley Scalio 2011-08-15 11:02:00 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@qualcomm.com>
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

Comment 2 Bradley Scalio 2011-08-15 11:07:40 UTC
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)

Comment 3 Bradley Scalio 2011-08-15 11:10:49 UTC
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

Comment 4 Bradley Scalio 2011-08-15 11:15:41 UTC
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.

Comment 5 Bradley Scalio 2011-08-22 10:20:25 UTC
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.

Comment 6 Kevin Johnson 2011-08-24 13:31:28 UTC
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@x86-18.phx2.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

Comment 7 Josh Boyer 2011-10-19 19:21:17 UTC
*** Bug 746197 has been marked as a duplicate of this bug. ***

Comment 8 Bradley Scalio 2011-10-25 19:53:45 UTC
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

Comment 9 Bradley Scalio 2011-10-26 11:54:34 UTC
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.

Comment 10 Dan Williams 2011-11-03 02:57:58 UTC
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.

Comment 11 Kevin Johnson 2011-11-03 10:09:07 UTC
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.

Comment 12 Kevin Johnson 2011-11-03 10:13:58 UTC
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

Comment 13 Kevin Johnson 2011-11-04 12:18:24 UTC
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?

Comment 14 Kevin Johnson 2011-11-08 14:00:59 UTC
Hello?  How can we continue to troubleshoot this?

Comment 15 Jirka Klimes 2011-11-09 08:54:02 UTC
(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

Comment 16 Jirka Klimes 2011-11-09 09:21:22 UTC
See also bug 713315 that fixed a packet dropping problem with e1000e driver.

Comment 17 Kevin Johnson 2011-11-09 12:46:28 UTC
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

Comment 18 Kevin Johnson 2011-11-09 12:47:29 UTC
[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

Comment 19 Kevin Johnson 2011-11-09 13:08:27 UTC
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...

Comment 20 Kevin Johnson 2011-11-11 12:36:16 UTC
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

Comment 21 Kevin Johnson 2011-11-15 17:44:30 UTC
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?

Comment 22 Kevin Johnson 2011-12-02 02:18:08 UTC
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

Comment 23 Jirka Klimes 2011-12-02 12:15:57 UTC
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

Comment 24 Kevin Johnson 2011-12-05 20:26:44 UTC
Created attachment 541071 [details]
pcap of ping after disconnecting from vpn

Adding attachment of ping after disconnecting from VPN

Comment 25 Kevin Johnson 2011-12-05 20:27:33 UTC
Created attachment 541072 [details]
pcap of web try using firefox after vpn disconnect

adding pcap of web browser try (firefox) after vpn disconnect

Comment 26 Kevin Johnson 2011-12-05 20:36:29 UTC
[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

Comment 27 Jirka Klimes 2011-12-06 15:55:45 UTC
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

Comment 28 Kevin Johnson 2011-12-09 16:56:22 UTC
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.

Comment 29 Kevin Johnson 2011-12-17 20:56:11 UTC
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 ~]$

Comment 30 Kevin Johnson 2012-01-14 00:03:41 UTC
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.

Comment 31 Fedora End Of Life 2012-08-07 19:49:29 UTC
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


Note You need to log in before you can comment on or make changes to this bug.