network-manager-vpnc produces incorrect routing table

[Jernej Stopinšek]

Binary package hint: network-manager-vpnc

I'm using the following versions:
    network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2
    network-manager-vpnc 0.7.1~rc4.20090316+bzr21-0ubuntu2
    vpnc 0.5.3-1

Logging into the same cisco concentrator produces different results depending how you connect.

From network manager:

user@ubuntu:~$ sudo netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
<cisco-ip> 10.10.10.1 255.255.255.255 UGH 0 0 0 wlan0
<cisco-ip> 10.10.10.1 255.255.255.255 UGH 1500 0 0 wlan0
10.15.107.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
10.10.107.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0

From vpnc-connect:

user@ubuntu:~$ sudo netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
<cisco-ip> 10.10.10.1 255.255.255.255 UGH 1500 0 0 wlan0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
10.10.107.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
0.0.0.0 10.10.10.1 0.0.0.0 UG 0 0 0 wlan0

Connecting with network-manager-vpnc also produces this error:

Apr 21 22:37:02 ubuntu NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.vpnc'...
Apr 21 22:37:02 ubuntu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 8426
Apr 21 22:37:02 ubuntu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections
Apr 21 22:37:02 ubuntu NetworkManager: <info> VPN plugin state changed: 3
Apr 21 22:37:02 ubuntu NetworkManager: <info> VPN connection 'Test' (Connect) reply received.
Apr 21 22:37:02 ubuntu kernel: [ 3935.789137] tun0: Disabled Privacy Extensions
Apr 21 22:37:03 ubuntu NetworkManager: <info> VPN connection 'Test' (IP Config Get) reply received.
Apr 21 22:37:03 ubuntu NetworkManager: <info> VPN Gateway: <cisco-ip>
Apr 21 22:37:03 ubuntu NetworkManager: <info> Tunnel Device: tun0
Apr 21 22:37:03 ubuntu NetworkManager: <info> Internal IP4 Address: 10.15.107.7
Apr 21 22:37:03 ubuntu NetworkManager: <info> Internal IP4 Prefix: 24
Apr 21 22:37:03 ubuntu NetworkManager: <info> Internal IP4 Point-to-Point Address: 10.15.107.7
Apr 21 22:37:03 ubuntu NetworkManager: <info> Maximum Segment Size (MSS): 0
Apr 21 22:37:03 ubuntu NetworkManager: <info> Static Route: 10.10.107.0/24 Next Hop: 10.10.107.0
Apr 21 22:37:03 ubuntu NetworkManager: <info> DNS Domain: '(none)'
Apr 21 22:37:03 ubuntu NetworkManager: <info> Login Banner:
Apr 21 22:37:03 ubuntu NetworkManager: <info> -----------------------------------------
Apr 21 22:37:03 ubuntu NetworkManager: <info> (null)
Apr 21 22:37:03 ubuntu NetworkManager: <info> -----------------------------------------
Apr 21 22:37:04 ubuntu NetworkManager: <info> (tun0): writing resolv.conf to /sbin/resolvconf
Apr 21 22:37:04 ubuntu NetworkManager: <info> VPN connection 'Test' (IP Config Get) complete.
Apr 21 22:37:04 ubuntu NetworkManager: <info> (tun0): writing resolv.conf to /sbin/resolvconf
Apr 21 22:37:04 ubuntu NetworkManager: <info> Policy set 'Test' (tun0) as default for routing and DNS.
Apr 21 22:37:04 ubuntu NetworkManager: <info> VPN plugin state changed: 4
Apr 21 22:37:04 ubuntu nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1.

Connection with vpnc-connect is working fine, but with network-manager-vpnc does not.

I use the following config files:

/etc/vpnc/Test.conf

IPSec gateway <cisco-ip>
IPSec ID <group-name>
IPSec secret <group-password>
Xauth username <username>
Xauth password <password>

I start vpnc-connect with:

user@ubuntu:~$ sudo vpnc-connect Test
VPNC started in background (pid: 5061)...

Export of network-manager-vpnc configuration:

