I have recently configured a Postfix mail server to use SpamAssassin as a before-content filter using SpamPD as described on the SpamAssassin Wiki. I have been quite impressed with how well it is working, with one exception. A few email messages have been getting rejected with the following error message:

After a bit of investigation I found that the problem is due to a few mail servers that include the AUTH parameter to the MAIL FROM command, even when not authenticated. However, this server is configured to allow authentication only over TLS/SSL. The problem is that the AUTH parameter is passed through SpamPD to the receiving instance of postfix, which rejects the MAIL FROM command because the connection from SpamPD is not using TLS/SSL. To solve the problem, add "-o smtpd_tls_auth_only=no" to the postfix receiving entry in master.cf from the example as follows:

I was recently assisting a colleague to setup VNC on a headless server for remote graphical administration. I had followed one of the many VNC+GDM tutorials on the Internet and everything was working great. Then, after a reboot, it stopped. Here's what happened:

Symptoms

The server is running Debian Squeeze and is configured similarly to the settings in this HOWTO on the Ubuntu Forums. After working quite well for several months, the server was rebooted and it ceased to work at all. Whether connecting using VNC or directly over XDMCP I was presented with the generic black X cursor over a black/white/grey patterned screen and the GDM greeter was nowhere in sight.

After much poking and prodding and technical assistance I determined the key symptom. Everything works well when the server is booted with a monitor connected. When started without a monitor, X would fail to start with the following error:

(EE) open /dev/fb0: No such file or directory
(EE) intel(0): No modes.
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Although this shouldn't be a problem for the VNC session (which doesn't require an X display on the video hardware), it was.

Solution

Fixing this problem simply required disabling the GDM server instance running on the display hardware. With this server disabled in the GDM configuration, everything works smoothly regardless of whether or not a monitor is connected. On Debian, the default server can be disabled by editing /usr/share/gdm/defaults.conf and commenting out the following line (around line 604 in my version):

Bug Report?

I'm not knowledgeable enough about how GDM and XDMCP are supposed to work to know if this is a bug or expected behavior. Any feedback on this point would be greatly appreciated.

At our recent LAN Party, I ran into a problem playing Unreal Tournament 2004 (old, I know...) on Windows 7. After clicking "Join Game" or "Host Game" I am presented with the following error message:

There are a few different solutions that I came across. The first is to change permissions on a firewall policy list registry key, which doesn't appear to exist in Windows 7 (although it may solve the problem, if that is where UT2004 wants to write...). The other, which does work for me, is to edit the UT2004 configuration to ignore the Windows firewall. The complete solution was to edit ut2004.ini (stored in the System directory inside the UT2004 installation directory) and add the following lines:

Note that in many configurations on Vista/7, ut2004.ini is saved/loaded from underneath %LOCALAPPDATA%\VirtualStore (usually C:\Users\username\AppData\Local\VirtualStore) due to UAC File Virtualization. Edit ut2004.ini in the VirtualStore as it is loaded preferentially.

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

I have been evaluating different virtualization software recently and have been quite impressed with VirtualBox for desktop virtualization. The user interface is simple and easy to use, and the hardware video acceleration is a real plus. Recently, while installing Windows XP in VirtualBox I encountered a BAD_POOL_HEADER BSOD when booting from an XP installation CD created with nLite (just after "Starting Windows..." is displayed in the status bar). With some help from a thread on MSFN, I tracked the issue down to the Intel drivers that I had included on the CD. I was using version 9.6.0.1014 of the Intel Matrix Storage Manager Floppy Configuration Utility (f6flpy), recreating the CD with version 8.9.0.1023 (from the archives) solved the problem. Note: The choice of IDE controller in the VirtualBox configuration does not appear to matter, both ICH6 and PIIX4 resulted in the BSOD.

I was recently bitten by KB910272 (again). For the unfamiliar, this issue causes Sender ID/SPF records with non-class full subnets to be processed incorrectly and mail from those domains to be rejected. The number of such domains is surprisingly large for this problem to remain unsolved in the normal patch cycle... or so it seems to me right now.

To solve the problem, apply the hotfix from KB910272 or, even better, from one of the superseding updates: KB927478 or KB951639.

Recently I discovered and corrected an obscure problem on a client's system relating to SMTP mail not being received from a single remote domain. The ultimate cause turned out to be the cause for an earlier (only partially solved) problem relating to POST data getting lost for the server hosting their website, and it is all the result of the default configuration on their SonicWall firewall.

