Author Archives: Michael Kuron

Fixing OpenMPI over InfiniBand on Rocks Cluster Linux

We recently got a new small compute cluster at the university, running Rocks Clusters Linux 6.1.1, a CentOS 6 derivative. The nodes are interconnected via an InfiniBand network. Unfortunately, the default configuration of OpenMPI 1.6.2 in the HPC roll wastes a significant amount of performance: it communicates using TCP, which is run over a load-balanced combination of IP over InfiniBand and IP over Ethernet.

Switching to DMA over InfiniBand is simple: just run the following command on all compute nodes and the head node:

sed -i 's/add rocks-openmpi/add rocks-openmpi_ib/g' /etc/profile.d/rocks-hpc.*sh

Now however, you get a message like this when you run an MPI job:

--------------------------------------------------------------------------
WARNING: It appears that your OpenFabrics subsystem is configured to only
allow registering part of your physical memory.  This can cause MPI jobs to
run with erratic performance, hang, and/or crash.

This may be caused by your OpenFabrics vendor limiting the amount of
physical memory that can be registered.  You should investigate the
relevant Linux kernel module parameters that control how much physical
memory can be registered, and increase them to allow registering all
physical memory on your machine.

See this Open MPI FAQ item for more information on these Linux kernel module
parameters:

    http://www.open-mpi.org/faq/?category=openfabrics#ib-locked-pages

  Local host:              bee.icp.uni-stuttgart.de
  Registerable memory:     32768 MiB
  Total memory:            130967 MiB

Your MPI job will continue, but may be behave poorly and/or hang.
--------------------------------------------------------------------------

To fix that, run

echo "options mlx4_core log_num_mtt=24" >> /etc/modprobe.d/mlx4.conf

on all nodes and reboot. log_mtts_per_seg defaulted to 3 on our kernel and did not need tweaking. To check your current values, run

