Telekom SIP 1TR119 CompanyFlex legt auf mit Reason: SIP;cause=404;text=”Not Found (1:27)”

Heute mal in anderer Sprache, da die betroffen Nutzer am ehesten aus dem deutschem Sprachraum kommen.

Wir haben einem CompanyFlex oder im Telekom-Fachchinesisch 1TR119 ausprobiert. Hier litten wir unter häufigen Gesprächsabbrüchen. Diese wurden immer von der Telekomseite verursacht und hatten folgenden Grund drin:

Reason: SIP;cause=404;text=”Not Found (1:27)”

wie zum Beispiel in folgendem Bye:

BYE sip:+49190000000123@;transport=tcp SIP/2.0
Max-Forwards: 70
Via: SIP/2.0/TLS;branch=z9hG4bKg3Zqkv7iscypm2yeo4cl9nwd182p3bgqb
From: <;transport=tls>;tag=h7g4Esbg_898065121-1618311345090
Call-ID: c875dd16cf44479e828473e429de19e6
CSeq: 1 BYE
Reason: SIP;cause=404;text="Not Found (1:27)"
Content-Length: 0

Grund hierfür war das Verhalten des SIP-Stacks bei der Registrierung an Das ist mittlerweile ja kein A sondern ein SRV basierter Eintrag im DNS. Dieser sieht bei SIP mit TLS und TCP dann so aus:

dig srv

;; ANSWER SECTION: 3600 IN SRV 10 0 5061 3600 IN SRV 20 0 5061 3600 IN SRV 30 0 5061

Hier bekommt man 3 mögliche Anmeldeserver. Sollte der SIP-Stack sich während eines laufenden Gesprächs an einem anderen Server anmelden, weil zum Beispiel die Telekom die Prioritäten der SRV-Records ändert, dann beendet der vorherige Registrierungsserver und damit auch SIP-Session-Partner nach einem Timeout das Gespräch. Ein schneller Test und provisorische Problembehebung ist der Eintrag eines der Ergebnisse des SRV-Lookups wie zum Beispiel Das ist natürlich keine Dauerlösung, da die Einträge jederzeit wechseln können. Eigentlich müsste der SIP-Stack hier solange am Erstregistrierungsserver dran bleiben, bis er aus der SRV-Liste verschwindet oder unerreichbar ist. Andererseits könnte die Deutsche Telekom die bestehenden Gespräche auch weiterlaufen lassen.

Ich vermute, dass das auch bei DeutschlandLAN-Anschlüssen nach 1TR114 und 1TR118 passieren kann. Je nach Protokoll muss hier die Frage nach den SRV-Records aber auch nach SIP und UDP erfolgen. Das sieht dann so aus:

dig srv

;; ANSWER SECTION: 3368 IN SRV 30 0 5060 3368 IN SRV 10 0 5060 3368 IN SRV 20 0 5060

Migrate linux bare metal server to proxmox Container

Today I had to migrate a bare metal linux machine to an proxmox lxc container. I googled a bit an found a nice shore tar command in the proxmox forum but I had to add some excludes

cd /

tar -cvpzf backup.tar.gz –exclude=/backup.tar.gz –exclude=/proc –exclude=/dev –exclude=/sys /

Without excluding dev proc and sys the tar command tried to compress som virtual 128TB Files in the proc file system. In the new container those directories aren’t needed anyway. Next time I don’t need to google this 🙂

The tar.gz can be copied to the template directory of the proxmox server. Afterwards you can deploy an new container with this template. If you get errors extracting the template. you have to uncheck the “Unpriviliged Container”-Box

firewalld: open port for single ip (or how to limit access to checkmk-agent to a single ip)

Newer versions of checkmk-agent for linux started to use systemd instead of xinetd to spawn the agent. So you loose the ability to limit access through a simple config file.

My Solution was with a rule in firewalld. You have to use a rich rule. Sadly thats not as easy as the usual firewalld stuff…

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="" port protocol="tcp" port=6556 accept'

Afterwards simply restart firewalld or reload rules.

Use Powershell to read data from LDAP and create a modify-LDIF

I just stumbled about a problem to get a list of all users with a telephonenumber from LDAP to create an LDIF for those users. So I decided to use Powershell because it gave me an easy way to create this LDIF file to add an value to every user.

The first script just dumps the DN and the phone number of all objects