By default, SonicWall will block/discard fragmented IP packets. This can lead to very difficult to diagnose problems as large packets (packets larger than the MTU of any link between the source and destination) will mysteriously fail to arrive. To solve the problem, follow the instructions to re-enable fragmented packets.

Note: The reason that fragmented packets are disabled by default is reasonable (at least for simple IP implementations). An IP implementation must keep track of fragments received but not yet reassembled so that when other fragments of the packet arrive (possibly much later and out of order) the original packet can be reassembled. Attackers can use this fact to contribute to a DoS attack by sending many packet fragments which do not contribute to complete packets. This will force the victim system to hold the fragments in memory and exhaust system resources. However, I would expect all practical IP implementations have a limited cache size for fragments to mitigate this scenario...

In summary, I find this default configuration completely unacceptable. A "break the Internet" default policy is ridiculous. I'm surprised that this hasn't bitten more people and wasted more time (or that the affected people haven't complained more loudly about their wasted time). Perhaps it is just Montana that is still using carrier pigeons and other forms of transport with small MTUs...

Having recently configured fax sending/receiving on both a Windows server (using Windows Fax Services on SBS2003) and a Linux server (using Hylafax on Debian Lenny), I felt compelled to write down a few troubleshooting steps for fixing Caller ID problems. Both of these systems include Caller ID information with received faxes (separate from any TSID), but often this information is missing and it is difficult to determine why. Make sure that each of the following items are satisfied:

• Does the phone line to which the fax is connected have Caller ID service from the phone company? (easy to test using a Caller ID-capable phone)
• Does the modem support Caller ID? (check the specs, or skip to the next step)
• Is Caller ID enabled in the modem? Is it being received? To test this, use the following steps:
  1. Stop the fax service
  2. Connect to the modem using Hyper Terminal, telnet, or cu
  3. Query the status of Caller ID on the modem using AT#CID? (or a different modem-specific command). If the modem reports 0 (disabled), enable it with AT#CID=1 and add this to the modem initialization string so it will be enabled after reboot/reconnect.
  4. While still connected to the modem, make a call to the phone line and watch for Caller ID information to be printed. If no Caller ID information is printed, continue troubleshooting the modem/phone until the information is printed.
  5. Disconnect from the modem when finished and restart the fax service

Once the items above are satisfied, the Caller ID information should be gathered by the fax service and included with received faxes. If not, check that the initialization commands include enabling Caller ID, if it is disabled by default (try restarting the fax service, then step 3 from above. If the Caller ID is disabled, something in the fax service is disabling it - or not enabling it). Otherwise, something else is broken and you should add a comment below on how to fix it.

In the office we are using an HP OfficeJet 6310 All-In-One (donated by a friend, thanks mate!). I recently encountered a problem while attempting to scan from the device using the provided HP software bundle. The (very uninformative) error message that I received after pressing the Scan Document button was:

The communication problem is often solved by reinstalling the drivers (simply remove the printer from Printers and Faxes and click "Add Device" from the installation CD - no need to reinstall the included software) or by correcting common network misconfigurations (wrong IP, disconnected network cable, etc.). Steps for basic troubleshooting are discussed on HP's Website for USB and Network connections.

If/When the basic troubleshooting procedures don't solve the problem, there is a very involved solution for correcting the driver network connection settings posted by Ken Leon on the HP Forums (along with other useful suggestions/diagnostics in that thread).

However, in one (increasingly common) case, it may be possible to avoid the need to reconfigure the internals of the scanner drivers. If your ISP participates in DNS Hijacking, it may be prudent to rule this out as a cause of the error. It appears that the scan drivers attempt to address the device based on its hostname rather than its IP address (regardless of configuration) and when it resolves the address of the device, the DNS request gets hijacked and the scan drivers attempt to connect to the ISP server instead of the device. To diagnose this, simply disconnect the network from the Internet (and restart the router and computer after disconnecting to clear their DNS cache) and see if the error still appears. If it does, then this is not the problem, if it does not, you have found the problem. To remedy the problem, add an entry to the hosts file which associates the hostname of the device (both the name displayed in its web configuration as the hostname and its MAC address prepended with "HP" as this is often used by the drivers).