Ungewollte Paketumleitung bei der Deutschen Post DHL

Am 18. Mai 2021 bestellte die M GmbH bei vier verschiedenen Händlern Waren, welche anschließend über die Deutsche Post DHL (im folgenden DHL) verschickt wurden.

Aufgrund von der sehr ungewöhnlichen Status-Updates im Trackingverlauf (10:10 Sendung in Zustellfahrzeug geladen / 10:13 Sendung konnte nicht zugestellt werden), rief ich bei der DHL-Hotline an. Nach 20 Minuten Wartezeit erreichte ich einen Mitarbeiter, welcher nach Übermittlung der Paketnummer zunächst nach meinem Namen und der Adresse fragte. Auf meine Antwort hin hörte ich erst einmal Stille und dann die verstörende Mitteilung, dass die Adresse inkorrekt sei. Der Herr war nicht gewillt mir mitzuteilen, welcher Teil der Adresse denn falsch sei. Er gab nur schroff zurück, dass mit dem Paket etwas nicht stimme und das Paket an den Absender zurückgehen würde. Ich teile ihm mit, dass das für uns nicht sehr hilfreich und letztendlich inakzeptabel sei, die Waren doch schließlich dringend benötigt werden und er mir doch bitte helfen möchte. Was er nicht tat. Er wurde im Gegenteil regelrecht aggressiv. Ich solle mich an den Absender wenden. Ich beendete das Telefonat mit der Aussage: Danke für nichts!

Manchmal hat ein Hotline-Mitarbeiter einen schlechten Tag oder ist nicht so gut geschult. Ich versuchte es also erneut. Nach weiteren 25 Minuten erreichte ich eine etwas hilfsbereitere Mitarbeiterin, welche mich auch nach der Zustelladresse fragte. Die Dame sagte mir dann, dass die Adresse auf dem Paketlabel von der von mir übermittelten Adresse abweichen würde. Der Absender hätte einen Fehler gemacht. Die Adresse wollte auch diese Dame nicht preisgeben, jedoch ließ sie sich dazu hinreißen mir mitzuteilen, dass eine Adresse in Hallenberg auf dem Label stehen würde. Sehr seltsam – haben wir doch hier ein Problem bei gleich vier Paketen. Wie hoch mag die Wahrscheinlichkeit sein, dass sich deutschlandweit an einem Tag gleich vier (von vier) unabhängige Versender mit der Adresse vertan haben? Die Frage kann man sich leicht selbst beantworten.

Da man mit guten Worten bei der DHL offenbar nichts erreichen kann, kontaktierte ich die Versender. Einer der Versender war so nett, mir eine Fotografie des DHL-Labels zu schicken (danke, Herr G.). Die Adresse war, wie erwartet, vollständig und korrekt. Wieder rief ich die Hotline an. Nach weiteren 20 Minuten erreichte ich einen Mitarbeiter, welcher mir natürlich wieder nicht glauben wollte. Auf dem Label würde ein abweichender Empfänger stehen. Fehler des Versenders. Das Paket geht zurück. Details dürfe er mir nicht mitteilen. Ha! Aber nun hatte ich das Label. Ich teilte dem Herrn an der Hotline also mit, dass mir das korrekte Label auch vorliegen würden und bot an, die Abrechnungsnummer sowie Leitcodes und Routingcodes zu übermitteln. Daten, die mir ohne das Label ja gar nicht hätten vorliegen können. Nun erwachte wohl doch ein Funken Ehrgeiz in diesem Mann. Nach circa zwei Minuten Tastaturgeräuschen hörte ich einen erstaunten Ausruf am Telefon. Ich hätte wohl Recht. Das Label sei in der Tat korrekt. Es wäre hier nur eine Paketumleitung eingerichtet worden. Die Pakete würden jetzt offenbar alle nach Hallenberg umgeleitet. Sie würden dort in der Filiale gelagert. Wir könnten die Sachen dort abholen. Na, da sind wir des Rätsels Lösung ja schon ein ganzes Stück nähergekommen. Danke. Die 50km Fahrt hätten wir notfalls in Kauf genommen. Dieser Mitarbeiter nahm auch eine Beschwerde auf. Wir warten seit mehreren Wochen vergebens auf eine Antwort auf eben diese.

