While attempting to setup OpenSwan on OpenWRT, I encountered the following message in my system log (heavily redacted):

date machinename authpriv.warn pluto[pid]: "connname" #4: ERROR: netlink response for Add SA esp.uid@xxx.xxx.xxx.xxx included errno 2: No such file or directory
003 "connname" #2: ERROR: netlink response for Add SA esp.uid@xxx.xxx.xxx.xxx included errno 2: No such file or directory

After a lot of digging, I found that the in-kernel netlink code is returning -ENOENT in response to the ADD_SA request. This is being propagated from crypto_larval_wait at crypto/api.c:171 as a result of the following call chain:

xfrm_add_sa in net/xfrm/xfrm_user.c
xfrm_state_construct in net/xfrm/xfrm_user.c
xfrm_init_state in net/xfrm/xfrm_state.c
esp_init_state in net/ipv4/esp4.c
esp_init_authenc in net/ipv4/esp4.c
crypto_alloc_aead in crypto/aead.c
crypto_lookup_aead in crypto/aead.c
crypto_alg_mod_lookup in crypto/api.c
crypto_larval_wait in crypto/api.c

This is due to the kernel failing to load a requested crypto module (obviously...). To figure out which modules are failing to load, do the following (taken from Documentation/debugging-modules.txt in the Linux kernel source tree):

1. echo '#! /bin/sh' > /tmp/modprobe
2. echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
3. echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
4. chmod a+x /tmp/modprobe
5. echo /tmp/modprobe > /proc/sys/kernel/modprobe

Then try the connection (or do whatever provokes the error message) and read /tmp/modprobe.log to determine which modules failed to load.

I'm hoping to get a few patches into the OpenWRT source tree to allow selecting the necessary modules (hopefully with a meta-option for all typical IPSec modules). But until then, and on non-OpenWRT systems, the above process should work to figure out which modules are failing to load. Best of luck!

Update: This same problem can also manifest with the following message:

003 "connname" #2: ERROR: netlink response for Add SA esp.uid@xxx.xxx.xxx.xxx included errno 89: Function not implemented

First, my sympathies to anyone who still has to deal with Paradox databases. I recently setup Microsoft Access 2007 on a Windows 7 64-bit computer to manipulate data in an old Boreland Paradox database (from a limited user account). I consider this to be the computer equivalent of putting the engine from an old VW Beetle into a new Porche 914 (rather than the other way around)... but nonetheless, it has been done. The only serious problem was the following error message, which appeared upon opening the database from Access:

The cause was a series of permissions errors caused by the more strict access controls in Windows Vista/7. To fix the error perform the following steps:

1. Grant write permissions for the user/group who will be running Access on HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Borland\Database Engine\Settings in the Windows Registry.
2. Change the BDE configuration to avoid writing to C:\PDOXUSRS.NET
   1. Run "C:\Program Files (x86)\Common Files\Borland Shared\Bde\BDEADMIN.exe" as an Administrator
   2. Navigate to Configuration | Drivers | Native | Paradox
   3. Change the NET DIR parameter to somewhere writable (and shared between users). I created a folder in %systemdrive%\ProgramData.
3. If necessary, grant write permissions on HKEY_CLASSES_ROOT\.html in the Widnows Registry. I don't believe this was strictly required, but at one point I had enabled it during testing and am not completely certain if it was ruled out as a cause of the problem.

After performing the above steps, the error should be resolved. If not, I suggest using Process Monitor to look for permissions errors and attempt to resolve them (which is what I did). Best of luck.

Additional Information: Also, for those looking to the future, Access 2010 and later have dropped support Paradox 3-7, so further workarounds may be required.

Background

I am using Merge Replication with SQL Server 2008 R2 (server and clients). I have setup a publication with a rather complex filtering hierarchy rooted in a table with Parameterized Row Filters extended many times through Join Filters. Making modifications to data in a table near the root of this hierarchy would trigger repartitioning of the replicated data which would never complete and would cause deadlock errors in the other connections to the database while it ran (I let it run overnight once in single user mode, but had to kill it after 13 hours...).

Investigation Technical Details

After a lot of watching in SQL Profiler and digging around in the triggers/procedures which perform the repartitioning I found the culprit. The replication DML trigger on the table (MSMerge_op_GUID) called the repartitioning procedure (MSmerge_expand_sp_GUID) which included several queries with the following subquery:

Looking at the execution plan for any of the queries showed that this subquery was responsible for at least 40% of the total query cost. Both of these tables are quite large (~800k and ~425k rows respectively in my DB) and neither had indexes to cover this (sub-)query.

Solution

So, of course, I added the following indexes (with naming conventions to match the existing indexes):

After adding these indexes, the repartitioning operations completed in under 20 minutes!

Caveat

Both of these tables are heavily used and often modified (depending on the workload), so adding more indexes may not be the best solution for databases with high-performance requirements where repartitioning is rare and non-repartitioning operations are the norm. If that is the case, I suggest creating the above indexes before major repartitioning operations and removing them once the repartition is complete. However, that being said, I have been able to leave these indexes on the tables with no noticeable performance impact and a significant reduction in execution time for data modifications which involve repartitioning data.

Recently, the "Report Menu" stopped appearing in the Main Menu in Visual Studio 2005 after focusing on the report designer surface (in an ASP.NET project). This is a rather significant problem for me, since I do not know of another way to modify report parameters and data sources....

I did a bit of digging through the activity log (as described in Troubleshooting Extensions with the Activity Log on the Visual Studio Blog, but found that the Microsoft Report Designer Package was loading without error. The real breakthrough came after watching devenv.exe in Process Monitor and watching it load the Visual Studio 2008 versions of Microsoft.ReportDesignerUI.dll and several others....

My guess is that the cause of the problem was installing Business Intelligence Development Studio with the "Advanced Services" skew of SQL Server 2008 R2 Express, which uses Visual Studio 2008 and a version of the Microsoft Report Designer Package designed for that version of VS. However, I have not confirmed this absolutely, because I need the newer version for another project. So, instead, I will bite the bullet and upgrade all of my Report Viewer 2005 reports to Report Viewer 2008. At least then I can edit them in Visual Studio 2010 (did I mention Report Designer 2008 - in VS 2010 - won't edit/save 2005 files?).

In case this sounds like a familiar gripe, I had similar problems with incompatible library versions in Microsoft Access.

After a bit of frustration at Joomla! for discarding important error information, and phpMailer for not providing a method of retaining that error information, I have discovered that my client's web host, 1and1, blocks outbound connections on port 25 to all hosts except smtp.1and1.com. This wouldn't be a significant problem if I hadn't setup SPF on their domain.... Looks like it is time to open up an alternate port on the mail server....

Update: 1and1 is blocking ports 465 and 587 in addition to port 25. Great....