[main]
Description=Test
Host=<cisco-ip>
AuthType=1
GroupName=<group-name>
GroupPwd=
EnableISPConnect=0
ISPConnectType=0
ISPConnect=
ISPCommand=
Username=<username>
SaveUserPassword=1
EnableBackup=0
BackupServer=
EnableNat=1
CertStore=0
CertName=
CertPath=
CertSubjectName=
CertSerialHash=
DHGroup=2
ForceKeepAlives=0
enc_GroupPwd=
UserPassword=
enc_UserPassword=
NTDomain=
EnableMSLogon=0
MSLogonType=0
TunnelingMode=0
TcpTunnelingPort=10000
PeerTimeout=0
EnableLocalLAN=1
SendCertChain=0
VerifyCertDN=
EnableSplitDNS=1
SingleDES=0
SPPhonebook=

All other network-manager-vpnc values are left default.

[Alexander Sack (asac)]

the route's look like you have two vpnc connections setup at the same time. Maybe you connect with NM + with vpnc-connect at the same time?

[Jernej Stopinšek (jernej-stopinsek-mega-m)]

I've pasted wrong result for network manager. It should be:

From network manager:

user@ubuntu:~$ sudo netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
<cisco-ip> 10.10.10.1 255.255.255.255 UGH 0 0 0 wlan0
10.15.107.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
10.10.107.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0

Sorry for that.

But I've just figured out that if I connect to VPN via network-manager-vpnc and I manually configure routes to:

user@ubuntu:~$ sudo netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
<cisco-ip> 10.10.10.1 255.255.255.255 UGH 0 0 0 wlan0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
10.10.107.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
0.0.0.0 10.10.10.1 0.0.0.0 UG 0 0 0 wlan0

traffic still won't go through VPN tunnel.
If I connect with vpnc-connect it works fine with this same routing table.

[Alexander Sack (asac)]

thanks. please update the bug summary with the right info.

how do you configure vpnc-connect? what config files are you using? can you please attach them (sanitized by secrets et al).

[Anders Kvist (akv)]

This is also a problem here. I cannot route 0.0.0.0 through my VPN connection as the server doesn't allow it. I have to delete default route and add the old one to be able to use anything else but my work network...

[Anders Kvist (akv)]

Oh, sorry - I'm using OpenVPN - but it's also a problem with that module - maybe it's a change in Network Manager since two different plugins behave the same...

[Anders Kvist (akv)]

I found the solution, at least for the OpenVPN plugin...

Edit VPN settings -> IPv4 Settings -> Routes -> check "Use this connection only for resources on its network"

[Sigurður Guðbrandsson (siggi-siggi-heima)]

I can confirm this bug on 9.04 using network-manager-vpnc
I have tested this on a computer that was upgraded from 8.10 using i386 architecture, and a clean install using amd64 architecture.

In both cases I have a perfect route before I connect using vpnc but a broken route (extra nonsense routes) after I connect using vpnc network manager.

I have no other vpn running on the computer, not even on the network.
This was not broken on 8.10 and this severely affects me since I use vpnc to connect to a lot of my sites in work.

----------------------------------------------------------
nikkiclau@ubuntu:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
nikkiclau@ubuntu:~$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
213.176.148.242 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
10.177.22.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.177.25.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
nikkiclau@ubuntu:~$ ping google.is
PING google.is (216.239.59.104) 56(84) bytes of data.
^C
--- google.is ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5026ms

nikkiclau@ubuntu:~$

[Alexander Sack (asac)]

you can tweak routing for cases where the routing sent by your vpn server is bogus in the network-manager connection editor. That should be good enough for allmost all use cases. check that out.

[Sigurður Guðbrandsson (siggi-siggi-heima)]

