Archiv des Autors: s.jorde

Cisco Mobility Service Engine Version: 8.0.150.0 mit NMSP Problem

Beim Setup eines WLCs mit der TAC Version 8.3.141.5 und einer Cisco Mobility Service Engine (MSE) Version: 8.0.150.0 kam keine NMSP/SSL Tunnel nach dem Update der MSE auf Version 8.0.150.0 mehr zustande. NMSP, das Network Mobility Services Protocol, ist der das Kommunikationsprotokoll zwischen den MSE und den WLCs. Es transportiert Telemetrie, Warnungen sowie RSSI Informationen.

Tricks wie Rückfall auf SHA-1 oder neusetzen der Hashes waren erfolglos. Im Log des WLC war beim Debugging folgendes sichtbar:

(Cisco Controller) >debug nmsp all enable
*nmspRxServerTask: Aug 16 09:13:54.461: [PA] Polling nmsp connection at 0 index 0 (94). Handshake in progress
*nmspRxServerTask: Aug 16 09:13:55.081: [PA] Polling nmsp connection at 0 index 0 (94). Handshake in progress
*nmspRxServerTask: Aug 16 09:13:55.701: [PA] Polling nmsp connection at 0 index 0 (94). Handshake in progress
*nmspRxServerTask: Aug 16 09:13:56.005: [PA] ssl handshake timeouted for connection 0
*nmspRxServerTask: Aug 16 09:13:56.005: [PA]  freeing Nmsp Connection [0]
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] Accept succ for http socket addrtype=IPV4(0xf51410ac)
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] Allocated new NMSP connection 0
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] sslConnectionInit:  SSL_new() conn ssl 0x7f710c03af98
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] sslConnectionInit: SSL_do_handshake for conn ssl 0x7f710c03af98, conn state: INIT, SSL state: HANDSHAKING
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] — returns WANT_READ for conn ssl 0x7f710c03af98
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] sslConnectionInit() success with Connection state: INIT, SSL state: HANDSHAKING
*nmspRxServerTask: Aug 16 09:14:15.053: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:15.685: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:16.317: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:16.949: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:17.581: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:18.213: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:18.845: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:19.477: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:20.109: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:20.741: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:21.373: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress

Ursache hierfür ist Cisco Bug CSCvh24960. Die CiscoJ, eine Art Helper für die Kommunikation zwischen MSE und WLC, so der TAC ist ab Version  8.0.150.0 nach ausführen der setup.sh deaktiviert.

Damit der NMSP Tunnel wieder hoch kommt muss CiscoJ händisch auf der MSE aktiviert werden. Dies geht wie folgt:

root@mse1a:~[root@mse1a ~]# configureCiscoJ.sh status
CiscoJ is disabled.
root@ca-bbg1mse1a:~[root@mse1a ~]# configureCiscoJ.sh enable
CiscoJ is enabled.

Weiterführende Informationen unter https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvh24960/.

Cisco IOS Router an Telekom Annex J ADSL BNG

Um einen Cisco IOS Router an einem Telekom Annex J ADSL im neuen BNG betreiben zu können ist ähnlich wie beim VDSL auf dem Ethernet auf dem ATM Interface ein entsprechender VLAN Tag nötig.

Die Konfiguration sieht wie folgt aus:

test-router#sh run int atm0/0/0
Building configuration…

Current configuration : 178 bytes
!
interface ATM0/0/0
description — WAN —
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
atm vc-per-vp 64
no atm ilmi-keepalive
end

test-router#sh run int atm0/0/0.7
Building configuration…

Current configuration : 114 bytes
!
interface ATM0/0/0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
End

Die Nutzung des ATM Sub-Interfaces ist zwingend erfoderlich, da der Befehl bridge-dot1q encap 7 im ATM Interface nach dem Reboot verschwindet. Erst im Subinterface ist er Rebootfest.

Getestet auf dem IOS 15.5(3)M6 und der Modemfirmware VA_A_39m_B_38h3_24h_o.bin.