grep . /sys/module/mlx4_core/parameters/*mtt*

One warning message that still comes up when running an MPI job is the following:

--------------------------------------------------------------------------
WARNING: Failed to open "OpenIB-cma-1" [DAT_INVALID_ADDRESS:]. 
This may be a real error or it may be an invalid entry in the uDAPL
Registry which is contained in the dat.conf file. Contact your local
System Administrator to confirm the availability of the interfaces in
the dat.conf file.
--------------------------------------------------------------------------
bee.icp.uni-stuttgart.de:30104:  open_hca: getaddr_netdev ERROR: No such device. Is ib1 configured?
bee.icp.uni-stuttgart.de:30104:  open_hca: device mthca0 not found
bee.icp.uni-stuttgart.de:30104:  open_hca: device mthca0 not found
DAT: library load failure: libdaplscm.so.2: cannot open shared object file: No such file or directory
DAT: library load failure: libdaplscm.so.2: cannot open shared object file: No such file or directory

As UDAPL is removed in newer OpenMPI versions anyway, this is fixed by running

echo "btl = ^udapl" >> /opt/openmpi/etc/openmpi-mca-params.conf

on all compute nodes and the head node.

So all in all, you can simply add the following lines to /export/rocks/install/site-profiles/6.1.1/nodes/extend-compute.xml and rebuild your compute node image:

echo "btl = ^udapl" >> /opt/openmpi/etc/openmpi-mca-params.conf
sed -i 's/add rocks-openmpi/add rocks-openmpi_ib/g' /etc/profile.d/rocks-hpc.*sh
echo "options mlx4_core log_num_mtt=24" >> /etc/modprobe.d/mlx4.conf
dracut -f 2.6.32-504.16.2.el6.x86_64 # may need to rebuild the initrd so it picks up the modprobe parameters

Leserbrief “Vorratsdatenspeicherung”

Am 15. April 2015 kündigte Justizminister H. Maas an, die Vorratsdatenspeicherung wieder einführen zu wollen, die er selber jahrelang kritisiert hatte und die im Jahr 2010 vom Bundesverfassungsgericht und im Jahr 2014 vom Europäischen Gerichtshof verboten worden war. Am 27. April 2015 druckte die Süddeutsche Zeitung dazu einen von mir verfassten Leserbrief:

Elektronische Fußfessel für alle

Wie kann die Antwort auf die überbordende und ungesetzliche Überwachung durch westliche Geheimdienste wie NSA, BND und GCHQ sein, noch größere Datenmassen anzusammeln? In einem Rechtsstaat dürfen erst bei konkretem Verdacht Überwachungsmaßnahmen ergriffen werden, sonst besteht die Gefahr, dass die Bürger den Gebrauch ihrer Freiheiten einschränken, um bloß nicht als falsch-positiver Treffer bei einer Rasterfahndung aufzufallen.

Die Befürworter der Vorratsdatenspeicherung argumentieren unlauter: Es werden Einzelfälle verallgemeinert, um eine Notwendigkeit der Wiedereinführung zu belegen. Es werden seriöse Gutachten ignoriert, die der Vorratsdatenspeicherung keinen nennenswerten Nutzen für die Strafverfolgung attestieren. Es werden gar frei erfundene Beispiele genutzt, siehe Sigmar Gabriels Behauptung, die Vorratsdatenspeicherung habe bei der Aufklärung der Anschläge von Norwegen 2011 geholfen. Wenn die Vorratsdatenspeicherung aber gar nicht die Verfolgung schwerer Straftaten erleichtert, warum verlangt die Politik sie denn dann?

Wenn schon die Kommunikationsdaten nicht von Nutzen sind, liegt die Vermutung nahe, dass der Staat es auf die Mobilfunk-Standortdaten abgesehen hat: Fortwährende Speicherung der Aufenthaltsorte aller Mobiltelefone in Deutschland, quasi elektronische Fußfesseln für die gesamte Bevölkerung, ohne dass diese sie bemerkt – ein Traum für jeden Sicherheitspolitiker, ein Albtraum für die Väter und Mütter des Grundgesetzes.

Die nächsten beiden Jahre großer Koalition werden sehr schwer für die SPD: Sie hat alle ihre Wünsche aus dem Koalitionsvertrag bereits erfüllt bekommen, jetzt besteht die Union auf die Umsetzung ihrer eigenen Projekte. Vielleicht ist es an der Zeit für die SPD, die Koalition einfach aufzukündigen.

Michael Kuron, Frickenhausen

Scientific Article: Role of Geometrical Shape in Like-Charge Attraction of DNA

My first scientific article has been published. It is available at The European Physical Journal E.

Role of geometrical shape in like-charge attraction of DNA
Michael Kuron, Axel Arnold
Eur. Phys. J. E 38, 20 (2015)
DOI: 10.1140/epje/i2015-15020-9

While the journal is not open-access, I am allowed to provide a PDF version of the author’s accepted manuscript for download on my own website below:

Download

Multiple GPUs on unsupported Mac Pro

The first two generations of Apple’s Mac Pro, the MacPro1,1 and MacPro2,1, do not officially run OS X later than 10.7.5. However, there is a modified EFI bootloader available which emulates the EFI64 interface on EFI32 machines. The original version available at Google Code supports OS X 10.9, and there’s a newer one available at Github which also does OS X 10.10. You simply drop in a new boot.efi in two places and add your board ID to the list of supported systems.

The resulting system works perfectly fine, which makes me wonder why Apple didn’t come up with a solution like this themselves. In any case, it extends the life of 2006 and 2007 Mac Pros beyond last year’s end-of-support for OS X Lion.

Since OS X 10.7 and higher included graphics drivers that not only supported the official Apple-supplied GPUs with EFI-compatible firmwares, but pretty much any off-the-shelf Nvidia or AMD GPU, GPUs have become quite easy to upgrade in Mac Pros (the classic tower cheese grater Mac Pro, not the new black trash can Mac Pro). The only thing you lose is the boot screen, so you still need to keep around that original GPU to debug the machine if it doesn’t boot.

These upgraded GPUs work fine with the modified bootloader as well, however if you try to install multiple GPUs (e.g. if you want to drive more than two displays or develop CUDA code and would like to run it in the debugger), only one of them will actually output video.

The solution to make multiple GPUs work in Macs running OS X versions they don’t officially support is surprisingly simple:

sudo /usr/libexec/PlistBuddy -c "Add :IOKitPersonalities:AppleGraphicsDevicePolicy:ConfigMap:Mac-F4208DA9 string none" /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext/Contents/Info.plist
sudo /usr/libexec/PlistBuddy -c "Add :IOKitPersonalities:AppleGraphicsDevicePolicy:ConfigMap:Mac-F4208DC8 string none" /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext/Contents/Info.plist
sudo touch /System/Library/Extensions

So here we are, running a 2006 MacPro1,1 with two EVGA Nvidia GT610 1GB cards, driving three Apple Cinema Displays.

Fixing OS X Server Push Mail

OS X Server 10.7 and later support push mail for iOS devices. This mechanism is neither based on IMAP IDLE (which iOS doesn’t support) nor Exchange ActiveSync (EAS), but on Apple’s Push Notification Service (APNS) infrastructure.

After setting up Mail using the GUI in OS X Server 10.10 Yosemite, I wondered why push didn’t work. From my understanding, it should happen automatically. The only indications something was wrong were the following lines in /Library/Logs/Mail/push_notify.log:

Feb 21 20:13:27 server.example.com push_notify[22848]: ApplePushServiceProvider: Warning: no device map found for 3F2504E0-4F89-41D3-9A0C-0305E82C3301

as well as XAPPLEPUSHSERVICE missing from the IMAP capabilities list:

$ openssl s_client -quiet -connect localhost:993
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

This is often the point where you have to break out the disassembler to find out what is wrong. Luckily however, Dovecot is open source, including the modifications Apple made to support APNS. Tracing through the code, the message above is logged if /Library/Server/Mail/Data/mta/guid_device_maps.plist does not contain a section for the user to which the incoming email is addressed. This section is written when Dovecot receives an XAPPLEPUSHSERVICE command. This command is probably only sent by a client when the XAPPLEPUSHSERVICE capability is reported by the server. The reason why the server didn’t report the capability was a simple incorrect (default) setting, easily fixable using

sudo serveradmin settings mail:imap:aps_topic_enabled = yes

Push mail immediately started working for me after this command, and the capability is correctly reported:

$ openssl s_client -quiet -connect localhost:993
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE XAPPLEPUSHSERVICE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

PHP 5: ldap_search never returns when searching Active Directory

I recently moved a PHP web application from a server running PHP 5.3 on Mac OS X 10.6 to a newer one with PHP 5.4 on Mac OS X 10.9. This caused the following code sample, run against an Active Directory server, to hang at the ldap_search() call:

$conn = ldap_connect('ldaps://' . $LDAPSERVER);
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
$bind = @ldap_bind($conn, $LDAPUSER, $LDAPPW);
$result = ldap_search($conn, $LDAPSEARCHBASE, '(&(samaccountname=' . $searchuser . '))');
$info = ldap_get_entries($conn, $result);
ldap_close($conn);

Wiresharking the connection between web server and LDAP server (after replacing ldaps:// with ldap://) showed:

bindRequest(1) "$LDAPUSER" simplebindResponse(1) success searchRequest82) "$LDAPSEARCHBASE" wholeSubtree
searchResEntry(2) "CN=$searchuser,...,$LDAPSEARCHBASE" | searchResRef(2) | searchResDone(2) success [1 result]
bindRequest(4) "" simple
bindResponse(4) success
searchRequest(3) "DC=DomainDnsZones,$LDAPSEARCHBASE" wholeSubtree
searchResDone(3) operationsError (000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be complete on the connection., data0,

So it’s binding, receiving a success response, searching and then receiving a response and a referrer to DC=DomainDnsZones,$LDAPSEARCHBASE. Next, it opens a new TCP connection and follows the referrer, but does an anonymous bind.

The solution is simple: just add

ldap_set_option($conn, LDAP_OPT_REFERRALS, FALSE);

after line 2. If for some reason you actually need to follow the referrer, have a look at ldap_set_rebind_proc, which lets you specify a callback which then does the authentication upon rebind.

Update August 2015: Same goes when using Net_LDAP3, which is used e.g. by Roundcube’s LDAP integration. Here you need to add the following:

$config['ldap_public']['public'] = array(
[...]
 'referrals' => false,
);

Crossflashing Dell PERC H200 to LSI 9211-8i

OEM version of the LSI SAS 9211-8i, such as the Dell H200, H310 or IBM M1015 are quite popular for use with FreeNAS. However, they need to be flashed with a regular LSI firmware to disable their RAID capabilities in order to passthrough the drives directly to the OS.

Here’s how I upgraded my Dell PERC H200, which came with Dell’s A10 firmware (equivalent to LSI SAS 2008 P07 firmware), to LSI P20 firmware. The newer version also has the advantage that drives larger than 2TB are supported. Also, re-flashing allowed me to not flash a boot ROM to the card, speeding up the boot process of my server as my boot disk is connected to the Intel AHCI controller on the mainboard.

Please note that this operation is not supported by Dell or LSI, may void your warranty and could potentially damage the controller. So proceed at your own risk.

Step 1: Downloading old firmware

  1. Download the firmware for the Dell 6Gbps SAS HBA (this is a variant of the H200 with 8 external ports instead of 8 internal ports) and extract 6GBPSAS.FW from SASHBA_Firmware_6GBPS-SAS-HBA_07.03.06.00_A10_ZPE.exe.
  2. Download the P07 firmware for the LSI SAS 9211-8i and extract the file 2118it.bin from 9211_8i_Package_For_P7_Firmware_BIOS_Upgrade_on_MSDOS_and_Windows.zip.
  3. Download the P05 UEFI flasher for the LSI SAS 9211-8i and extract the file sas2flash.efi from EFI_Installer_P5.zip.
  4. Place these three files into a directory named P07 on a FAT32-formatted USB flash drive.

Step 2: Downloading current firmware

  1. Download the current firmware for the LSI SAS 9211-8i and extract the file 2118it.bin from 9211_8i_Package_P20_IR_IT_Firmware_BIOS_for_MSDOS_Windows.
  2. Download the current UEFI flasher for the LSI SAS 9211-8i and extract the file sas2flash.efi from Installer_P20_for_UEFI.zip.
  3. Place these two files into a directory named P20 on the USB flash drive.

Step 3: Downloading UEFI shell

  1. Download an x86_64 UEFI shell. I had to use the v1 shell because my server would only show error messages (about failed assertions and files not found).
  2. Rename the shell to BOOTX64.efi and place it into a directory named BOOT inside a directory named EFI on the USB flash drive.

Step 4: Flashing

  1. UEFI boot your server off the flash drive
  2. Type map -b to find the flash drive
  3. Switch to it, e.g. by entering fs1:
  4. cd P07
  5. sas2flash.efi -listall should show you your controller
  6. sas2flash.efi -c 0 -list shows you details on the controller. Note down the SAS address in case something goes wrong and you need to reprogram the SAS address.
  7. Erase the old firmware and boot ROM: sas2flash.efi -o -e 6
  8. Write the Dell 6Gbps firmware: sas2flash.efi -o -f 6GBPSAS.FW
  9. Write the LSI P07 firmware: sas2flash.efi -o -f 2118it.bin
  10. cd ..\P20
  11. Write the LSI P20 firmware: sas2flash.efi -o -f 2118it.bin

Notes

At the end of every command (before I rebooted before step 10), I got the message “Failed Reconnecting the EFI Driver. (EFI Error: Not Found)”. It did not seem to affect anything.

Step 7 showed “Erasing Flash Region” and then after a while “ERROR: Erase Flash Operation Failed!”. I simply proceeded and the error did not appear to affect anything.

Step 8 looked like this:

Screen Shot 2014-11-29 at 10.02.09

and the controller details after the flash looked like this:

Screen Shot 2014-11-29 at 10.03.04

During step 9, I received the message “NVDATA Versions Compatible. NVDATA Product ID and Vendor ID do not match. Would you like to flash anyway [y/n]?”, where I simply hit y and it proceeded flashing. At the end, it said “Firmware Flash Successful! Resetting Adapter… Adapter Reset Failed!”. Looking at the controller details showed lots of errors:

Screen Shot 2014-11-29 at 10.06.34So at this point, I rebooted the machine. Now the details looked all right:

Screen Shot 2014-11-29 at 10.09.54

Step 11 worked without a hitch and afterwards the controller details looked like this:

Screen Shot 2014-11-29 at 10.11.38

 

Booting up the server, I now had a Dell H200 that behaved exactly like a LSI SAS 9211-8i. The only difference was that it still reported its name and PCI ID (1028:1f1c) as a Dell 6Gbps SAS Card. FreeNAS didn’t care about that though.

Addendum: Matching firmware and driver versions

I was using this controller with FreeNAS 9.2.1.9 and kept on getting kernel messages like

Nov 30 19:49:55 file02 kernel: (da1:mps0:0:0:0): READ(10). CDB: 28 00 a1 ea 00 58 00 01 00 00 length 131072 SMID 609 terminated ioc 804b scsi 0 state 0 xfer 0
Nov 30 19:49:55 file02 kernel: (da1:mps0:0:0:0): READ(10). CDB: 28 00 a1 e9 ff 58 00 01 00 00 
Nov 30 19:49:55 file02 kernel: (da1:mps0:0:0:0): CAM status: SCSI Status Error
Nov 30 19:49:55 file02 kernel: (da1:mps0:0:0:0): SCSI status: Check Condition
Nov 30 19:49:55 file02 kernel: (da1:mps0:0:0:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected)
Nov 30 19:49:55 file02 kernel: (da1:mps0:0:0:0): Retrying command (per sense data)

It turns out that these are due to a mismatch between firmware and driver version. FreeBSD 9 ships with driver version 16 and FreeBSD 10 includes version 19. Linux currently has version 18. So make sure that in step 11, you always flash the version that matches your operating system’s driver version, don’t blindly go with version P20 or the latest version. On FreeNAS, you can determine the driver version using dmesg | grep “mps0: Firmware”:

mps0: Firmware: 20.00.00.00, Driver: 16.00.00.00-fbsd

In this case, I had no data loss whatsoever and the person who reported this on the FreeBSD mailing list didn’t either, but both LSI and FreeBSD recommend to keep driver and firmware in sync.

Downgrading firmware

As I had to downgrade the firmware, I needed to do sas2flash.efi -o -e 6 before the flashing. Of course, this means that the crossflashing is undone and you’ll have to start over, flashing Dell 6GPBSAS.FW, flashing LSI P07 IT, and finally flashing the version matching your driver.

6GBPSAS.FW and LSI P07 need to be flashed with the LSI P05 sas2flash.efi because later versions will simply refuse when they encounter a NVDATA mismatch. Once that’s done, you can use the latest (P20 at the moment) sas2flash.efi to flash your final firmware version. This also has the advantage that you don’t get these “Adapter Reset Failed” warnings.

Below is a screenshot of the details of the P16 firmware:

Screen Shot 2014-12-03 at 09.11.40

Update 2021: Over the years, LSI was taken over by Broadcom, Broadcom was taken over by Avago, and Avago renamed itself back to Broadcom. As a result, none of the download links above work anymore. The files are still available from Broadcom though: go to https://www.broadcom.com/support/download-search, select “Legacy Products”, “All Legacy Products”, search for 9211-8i.

Asterisk 11 und Sipgate Basic

Für ältere Asterisk-Versionen hat Sipgate in seinen FAQs passende Einträge für die sip.conf aufgeführt. Unter Asterisk 11 hat sich leider die NAT-Behandlung etwas verändert (nat=yes gibt es nicht mehr), deswegen hier meine funktionierende Konfiguration (SIPID durch die Kundennummer und SIPPWD durch das SIP-Passwort ersetzen):

[sipgate-SIPID]
type=friend
insecure=invite
nat=force_rport
username=SIPID
fromuser=SIPID
fromdomain=sipgate.de
secret=SIPPWD
host=sipgate.de
qualify=yes
canreinvite=no
dtmfmode=rfc2833
context=sipgate-in
callbackextension=SIPID
outboundproxy=sipgate.de
trustrpid=yes
sendrpid=no

In der [global]-Section habe ich außerdem

disallow=all
allow=g722
allow=alaw
allow=ulaw

Erläuterungen zu den Einstellungen, die potentiell problematisch sind:

  • nat: wenn hier was anderes steht, werden eingehende Anrufe nicht immer signalisiert. Unter Asterisk 1.8 und früher ging nat=yes.
  • qualify: sendet regelmäßig SIP-Pakete, um in der NAT-Tabelle des Routers zu bleiben. Wenn das nicht aktiviert ist,w erden eingehende Anrufe nicht immer signalisiert.
  • canreinvite: muss deaktiviert sein, weil sonst der UDP-Port für RTP nach der Anrufannahme noch geändert werden kann. Der Router hat den Port dann nicht in seiner NAT-Tabelle und verwirft die Pakete, dementsprechend wird kein Ton übertragen.
  • callbackextension: hiermit spart man sich eine Zeile wie register => SIPID:SIPPWD@sipgate.de/SIPID in der [global]-Sektion. Wichtig: die lokale Extension (das ist der Wert von callbackextension bzw. der nach dem Schrägstrich in der register-Zeile) muss unbedingt gleich der SIPID sein. Wenn er das nicht ist, wird der erste eingehende Anruf nach einer Wartezeit von ca. 30 Minuten oder mehr zwar signalisiert, aber der Anrufer bekommt auch nach dem Annehmen weiterhin das Freizeichen (ein iPhone im Vodafone-Netz zeigte bei mir nach einige Sekunden nach dem Annehmen dann “Anruf fehlgeschlagen” an) und der Angerufene bekommt keinen Ton. Ich hatte ursprünglich nur register => SIPID:SIPPWD@sipgate.de (entspricht callbackextension=s), was auch ging — nur andere Zahlen, z.B. die eigene Telefonnummer, verursachen das Problem.
  • trustrpid: Bei Sipgate-internen Anrufen steht bei eingehenden Anrufen im From-Feld des SIP-Headers nicht immer die Nummer des Anrufers, sondern z.B. dessen Kundennummer. In dem Fall wird die korrekte Nummer im Feld P-Asserted-Identity mitgesendet und mit dieser Option wird sie später ins From-Feld kopiert.
  • sendrpid: Falls man im Dialplan die CONNECTEDLINE-Funktion benutzt, um bei ausgehenden Anrufen Text im Display des Telefons anzuzeigen (und dafür in [global] den Wert sendrpid=pai gesetzt hat), sollte man es für Sipgate hier deaktivieren.

Mit der obigen Konfiguration landen eingehende Sipgate-Anrufe im Dialplan unter SIPID@sipgate-in. Ausgehende Anrufe bekommt man im Dialplan mit

[outgoing]
exten => _0049X.,1,Goto(0${EXTEN:4},1)
exten => _+49X.,1,Goto(0${EXTEN:3},1)
exten => _+XXX.,1,Goto(00${EXTEN:1},1)
exten => _XXX.,1,Set(CALLERID(number)=SIPID)
same => n,Set(CALLERID(name)=49123456789)
same => n,Dial(SIP/${EXTEN}@sipgate-SIPID,,rWT)

wobei 49123456789 die gewünschte Absenderrufnummer ist, wenn im Sipgate-Account bei Absenderrufnummer “setzt das Endgerät” ausgewählt ist. Für die Standardnummer kann man diese Zeile auch weglassen.

Eingehende Anrufe gehen so (angenommen, man hat ein internes SIP-Endgerät mit der Nummer 20 angelegt):

[sipgate-in]
exten => SIPID,1,Dial(SIP/20)

Asterisk: Change number in To header

A long time ago, I wrote about changing the callee ID as seen by the caller using CONNECTEDLINE.
Changing the caller ID as seen by the callee is also pretty obvious using CALLERID.
That leaves two more constellations: changing the caller ID as seen by the caller (which doesn’t make sense because a phone typically doesn’t display its own number on outgoing calls)., and changing the callee ID as seen by the callee, which I’ll talk about here now.

The reason you might want to do this is because you have multiple PSTN phone numbers that ring the same SIP phone. The obvious way to solve this would be to use

exten => _X.,n,SipAddHeader(To: "123456" <sip:123456@server>)
exten => _X.,n,Dial(SIP/${EXTEN})

, but that doesn’t work because SipAddHeader doesn’t overwrite existing headers, it only adds new ones. The Snom forum mentions a hack using the Diversion header, assuming your phone does indeed display that. A much nicer way is the following:

exten => _X.,n,Dial(SIP/${EXTEN}!123456)

. The number after the exclamation mark is simply what Asterisk uses as the local part when it composes the To URI. This features is not well-documented, but from the code I guess it was introduced in Asterisk 1.6. Asterisk 1.8’s (and higher) chan_sip.c gives a short explanation:

 *  SIP Dial string syntax:
 *       SIP/devicename
 *  or   SIP/username@domain (SIP uri)
 * or   SIP/username[:password[:md5secret[:authname[:transport]]]]@host[:port]
 * or   SIP/devicename/extension
 *  or   SIP/devicename/extension/IPorHost
 * or   SIP/username@domain//IPorHost
 * and there is an optional [!dnid] argument you can append to alter the
 *  To: header.

Wifi with WPA/WPA2 mixed mode encryption on Snom phones

When you try to connect a Snom phone to a Wifi network, make sure the network isn’t running in mixed WPA/WPA2 mode. The phone will see the network anyway, but fail to connect at boot. Disabling WPA in favor of WPA2-exclusive operation might be a good idea because WPA’s TKIP encryption isn’t that great and WPA2’s AES is much better. Also, every device sold in the past 8 years supports WPA2, so it’s unlikely you still have anything on your network that doesn’t support it.