Just wanted to add, when I use vpnc-connect I get the following routes when connected (note, different site though, and i'm on a different network right now..)

I connect using 'sudo vpnc-connect /path/to/profile.conf'

-----------------------------------------------------
nikkiclau@ubuntu:~$ route -ne
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.192.193.192 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.100 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.2.100 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
193.4.252.190 10.177.22.254 255.255.255.255 UGH 1500 0 0 wlan0
192.168.39.100 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.193.194.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.192.193.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.192.192.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.0.40.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.177.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0
0.0.0.0 10.177.22.254 0.0.0.0 UG 0 0 0 wlan0
nikkiclau@ubuntu:~$ ping google.is
PING google.is (74.125.77.104) 56(84) bytes of data.
64 bytes from ew-in-f104.google.com (74.125.77.104): icmp_seq=1 ttl=247 time=56.6 ms
64 bytes from ew-in-f104.google.com (74.125.77.104): icmp_seq=2 ttl=247 time=55.3 ms
64 bytes from ew-in-f104.google.com (74.125.77.104): icmp_seq=3 ttl=247 time=56.7 ms
^C
--- google.is ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 55.341/56.261/56.773/0.651 ms
nikkiclau@ubuntu:~$
-------------------------------------

For comparison, I connected to the same site using NM and get the fubar routes (note that it's missing even all the routes that are given by the other end-point[router])
As you can see, the routes are a bit different, and I believe that this is what is needs to be fixed. (i'll come up with a patch if I get the time to debug this).

-------------------------------------
nikkiclau@ubuntu:~$ route -ne
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.177.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0
0.0.0.0 10.177.22.254 0.0.0.0 UG 0 0 0 wlan0
nikkiclau@ubuntu:~$ route -ne
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.100 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
193.4.252.190 10.177.22.254 255.255.255.255 UGH 0 0 0 wlan0
192.168.2.100 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.39.100 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.193.194.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.192.193.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.192.192.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.0.40.0 0.0.0.0 25...

[Sigurður Guðbrandsson (siggi-siggi-heima)]

Alexander,
My issue is not getting things to work properly, I can fix that one by myself.
My main concern is the thousands of users that use this, only to get it broken in Ubuntu 9.04. (and most of them don't have a clue how to fix this)
Thus I am providing contributions about this bug so hopefully this won't be a long standing issue.

Thanks though for the tip.

[Lonnie Lee Best (launchpad-startport)]

Public bug reported:

Although, by manually using vpnc via a command prompt, I don't get this
problem, when I use the GUI provided in Ubuntu 9.04 GNOME netowork-
manager-vpnc (to do a Cisco VPN connection), it doesn't honor split-
tunneling.

While connected to the virtual private network, the GUI enabled VPN
connection sends all traffic accross the tunnel. Therefore:

-I'm unable to reach any destination that is not in the virtual private network. Therefore,
-I'm unable to reach my local dns server, and
-I'm unable to surf the web locally while being connected to the VPN.

However, when I use vpnc mannually from a command prompt, instead
traffic is routed correctly; only traffic destined for the virtual
private network gets sent through the tunnel, and other traffic
appropriately gets routed through my local network (such as DNS
request).

Using the GUI VPN, if my machine makes a request for my local dns server
at 192.168.54.1, instead of sending that to the local machine, it gets
sent accross the tunnel, and since that's not where the DNS server is,
it doesn't resolve.

So, GUI VPN connections don't honor split-tunneling configurations on
Cisco VPNs, but manual command line vpnc does.

Please forgive my redundancy, but I wanted to make it very clear what
the problem is, and the manifestations of this problem.

I look forward to this bug being fixed, because it will allow me to do
vpn connections quickly through the GUI, instead of having to type at
several prompts.

Respectfully,

Lonnie Lee Best
Wilson Wade Vick CPNA

[Timo Aaltonen (tjaalton)]

Looks like Anders' solution should be used, ie. switch the option on by default. Quote:

'Edit VPN settings -> IPv4 Settings -> Routes -> check "Use this connection only for resources on its network"'

[Dan Smith (mrdanpsmith)]

I can confirm that this problem occurs for me and goes away when I check that box. I love launchpad, now everything is working via GUI. Thanks guys.

[Lonnie Lee Best (launchpad-startport)]

Timo,

Anders' solution should be the default setting. The solution to this "bug", is to make this the default setting checked:

Edit VPN settings -> IPv4 Settings -> Routes -> check "Use this connection only for resources on its network"

[Robb Kidd (ubuntu-thekidds)]

I think the bug still exists. I cannot communicate with any hosts at the other end of a tunnel created by network-manager-vpnc (NM-vpnc). The network is multi-subnetted, so the VPN "landing zone" is separate from the hosts to which I need to connect.

As with others on this bug, vpnc-connect works, NM-vpnc does not. The routing tables they create differ, though updating the table during an NM-vpnc session does not fix the problem.

The netmask set for tun0 differs as well:
vpnc-connect = 255.255.255.255 (works)
NM-vpnc = 255.255.255.0 (no worky)

Using 9.04 Jaunty
network-manage 0.7.1~rc4.2009
vpnc 0.5.3-1

[Lars Åge Kamfjord (laaknor)]

This error is confirmed on Ubuntu karmic (development branch) 9.10, downloaded today. network-manager-npc version: 0.8~a~git.20091008t124012.f5b95a2-0ubuntu1

[reader4 (cbrace1-gmail)]

I am having a similar problem using an up-to-date Karmic Ubuntu 9.10 64-bit, same network=manager-vpnc as above (0.8~a~git.20091008t124012.f5b95a2-0ubuntu1):

First, with NM-vpnc I get
$ route -ne
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.4.11 10.112.0.1 255.255.255.255 UGH 0 0 0 eth0
193.15.192.0 0.0.0.0 255.255.240.0 U 0 0 0 tun0
10.112.0.0 0.0.0.0 255.255.128.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
$ ping google.com
^C

Then using vpnc on the CLI
$ sudo vpnc-connect
VPNC started in background (pid: 10594)...
$ route -ne
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.4.11 10.112.0.1 255.255.255.255 UGH 1500 0 0 eth0
193.15.192.0 0.0.0.0 255.255.240.0 U 0 0 0 tun0
10.112.0.0 0.0.0.0 255.255.128.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
$ ping google.com
PING google.com (209.85.225.99) 56(84) bytes of data.
64 bytes from iy-in-f99.1e100.net (209.85.225.99): icmp_seq=1 ttl=54 time=32.5 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 32.517/32.517/32.517/0.000 ms

The only difference I see is in the MSS value: 1500 when connected and working from vpnc-connect, 0 when using the NM-vpnc GUI.

[Jeroen Visscher (jeroen-hetuniversum)]

Hi all,

I am using vpnc-connect now. Has anyone figured out another work-around for this problem? Ticking the "Use this connection only for resources on its network" box does not work for me.

Best regards,

Jeroen

[Marius Jigmond (mjigmond)]

The following setting "Use this connection only for resources on its network" is checked by default on Ubuntu 10.10 and it disables the networking completely after connecting to the VPN server. I had no idea why I was able to connect to the VPN server but I couldn't connect to anything else after that. Un-checking the box (I assume it disables any kind of split) restores the tunneled traffic.

Marius

[Juliano Ravasi (jravasi)]

I had this problem, and made this patch to fix it:

To apply (for Natty):
mkdir -p tmp/deb; cd tmp/deb
sudo apt-get build-dep network-manager-vpnc
sudo apt-get source network-manager-vpnc
cd network-manager-vpnc-0.8.1*/
patch -p1 < ~/path-to-patch/0001-Fix-VPNC-point-to-point-tunnels.patch
dpkg-buildpackage
sudo dpkg -i ../network-manager-vpnc_0.8.1*.deb

Please test and, if possible, nominate it for Natty.

[Mathieu Trudel-Lapierre (cyphermox)]

JRavasi, I'm not convinced this patch really is applicable to all cases; I'm concerned it might break other things for different cases where the netmask is not provided (e.g. what if just 0.0.0.0 is given as an address?). In general, it sounds as though a missing netmask is really an issue with the vpn endpoint used, but I'm just going from memory there. In any case, it would be beneficial if you could provide details (logs and all) as to why this is required. This should be done in a separate bug report.

Also please, send this patch to the NetworkManager mailing list for review: http://mail.gnome.org/mailman/listinfo/networkmanager-list

As far as I know, the initial issue has been resolved in Karmic or at worst in Lucid with the use of the "Use this connection only for the resources on its network" checkbox. If you find that it has not; please file a new bug using 'ubuntu-bug' and providing the exact routes you are getting along with the ones you are expecting so we can fix it.

I'll mark this Fix Released because there has been reports of this bug being fixed with the checkbox that was introduced in (Karmic or Lucid); this doesn't mean everything is fixed, but does mean that we'll need new, separate reports to figure out what else may be wrong.

[Juliano Ravasi (jravasi)]

Mathieu,

I don't think 0.0.0.0 will ever appear as a VPN tunnel endpoint in any sane environment, oh please. You are ignoring how VPNC works. VPNC creates point-to-point connections, and routes the traffic through the tunnel. The netmask is not used for the endpoint, but for the route created afterwards. If you check /etc/vpnc/vpnc-script (which is the default setup script used by vpnc-connect, and which NetworkManager overrides), it has these commands:

  # Point to point interface require a netmask of 255.255.255.255 on some systems
  ifconfig "$TUNDEV" inet "$INTERNAL_IP4_ADDRESS" $ifconfig_syntax_ptp "$INTERNAL_IP4_ADDRESS" netmask 255.255.255.255 mtu ${MTU} up

  if [ -n "$INTERNAL_IP4_NETMASK" ]; then
    set_network_route $INTERNAL_IP4_NETADDR $INTERNAL_IP4_NETMASK $INTERNAL_IP4_NETMASKLEN
  fi

Note that the endpoint address netmask is _always_ 255.255.255.255, a.k.a. /32. The set_network_route function above only sets the endpoint route, not the default route (another function does that). For your convenience (IPROUTE=ip):

  set_network_route() {
    NETWORK="$1"
    NETMASK="$2"
    NETMASKLEN="$3"
    $IPROUTE route replace "$NETWORK/$NETMASKLEN" dev "$TUNDEV"
    $IPROUTE route flush cache
  }

When INTERNAL_IP_NETMASK is not set, this function is not called, which makes sense exactly when the internal netmask is /32 (there is no point in such route, since it is always local).

When using vpnc-connect, which uses the script above, the tunnel works properly; while when using NetworkManager, which overrides the script above with the problematic binary I'm suggesting the patch, it doesn't.

There is a misunderstanding in variable names between vpnc and network-manager-vpnc. INTERNAL_IP4_NETMASK from VPNC is not to be used in the endpoint address, while NetworkManager uses the value passed in NM_VPN_PLUGIN_IP4_CONFIG_PREFIX for such thing. The nm-vpnc helper seems more broken than it looks like, but since there are reports of it working in some cases, I went through the safe route and only set it to the correct value when NETMASK is missing.

The issue has not been resolved, as you can see from the comments above, and I ran into exactly the same issue now in my fully updated Natty installation. So, please, undo the "Fix Released" status, since it requires, at minimum, more investigation.

As I understand, network-manager-vpnc is a plugin separate from network-manager. I already sent the patch to Dan Williams, who is listed in the MAINTAINERS file for the package, but it is taking some time to have it replied.

[Mathieu Trudel-Lapierre (cyphermox)]

Got that already. I've used network-manager-vpnc extensively in the past, and sent patches as well. Regardless; this is a different problem than what was originally reported which is why I've closed the bug (you're also mentioning Natty, where this was reported initially for Jaunty, more than 3 releases ago, no longer supported and a major release difference in NetworkManager) The original reporter (or at least others at the same release levels) already reported this being working properly when they toggle the checkbox.

I appreciate you may still be having dificulties, but I do believe it's a very different problem: that's why I suggested opening a new bug report for your particular issue, so if you use "ubuntu-bug network-manager"; this will add all the necessary information while opening the bug report so we can look into the issue.

In addition, we'd also need debug logs for network-manager-vpnc; see http://live.gnome.org/NetworkManager/Debugging at the end in the NetworkManager-vpnc section. Since you're requesting a fix for Natty; this means we'll at least need careful test cases and a clear explanation of what the problem is and why this fixes it. That's also why I'm suggesting opening a separate bug for the issue so we can have everything together, where we can track that specific small issue and get testing and test feedback.

Obviously, then please comment with the bug number here so I can go and Confirm it, test the patch, etc.