test-router#sh ver | i IOS
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.5(3)M6, RELEASE SOFTWARE (fc2)
test-router#sh controllers vDSL 0/0/0
Controller VDSL 0/0/0 is UP

Daemon Status:           Up
[…]
Modem Status:            TC Sync (Showtime!)

DSL Config Mode:         AUTO
Trained Mode:   G.992.5 (ADSL2+) Annex J
TC Mode:                 ATM
Selftest Result:         0x00
DELT configuration:      disabled
DELT state:              not running

Full inits:             55
Failed full inits:      40
Short inits:            25
Failed short inits:     37

Firmware        Source          File Name
——–        ——          ———-
VDSL            user config     flash:VA_A_39m_B_38h3_24h_o.bin

Modem FW  Version:      150716_0926-4.02L.03.B2pvC038h3.d24h
Modem PHY Version:      B2pvC038h3.d24h
Trellis:                 ON                       ON
SRA:                     disabled                disabled
SRA count:              0                       0
Bit swap:                enabled                 enabled
Bit swap count:         112113                  1345
Line Attenuation:        52.0 dB                 36.0 dB
Signal Attenuation:      54.2 dB                 35.5 dB
Noise Margin:             5.7 dB                  5.9 dB
Attainable Rate:        10416 kbits/s            1951 kbits/s
Actual Power:            19.3 dBm                13.1 dBm
Total FECC:             21095028                         2384697
Total ES:               2877                     1184
Total SES:              1116                     3
Total LOSS:             85                       0
Total UAS:              113338                   113338
Total LPRS:             0                        0
Total LOFS:             442                      0
Total LOLS:             0                        0

DS Channel1     DS Channel0   US Channel1       US Channel0
Speed (kbps):             0             5624             0              2056
SRA Previous Speed:       0                0             0                 0
Previous Speed:           0             3452             0              1980
Total Cells:              0       3431086630             0        2825378336
User Cells:               0         69269238             0          21398987
Reed-Solomon EC:          0         14067201             0              9282
CRC Errors:               0            60804             0              1506
Header Errors:            0             1448             0                 2
Interleave (ms):       0.00             7.61          0.00              6.75
Actual INP:            0.00             6.62          0.00              1.13

Training Log :  Stopped
Training Log Filename : flash:vdsllog.bin

MySQL „Error 1067: The process terminated unexpectedly“

Nach einem strombedingten Totalausfall einer Hyper-V Maschine startete der MySQL Server einer VM nicht mehr.

MySQL „Error 1067: The process terminated unexpectedly“

Der check auf der Commandozeile mittels C:\Program Files\MySQL\MySQL Server 5.5\bin>mysqld.exe -console zeigte keinerlei Fehlermeldung.

Alle Verzeichnisse waren intakt bzw. wurden korrekt zurückgesichert.

Abhilfe brachte das MySQL Instance Config-Tool (zu finden unter \bin\MySQLInstanceConfig.exe).

Mittels der Einstellung „Reconfigure Instance“ wurde sämtliche Config erneut durchgeklickt – es wurden keine Änderungen vorgenommen und mittels „Execute“ die sämtliche Konfig, die zur Instanz gehört, neu geschrieben.

Danach startete der Service fehlerfrei und es standen sämtliche Daten wieder zur Verfügung.

Es handelte sich hierbei um eine bereits etwas in die Jahre gekommene Version 5.5.22-winx64 welche lediglich ein internes Programm befeuerte.

Inbetriebnahme AIR-AP1572EAC-E-K9

Bei der Inbetriebname eines AIR-AP1572EAC-E-K9 war in der Konsole folgende Fehlermeldung zu sehen:

*Jul 11 12:57:16.211: %CAPWAP-5-SENDJOIN: sending Join Request to 1.2.3.4
*Jul 11 12:57:16.211: %DTLS-5-ALERT: Received WARNING : Close notify alert from 1.2.3.4
*Jul 11 12:57:16.211: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 1.2.3.4:5246
*Jul 11 12:57:26.211: AP has SHA2 MIC certificate – Using SHA2 MIC certificate fS.