Eigentlich kann man Postfilialen nicht anrufen. Eigentlich. Die Postfiliale in Hallenberg liegt innerhalb des REWE-Markts. Über diesen REWE-Markt war es einer Mitarbeiterin unseres Unternehmens möglich, telefonisch Kontakt zu der Postfiliale aufzunehmen und sich bestätigen zu lassen, dass die Pakete tatsächlich in Hallenberg liegen. Oder zumindest lagen. Denn die Mitarbeiterin dort erkannte den Fehler offenbar und gab die Pakete wieder an das Zustellzentrum Winterberg zurück. Eines der Pakete verlieb aber wohl in Hallenberg oder kam wieder nach Hallenberg zurück. Wir könnten dieses dort abholen, müssten aber 6,99 Euro Umleitungsgebühr bezahlen. Wir waren gar nicht gewillt diese Gebühren zu zahlen, wurde dieser Fehler von uns doch nicht verursacht. Die Dame in Hallenberg bemühte sich sehr und investierte viel Zeit in die Lösung dieses Problems. Sie versuchte offenbar uns die Gebühr zu ersparen und telefonierte mit der DHL-Hotline. Leider hat diese Dame von Ihrem Ansprechpartner bei der DHL (Ansprechpartner, ich verfluche Ihre Ignoranz!) wohl nur die Auskunft erhalten, dass es sich bei dem Paket um einen Betrugsfall handeln würde und sie ab sofort gar keine Auskünfte mehr erteilen dürfte. Nicht mal mehr die Paketnummer durfte sie teilen. Das Paket würde an den Absender zurückgehen. Der Computer des Absenders wäre nämlich gehackt worden (sic!). Ich habe versucht der Dame zu erklären, dass das natürlich im Rahmen des Möglichen sei, es jedoch mit an Sicherheit grenzender Wahrscheinlichkeit unmöglich sei, dass gleich vier unabhängige Computer an einem Tag gehackt werden. Aber vergebens, die Dame hatte es nun mit der Angst zu tun bekommen und fürchtete Ärger mit der DHL. Verständlich. Ich danke ihr trotzdem für Ihren Einsatz.

Zwischenzeitlich ergab sich bei einer Kollegin noch ein Geistesblitz. Die M GmbH sitzt in einem kombinierten Wohn- und Geschäftshaus. Die Geschäftsräume erstrecken sich über das Erdgeschoss – darüber befinden sich mehrere Etagen mit privaten Wohneinheiten. War nicht kürzlich ein Anwohner dort aus- und nach Hallenberg gezogen? Eine kurze Nachfrage bei der Vermieterin ergab, dass dem tatsächlich so war. Sie stellte auch Kontakt zu dem ehemaligen Mieter her. Dieser bestätigte mir, dass er einen Nachsendeauftrag bei der Deutschen Post gestellt hat. Er beteuerte aber, dass der Nachsendeauftrag natürlich nur in seinem Namen und ausdrücklich nur für Briefe beauftragt wurde. Mir liegt eine Benachrichtigungskarte der DHL vor, auf dem unser Firmenname, zusammen mit der neuen Privatadresse des Betroffenen gedruckt ist. Well done, DHL. Well done.

Nun fiel mir noch etwas ein. Stand in der letzten Woche nicht ein etwas unglücklicher Postbote an der Tür und wollte 6,99 Euro Gebühren für eine ihm nicht bekannte Leistung kassieren? Ein Beleg oder eine Rechnung lag ihm nicht vor. Das ergibt nun auf einmal einen Sinn. Offenbar trat das Problem auch bei mindestens einem bereits zugestellten Paket auf.