$Server= "LDAP://ldpahost.domain.local:389/DC=domain,DC=local"
$DirEntry =New-Object -TypeName System.DirectoryServices.DirectoryEntry -ArgumentList $Server, $DN, $Pw, "FastBind"
$DirSearcher =New-Object -TypeName System.DirectoryServices.DirectorySearcher -ArgumentList $DirEntry, $Filter
$DirSearcher.FindAll() | Select -ExpandProperty Properties | ForEach {
    Write-Output $ldapDN

The second script writes an ldif file to modify a a field on every user:

$Server= "LDAP://ldpahost.domain.local:389/DC=domain,DC=local"
Remove-Item -Path $destfile
$DirEntry =New-Object -TypeName System.DirectoryServices.DirectoryEntry -ArgumentList $Server, $DN, $Pw, "FastBind"
$DirSearcher =New-Object -TypeName System.DirectoryServices.DirectorySearcher -ArgumentList $DirEntry, $Filter
$DirSearcher.FindAll() | Select -ExpandProperty Properties | ForEach {
    Out-File -FilePath $destfile -InputObject "dn: $ldapDN" -Append
    Out-File -FilePath $destfile -InputObject "changetype: modify" -Append
    Out-File -FilePath $destfile -InputObject "add: ldapfield" -Append
    Out-File -FilePath $destfile -InputObject "ldapfield: newContent" -Append
    Out-File -FilePath $destfile -InputObject "" -Append

The resulting file can be used to import it to the directory using LDAPAdmin. But be aware that Powershell generates utf8-files and LDAPAdmin needs ASCII to import. The encoding-Option of OutFile didn’t work out because it killed german umlauts. So I converted it afterwards with notepad.

Only 6-bit color depth on Intel UHD 6xx Graphics and Dell Display

A while ago I noticed some color problems on my work display. It seemed to have problems with color gradients. I investigated a litttle and found information in the advanced display settings that my Dell-Display only supports 6-Bit color depth.

color depth in advanced display settings

Back than I found no clue what the problem could be. Except that at home with the same display I had no problems. Difference was: At home working with NVidia graphics card and at work with an Intel UHD 620 Chipset.

Some days ago I found at least two threads in the Intel forum with people with the same problem. They all have Dell displays and Intel UHD graphics. In one of the treads an Intel employee already said that the problem was found and a new driver will be released soon. As of now this did not happen but I will update this post than.

Update 2018-11-29: Yesterday a new driver was released wich fixes the problem. Beginning with driver version (UWD) full 8-Bit ist available again!

vSphere 6.7U1 update pre-check fails with “DRS should be enabled”

In vSphere 6.7U1 I could not update my ESXi-Hosts in my cluster because the new Remediation Pre-Check fails with  the following error: “DRS should be enabled”

It also has a big red banner:

“Pre-check found problems that will block remediation. See details below. The blocking problems may have caused the pre-check to complete prematurely. Therefore, after fixing the problems, please re-run this pre-check.”

So Host remediation is blocked with error message: “Pre-check has found 2 issues that will block remediation”

Here are my work arrounds so far that I also posted on the relevant spiceworks thread:

1: use the old flex/flash-client. There is no pre-check

2: remove the esxi server from the cluster (just drag&drop the the server in question from the cluster to the datacenter). Outside of the cluster there is no DRS, so the pre-check works and update is not blocked anymore

But I think the second is the easiest way to do it.

I also opened a support request with VMware. I will keep you updated.


/var runs full on VMware ESXi 6.7 on HP Gen8 Server

Today two of my ESXi 6.7 servers running on HP DL360p Gen8 didn’t behave as expected. VMotion and remote consoles quit with internal error.

In vspere syslog I found:

The ramdisk 'var' is full. As a result, the file /var/log/EMU/mili/mili2d.log could not be written.

On ESXi vdf -h revealed a full file system. The milid2.log was the problem and dumped the following errors:

CRITICAL:backend_init:OneConnect Adapter Not Found.
ERROR:rename all the configuration files!
ERROR:MILI_enumerate_elxiscsi:Failed to initialize User Init with status = 19
ERROR:MILI_enumerate_elx_nics:Failed to initialize USer Init with status = 19
ERROR:could not open device node /vmfs/devices/char/vmkdriver/be_esx_nic

In both servers no emulex hardware was installed.  So I removed 3 packages form those ESXis with a reboot between each. The last one solved the problem!

esxcli software vib remove --vibname elxnet

esxcli software vib remove --vibname elxiscsi

esxcli software vib remove --vibname

On my DL360 Gen9 this problem did not occur.

Update: As Gunnar pointed out in a comment this could also happen on a Gen9 on newer vSphere 6.7 Updates.

Update 2 (Thanks Pete): VMware resolved this problem with vSphere 6.7 U2 or Patch ESXi670-201904211-UG

Shimano Ultegra Di2 synchronized shifting

If you want to enable synchronized shifting or semi-synchronized shifting on Ultegra Di2 6870 or on DuraAce Di2 9070, Its possible from now on.

On March 10th Shimano released new Firmware for the front and rear derailleurs. With version 3.0 installed you can enter the configuration menu in e-tube project and set the configuration of the shift modes.

There is only one thing you mght have to change to make it work. synchro shift only works with the newer battery type on road bikes. So if you have the old battery SM-BTR2 you have to upgrade to the newer BT-DN110.

If your system meets all the requirements, its easy to toggle between shift modes. You just have to double press the button on your junction. If you get one blink for confirmation, manual mode is set, if it blinks twice, shift mode 1 is enabled. If it blinks 3 times your bike is set to mode 2.

In default setup mode 1 is synchronized shifting and mode 2 is semi-synchronized