Im Log des WLC erscheinte das Gerät mit der Meldung

AAA Authentication Failure for UserName:234567890 User Type: WLAN USER

Bei Check der Konsole fiel auf, dass das Gerät im „Bridge“ Modus läuft:

AP234567890#show capwap client config | i Mode
Mode                  Bridge

Mit dem Befehl capwap ap mode local konnte der Modus via CLI umgehoben werden. Danach bootete der Accesspoint einmal durch und jointe wie gewohnt zum WLC.

Getestet mit c1570-k9w8-mx.153-3.JBB6.

Nach erfolgreicher Anmeldung am ADFS Proxy erscheint AADSTS50008: SAML token is invalid.

Nach erfolgreicher Anmeldung am ADFS Proxy erscheint AADSTS50008: SAML token is invalid. screenshot-error-message

Beim Betrieb einer föderierten Domain, welche mittels ADFS / ADFS Proxy Benutzer via Single Sign On gegen Office 365 dienste authentifiziert erscheint ohne Change an den on premise Systemen plötzlich die Fehlermeldung:

  • Leider können wir Sie nicht anmelden.
  • Es wurde eine ungültige Anforderung empfangen.
  • Weitere technische Informationen:
  • Correlation ID: 99a6cc54-47f1-4936-a57c-59050600a8f8
  • Timestamp: 2015-10-23 05:12:39Z
  • AADSTS50008: SAML token is invalid.