Wir fassen die Fakten kurz zusammen:

  • Die DHL leitet Pakete eines Unternehmens, welches zufällig die gleiche Anschrift wie eine verzogene Privatperson hat, ohne Zustimmung oder Kenntnis des Unternehmens an diese Privatperson in einer anderen Stadt um.
  • Die Privatperson hat keinen Auftrag für die Weiterleitung von Paketen, sondern lediglich für Briefe erteilt.
  • DHL ist an der Hotline nicht im Stande so einen Fehler nachzuvollziehen oder anzuerkennen. Auch ist man nicht bereit an der Hotline zu helfen.
  • Man schiebt das Problem lieber auf andere Beteiligte. Schuld sei hier immer der Versender (denn das Label sei ja falsch bzw. sein Computer sei ja gehackt worden).
  • Für diese absolut hervorragenden Leistungen berechnet die DHL dem Empfänger 6,99 Euro Umleitungsgebühr. Ohne die Zahlung dieser Gebühr, erfolgt keine Übergabe der Pakete. Man wird regelrecht zur Zahlung genötigt bzw. mit der Nichtherausgabe der Pakete erpresst.
  • Beschwerden werden zielgerichtet ignoriert.

macina_banners 1.5.1 Extension ignoriert Sysfolder und zeigt alle Banner an

In der Version 1.5.1 der Extension macina_banners (Advanced Banner Management) scheint es ein Problem mit der Kategorisierung der Banner über mehrere Sysfolder zu geben. In meinem Fall wurden einfach alle Banner angezeigt, unabhängig von der Einstellung, die über typoscript getroffen worden ist. pidList = 123 wird also ignoriert. Das Problem trat in meinem Fall mit einer TYPO3 4.4-Installation auf.

Das Problem scheint im code der Extension zu liegen. Für das Problem ist nämlich bereits ein Fix verfügbar, welcher für die Version 1.5.2 der macina_banners geplant ist und aktuell darauf wartet eingebaut zu werden. Da 1.5.2 schon eine Weile auf sich warten lässt, habe ich den Code manuell übernommen.

Für eine schnelle Abhilfe kann die Extension also direkt editiert werden:

/pfad/zum/webserver/typo3conf/ext/macina_banners/pi1/class.tx_macinabanners_pi1.php

Hier fügen wir hinter den folgenden Zeilen (in Extension-Version 1.5.1 ist das nach Zeile 173)

// alle banner die die aktuelle page id nicht in  excludepages stehen haben
$where .= „AND NOT ( excludepages regexp ‚[[:<:]]“.$GLOBALS[‚TSFE‘]->id.“[[:>:]]‘ )“;

den folgenden Code ein:

// FIX pidList beachten !! Version 1.5.2
if ( $conf[‚pidList‘] != null && $conf[‚pidList‘] != “ )
{
$where .= “ AND pid IN ( „.$conf[‚pidList‘].“ ) „;
}

Weiter Infos:

Fatal error: session_start(): Failed to initialize storage module: files (path: ) in on line

Bei einer aktuellen Debian Linux Installation in Verbindung mit PHP 5.3.3 aus dem Dotdeb-Repository gab es ein Problem mit der Session-Verwaltung:

Fatal error: session_start(): Failed to initialize storage module: files (path: ) in /path/to/php/script/session.inc.php on line 123

Zu lösen war das Problem recht einfach: In der php.ini war die Zeile (session.save_path) auskommentiert. Wird diese einkommentiert

session.save_path = „/tmp“

und der Apache neugestartet, ist das Problem behoben. In anderen Distributionen (OpenSUSE) ist der Speicherort von Haus aus über diese Methode angegeben. Bei einer PHP-Installation aus den Debian-Repositorys tritt das Problem möglicherweise auch nicht in Erscheinung (nicht weiter verfolgt).

Passwort-Reset bei einem HP ProCurve Secure Router 7102dl J8752A

Da die Lösung im HP PDF-Handbuch auf die Schnelle nicht zu finden war: Der Boot ohne Passwort ist bei einem Secure Router 7102dl folgendermaßen möglich:

Im ersten Schritt den Router über ein serielles Kabel mit dem Rechner verbinden. Router sollte ausgeschaltet sein (da wir im Bootvorgang aktiv werden müssen). PuTTY eignet sich als Software hervorragend. Connection type: Serial auswählen; Speed auf 9600 baud belassen). Router einschalten und folgende Meldung abwarten:

Executing bootstrap…
ram: 134217728 bytes of RAM detected.
Serial Number: US511XXXXX
Bootstrap version: J02.01, checksum: 9B84, Tue Mar 29 10:48:20 2005
flash: initializing flash devices…
flash: 33554432 bytes of FLASH detected at 0xfe000000 – dev 0x0001007e
vfs: NONVOL: 504 tracks, 64 sectors/track, 1024 bytes/sector.
eth0/1: initializing…
eth0/1: MAC address is 00:XX:XX:XX:XX:XX
bootstrap: Checking boot configuration…
bootstrap: Primary image is ‚NONVOL:/J02_01.biz‘.
You have 5 seconds to press escape to enter bootstrap mode.

An dieser Stelle ESC drücken

bootstrap: User escaped to command line interface.
cli: starting user interface

Press ‚?‘ for help.
bootstrap#

bypass passwords
boot

Der Zugriff auf den Router ist danach ohne Passwort möglich und man kann ein neues Passwort vergeben.

Netzwerkkarte nachträglich aktivieren – Windows Server 2008 Hyper-V oder Core Installation

Eine nachträglich aktivierte bzw. installierte Netzwerkkarte (oder andere Hardware) kann in einer Microsoft Windows Server 2008 (R2) Core Installation oder einer Microsoft Hyper-V Server 2008 (R2) Installation Fehler verursachen. Eine mögliche Problemlösung ist die Verwendung von DevCon aus dem Microsoft WDK.

Eine nachträglich aktivierte bzw. installierte Netzwerkkarte (oder andere Hardware) kann in einer Microsoft Windows Server 2008 (R2) Core Installation oder einer Microsoft Hyper-V Server 2008 (R2) Installation einiges an Spass bedeuten.

In meinem Fall verfügen die betroffenen Server über zwei onboard Broadcom-Netzwerkkarten des gleichen Typs (d.h. es wird der gleiche Treiber verwendet). Jeweils eine der Karten war zum Installationszeitpunkt über das BIOS der Server deaktiviert. Gegen allen Erwartungen verweigerte die nachträglich aktivierte Netzwerkkarte den Dienst. Ein Remote-Zugriff auf den Gerätemanager unserer Hyper-V Server 2008 R2 Installation zeigte, dass die nachträglich aktivierte Karte einen Fehler 31 aufwies (das Gerät funktioniert nicht ordnungsgemäß, da Windows die für das Gerät erforderlichen Treiber nicht laden kann). Auf einem Standard-Windows hätte ich nun das Gerät neu installiert. Leider ist das ohne einen lokalen Gerätemanager nicht so ohne Weiteres möglich. Der Remote-Gerätemanager dient nur zur Ansicht.

Eine mögliche Lösung ist die Verwendung von Microsoft DevCon aus dem WDK (Windows Driver Kit). Der Download der .iso-Datei ist über 600 MB schwer. Es gibt die devcon.exe auch zum Einzeldownload – jedoch würde ich hier zumindest zur nötigen Vorsicht raten. Nach der Installation kann man das WDK entweder auf CD brennen oder – sofern man noch über wenigstens eine funktionierende Netzwerkkarte verfügt – entpacken und auf den Server kopieren.

Nach dem Download und der Installation des WDK befindet sich devcon unter dem ausgewählten Installationspfad wie folgt wieder (es sind drei Versionen für ia64, amd64 und i386 verfügbar):

C:ToolsWinDDKToolsdevconamd64devcon

DevCon scheint insgesamt nicht sehr beliebt zu sein. Die meisten Probleme entstehen wohl bei der Suche nach der passenden Hardware-ID der betroffenen Hardware. Wie so oft führen viele Wege nach Rom. Im Fall der nicht funktionierenden Netzwerkkarte halte ich das folgende Vorgehen für gut:

Der folgende Befehl listet uns die Hardware auf, die der Klasse net entspricht:

C:ToolsWinDDKToolsdevconamd64>devcon hwids =net

PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_104&1A5F56DF&0&00E5
Name: HP NC107i PCIe Gigabit Server Adapter
Hardware IDs:
PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10
PCIVEN_14E4&DEV_165B&SUBSYS_705D103C
PCIVEN_14E4&DEV_165B&CC_020000
PCIVEN_14E4&DEV_165B&CC_0200
Compatible IDs:
PCIVEN_14E4&DEV_165B&REV_10
PCIVEN_14E4&DEV_165B
PCIVEN_14E4&CC_020000
PCIVEN_14E4&CC_0200
PCIVEN_14E4
PCICC_020000
PCICC_0200

PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_104&29F6B73F&0&00E4
Name: HP NC107i PCIe Gigabit Server Adapter #2
Hardware IDs:
PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10
PCIVEN_14E4&DEV_165B&SUBSYS_705D103C
PCIVEN_14E4&DEV_165B&CC_020000
PCIVEN_14E4&DEV_165B&CC_0200
Compatible IDs:
PCIVEN_14E4&DEV_165B&REV_10
PCIVEN_14E4&DEV_165B
PCIVEN_14E4&CC_020000
PCIVEN_14E4&CC_0200
PCIVEN_14E4
PCICC_020000
PCICC_0200
2 matching device(s) found.

„devcon classes“ gibt übrigens eine Liste der verfügbaren Geräte-Klassen aus.

Nun können wir uns den Status der Geräte anzeigen lassen:

C:ToolsWinDDKToolsdevconamd64>devcon status „PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10“

PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_104&1A5F56DF&0&00E5
Name: HP NC107i PCIe Gigabit Server Adapter
Driver is running.

PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_104&29F6B73F&0&00E4
Name: HP NC107i PCIe Gigabit Server Adapter #2
The device has the following problem: 31
2 matching device(s) found.

Das Gerät zu deaktivieren und zu reaktivieren brachte keinen Erfolg – daher werden beide Netzwerkkarten entfernt:

C:ToolsWinDDKToolsdevconamd64>devcon remove „PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10“

C:ToolsWinDDKToolsdevconamd64>devcon reboot

Der „devcon reboot“ war in meinem Fall leider notwendig. Ein einfaches „devcon rescan“ erkannte die beiden Karten zwar, sorgte jedoch bei einer der Karte für einen neuen Fehler. Nach dem Neustart wurden die Karten nun korrekt erkannt. Man kann das System natürlich auch über andere Wege neustarten lassen ;-).

C:ToolsWinDDKToolsdevconamd64>devcon status „PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10“

PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_104&1A5F56DF&0&00E5
Name: HP NC107i PCIe Gigabit Server Adapter
Driver is running.

PCIVEN_14E4&DEV_165B&SUBSYS_705D103C&REV_104&29F6B73F&0&00E4
Name: HP NC107i PCIe Gigabit Server Adapter #2
Driver is running.

Hilfreich beim Arbeiten mit DevCon sind die folgenden Seiten:

Fehler 0x80300001 bei der Windows Server 2008 R2 Installation

Bei der Installation eines Microsoft Windows Server 2008 R2 erhielt ich kürzlich folgende Fehlermeldung:

Windows kann nicht in dem gewählten Pfad installiert werden. Fehler: 0x80300001

Problemlösung bei mir: Einfach die Windows-Setup-CD wieder einlegen und im Partitionsmenu auf einen nicht aktiven Menupunkt klicken 😉

Was war passiert? Um auf den eingebauten 3ware RAID-Controller zuzugreifen musste ich über die Option „Treiber laden“ die 3ware-Treiber von der 3ware-CD laden.

Nach der Partitionierung der Festplatte über das Windows-Setup befand sich die 3ware-CD immer noch im Laufwerk und Windows schmiss einen irreführenden Fehler 0x80300001. Nach einiger Sucherei an falscher Stelle habe ich die Windows-CD wieder eingelegt und das Problem war erledigt.

Diese falsche Fehlermeldung wird übrigens auch bei Windows 7 ausgegeben – unglaublich.