Beim Studium von KB3015526 (https://support.microsoft.com/en-us/kb/3015526) erscheint der Hinweis, auf dem ADFS Server das Powershell-Kommando:

Update-MsolFederatedDomain -DomainName [verified domain]

abzusetzen, da es sich hierbei um einen bekannten Fehler handelt.

Gesagt getan – auf dem ADFS Server mit Hilfe der Microsoft Online Services Module auf dem ADFS Proxy und zwei Befehlen durchgeführt – leider ohne Erfolg.

PS C:\Windows\system32> connect-msolservice
WARNING: There is a newer version of the Microsoft Online Services Module. Your current version will still work as expected, however the latest version can be downloaded at https://portal.microsoftonline.com.
PS C:\Windows\system32> Update-MsolFederatedDomain -DomainName xyz.net
Successfully updated ‚xyz.net‘ domain.

Der Update-Befehl brachte in diesem Fall nicht die erwarteteLösung.

Beim weiteren Troubleshooting der Domaincontroller Logs fiel auf, dass aufgrund einer Firewallmigration die Zeit vom Zeitserver nicht mehr korrekt vom Internet synchronisiert wurde. Der gesamte Forrest ging 5 Minuten vor.

Lösung für AADSTS50008: SAML token is invalid bei Office 365 / Microsoft Azure Active Directory war in diesem Fall eine resynchronisation der Zeiten. Danach klappte es auch wieder mit der Anmeldung am Office 365 mittels ADFS / ADFS Proxy. In diesem Sinne – tempus fugit.

Entfernten Service mit Hilfe des Service Controllers durchstarten

Möchte man beispielsweise den Prozess w32time (Windows Zeitdienst) einmal durchstarten reicht die Eingabe des verketteten Befehls in einer cmd mit administrativen Rechten:

C:\Windows\system32>net stop w32time && net start w32time
The Windows Time service is stopping.
The Windows Time service was stopped successfully.

The Windows Time service is starting.
The Windows Time service was started successfully.

Soll dieses Durchstarten vom Prozess w32time beispielsweise auf einem entfernten Ziel-Server / PC ausgeführt werden hilft der Service Controller vom Windows:

C:\Windows\system32>sc \\vh01 stop w32time && sc \\vh01 startw32time

SERVICE_NAME: w32time
TYPE               : 20  WIN32_SHARE_PROCESS
STATE              : 3  STOP_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE    : 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT         : 0x2
WAIT_HINT          : 0x3e8

SERVICE_NAME: w32time
TYPE               : 20  WIN32_SHARE_PROCESS
STATE              : 2  START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE    : 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT         : 0x0
WAIT_HINT          : 0x7d0
PID                : 1000
FLAGS              :

Nähere Informationen zum SC gibt es hier: https://technet.microsoft.com/de-de/library/bb490995.aspx.

PS: Mit net time kann man sich auch die entfernte Zeit anzeigen lassen:

C:\Windows\system32>net time \\vh01
Current time at \\vh01 is 23.10.2015 19:48:12

The command completed successfully.

PPPoE Connection schlägt mit C886VAJ-K9 und IOS 15.4(3)M2 fehl

Beim heutigen testen eines neuen C886VAJ-K9 mit IOS 15.4(3)M2 stieß ich auf ein Problem bei der Zuweisung der öffentlichen IP Adresse während der ADSL/VDSL Einwahl. Im Log war ersichtlich, dass der Dialer up war und ca. 30 Sekunden später wieder abfiehl.

000213: *Mar 15 09:24:52: %DIALER-6-BIND: Interface Vi2 bound to profile Di1
000217: *Mar 15 09:24:52: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
000213: *Mar 15 09:24:52: %DIALER-6-BIND: Interface Vi2 bound to profile Di1
000219: *Mar 15 09:24:52: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up000223: *Mar 15 09:25:23: %DIALER-6-UNBIND: Interface Vi2 unbound from profile Di1
000225: *Mar 15 09:25:23: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
000226: *Mar 15 09:25:23: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down

Die IP Interface Brief-Summary zeigte, dass zwar Status und Protocol up waren, aber die IP-Adresse war noch unassigned:

router1#sh ip int brief | i Di
Dialer1                    unassigned   YES IPCP   up                    up

Um CRC oder Header Fehler auf dem VDSL auszuschließen kontrollierte ich die entsprechenden Counter:

router1#sh controllers vdsL 0 | i Err
CRC Errors:               0                0             0                 0
Header Errors:            0                0             0                 0

Bisherige Tests im Labor mit einem C1921-SEC-K9 und dem IOS 15.2(4)M7 verliefen ohne Probleme. Insofern entschied ich mich den Router zuerst auf 15.3(3)M5 zuheben. Auch hier die Einwahl ohne Probleme. Das Upgrade auf 15.4(3)M1 auf dem C1921-SEC-K9 klappte auch, allerdings zeigte dieser dann die identischen Probleme bei der Zuweisung der öffentlichen IP am Dialer-Interface.

Das auf dem C1921-SEC-K9 mit IOS 15.4(3)M1 durchgeführte Debugging der PPP-Negotiation zeigte die Ursache:

[…]
000158: *Mar 15 10:23:42: Vi2 CHAP: I SUCCESS id 1 len 42 msg is „CHAP authentication success, unit 8114“
000159: *Mar 15 10:23:42: Vi2 PPP: Phase is FORWARDING, Attempting Forward
000160: *Mar 15 10:23:42: Vi2 PPP: Phase is ESTABLISHING, Finish LCP
000161: *Mar 15 10:23:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
000162: *Mar 15 10:23:42: Vi2 PPP: No AAA accounting method list
000163: *Mar 15 10:23:42: Vi2 PPP: Phase is UP
000164: *Mar 15 10:23:42: Vi2 IPCP: Protocol configured, start CP. state[Initial]
000165: *Mar 15 10:23:42: Vi2 IPCP: Event[OPEN] State[Initial to Starting]
000166: *Mar 15 10:23:42: Vi2 IPCP: O CONFREQ [Starting] id 1 len 10
000167: *Mar 15 10:23:42: Vi2 IPCP:    Address 0.0.0.0 (0x030600000000)
000168: *Mar 15 10:23:42: Vi2 IPCP: Event[UP] State[Starting to REQsent]
000169: *Mar 15 10:23:42: Vi2 PPP: Control packet rate limit 10 reached
000170: *Mar 15 10:23:42: Vi2 PPP: Entering block state for 30 seconds
000171: *Mar 15 10:23:42: Vi2 PPP: Packet throttled, Dropping packet
000172: *Mar 15 10:23:42: Vi2 PPP: Packet throttled, Dropping packet
000173: *Mar 15 10:23:45: Vi2 PPP: Packet throttled, Dropping packet

Es verdichtete sich die Vermutung, dass sich die Default-Parameter zw. IOS 15.2(4)M7 und IOS 15.4(3)M2 auf dem C1921-SEC-K9  geändert haben, wodurch sich ggf. auch das Problem auf dem C886VAJ-K9 erklären könnte. Dieser zeigte im PPP-Debugugging die gleichen Throtteling-Meldungen.

Insofern verglich ich mit dem Befehl show running-config all | i ppp zw. den beiden IOS 15.2(4)M7 und IOS 15.4(3)M1 und es fiel der neue PPP Default-Parameter ppp packet throttle 10 1 30 auf. In der Tat zeigte sich das Blocking auch mit dem Kommando:

router1#sh ppp throttled
Ingress Port         Uniq ID          Remaining Block Time
———————————————————-
Virtual-Access2         5                  27 Seconds

Da ich weder in den Release-Notes noch in den Whitepapers zu den jeweilgen IOS Versionen fündig wurde, versuchte ich mit  ppp packet throttle 20 1 30 einen Schuss ins Blaue um so die neuen Default-Werte etwas zu enthärten – erfolgreich. Letztendlich erlaubte ich pro Sekunde 10 weitere Control-Pakete was die Policy etwas abschwächte und nun die Zuweisung der IP Adresse via IPCP auf dem Dialer-Interface gelang:

[…]
000141: *Mar 15 10:51:50: Vi2 CHAP: I SUCCESS id 1 len 43 msg is „CHAP authentication success, unit 13163“
000142: *Mar 15 10:51:50: Vi2 PPP: Phase is FORWARDING, Attempting Forward
000143: *Mar 15 10:51:50: Vi2 PPP: Phase is ESTABLISHING, Finish LCP
000144: *Mar 15 10:51:50: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
000145: *Mar 15 10:51:50: Vi2 PPP: No AAA accounting method list
000146: *Mar 15 10:51:50: Vi2 PPP: Phase is UP
000147: *Mar 15 10:51:50: Vi2 IPCP: Protocol configured, start CP. state[Initial]
000148: *Mar 15 10:51:50: Vi2 IPCP: Event[OPEN] State[Initial to Starting]
000149: *Mar 15 10:51:50: Vi2 IPCP: O CONFREQ [Starting] id 1 len 10
000150: *Mar 15 10:51:50: Vi2 IPCP:    Address 0.0.0.0 (0x030600000000)
000151: *Mar 15 10:51:50: Vi2 IPCP: Event[UP] State[Starting to REQsent]
000152: *Mar 15 10:51:50: Vi2 IPCP: I CONFREQ [REQsent] id 162 len 10
000153: *Mar 15 10:51:50: Vi2 IPCP:    Address a.a.a.a (0x030657BAE067)
000154: *Mar 15 10:51:50: Vi2 IPCP: O CONFACK [REQsent] id 162 len 10
000155: *Mar 15 10:51:50: Vi2 IPCP:    Address a.a.a.a  (0x030657BAE067)
000156: *Mar 15 10:51:50: Vi2 IPCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
000157: *Mar 15 10:51:50: Vi2 IPCP: I CONFNAK [ACKsent] id 1 len 10
000158: *Mar 15 10:51:50: Vi2 IPCP:    Address b.b.b.b (0x03065DC67EC5)
000159: *Mar 15 10:51:50: Vi2 IPCP: O CONFREQ [ACKsent] id 2 len 10
000160: *Mar 15 10:51:50: Vi2 IPCP:    Address b.b.b.b (0x03065DC67EC5)
000161: *Mar 15 10:51:50: Vi2 IPCP: Event[Receive ConfNak/Rej] State[ACKsent to ACKsent]
000162: *Mar 15 10:51:51: Vi2 IPCP: I CONFACK [ACKsent] id 2 len 10
000163: *Mar 15 10:51:51: Vi2 IPCP:    Address b.b.b.b (0x03065DC67EC5)
000164: *Mar 15 10:51:51: Vi2 IPCP: Event[Receive ConfAck] State[ACKsent to Open]
000165: *Mar 15 10:51:51: Vi2 IPCP: State is Open
000166: *Mar 15 10:51:51: Di1 IPCP: Install negotiated IP interface address b.b.b.b

Die IP Interface Brief-Summary nun auch die erfolgreiche Zuweisung der öffentlichen IP adresse:

asl1#sh ip int brief | i Di
Dialer1                    a.a.a.aYES IPCP   up                    up

 

 

Wireshark: TCP-Verbindungsaufbau loggen

Bei einer Migration eines Servers bietet es sich an, vorab zu prüfen in wie weit bzw. von wo noch Connections aufgebaut werden.

Die Lösung ist Wireshark. Hiermit kann z. B. bei einem alten SMTP-Server ohne Mühe identifiziert werden, woher ggf. noch SMTP-Sessions kommen und wo ggf. noch ein SMTP-Server (meistens Altsystem auf welche noch nicht via FQDN zugegriffen wird) geändert werden muss. Das folgende Beispiel zeigt, wie lediglich die ersten zwei Stufen des Verbindungsaufbaus einer TCP-Session anhand einer SMTP-Session gegen einen Mailbox-Server protokolliert werden.

Nach der regulären Wireshark-Installation auf dem Zielsystem kann man unter via „Capture Interfaces“ die „Capture Optionen“ editieren.

MX01A_Capture_Interfaces

Ausgewählt wird nun das Interface, welches beispielsweise den SMTP-Listner gebunden hat.

Der zu vergebene Dateiname ist das Präfix der Dateien, welche dann von Wireshark erzeugt werden – es wird automatisch noch eine Iterations- und Datumsinformation ergänzt. Es bietet sich an, diese Dateien z. B. direkt auf ein Share zu packen.

Via „use multiple files“ und „next file every 1 hour“ kann nun pro Stunde ein .pcap erzeugt werden.

MX01A_Screen_Capture

Nun zum Capture Filter:

  • „tcp port smtp‘ … Wireshark soll nur tcp/25 betrachten
  • „host not 10.60.61.11“ … wäre z.B. ein zweiter Mailserver, ein Spam-Filter den ich in dem Moment nicht sehen möchte oder ggf. auch ein bekannter Host mit viel Traffic.
  • „tcp[0xd]&2=2“ … schneidet Pakete mit, wo das „SYN-Flag“ auf „1“ gesetzt ist

Diese werden nun mit „and“ verkettet und fertig ist der Capture Filter.

tcp[0xd]&2=2 and tcp port smtp and host not 10.60.61.11

Mit dem Klick auf Start beginnt Wireshark mit der Arbeit.

MX01A_Wireshark_RunningAuf dem Share beginnt Wireshark nun stündlich eine neue .pacp-Datei zu erstellen und schneidet dort lediglich die SYN und SYN/ACKs von Sessions auf tcp/25 mit. So lassen sich sehr schnell möglicherweise in einer Migration übersehene Geräte gerade ziehen.

Wichtige Anmerkung: Wireshark muss in einer interaktiven Session laufen währendes seine Arbeit verrichtet. Insofern sollte, währenddes Schneidens, das RDP Verbindungs-Timeout modifiziert werden, so dass es diese für die notwendige Zeit die Session nicht wegreißt.

Die Auswertung: möchte man sich auf dem Admin-PC die vielen .pacps anschauen, reicht es diese per Drag & Drop in Wireshark zu laden. Wireshark macht, sofern bei der Installation das Tool „mergecap“ installiert ist automatisch einen Merge und man kann mit der Analyse beginnen.

Abschließender Hinweis: Nutzung natürlich auf eigene Gefahr und ohne Gewähr.