Hallo Backslash,
bevor ich hier auf die 9.24.0252 umsteige (woanders habe ich die überall schon), will ich noch mit der 9.24.0244 bzw. sogar einer älteren 9.24.0191 (vom 01.02.2017 mit der ich nochmal getestet habe) abschließen und möchte an der Stelle nochmal ein paar Fragen stellen, danke schon mal fürs Lesen.
Ab und an bekomme ich in PRTG auch eine Warnung, dass die DHCP-Adresszuweisung erst im zweiten Anlauf geklappt hat. Das ist normal keine Störung, wird auch nicht als solche ausgegeben, der Sensor geht für die 10 Sek. nur in den Status Warnung und im Protokoll kann man dies später noch einsehen. Ich habe trotzdem mal gedacht, kannst ja mal schauen, was da denn war/ist, wo ich den Trace nun schon da habe. Nachfolgend ein Trace mit der 9.24.0244. Ich nehme nichts raus, der Trace ist also fortlaufend, ich mache zwischendurch nur meine Bemerkungen. Im Gegenteil, ich fange sogar recht früh an, weil ich nicht weiß, ob die Vorgeschichte Einflüsse auf das (Fehl-?)Verhalten hat.
Code: Alles auswählen
[ARP] 2017/05/12 08:41:09,213
ARP RX (LAN-1, INTRANET): ARP-REQ
SrcIp=10.10.10.10 @ 94:de:80:23:59:93
DstIp=10.10.10.1 @ 00:a0:57:22:aa:2d (LANCOM 22:aa:2d)
Cache-10.10.10.10 @ 94:de:80:23:59:93
Response Fwd to LAN-1, INTRANET
[ARP] 2017/05/12 08:41:10,541
ARP Aging
-10.10.10.10.
-10.10.10.15.
-10.10.10.33.
-31.17.200.254.
complete
Wie jetzt? Vor einer Sekunde gecacht und jetzt gleich gelöscht? Was soll das?
Code: Alles auswählen
[ARP] 2017/05/12 08:41:10,747
ARP : LAN-TX (LAN-1, INTRANET): ARP REQ for 10.10.10.10
Und da kommt dann auch schon die Frage auf, wie nochmal die MAC-Adresse war...
Code: Alles auswählen
[ARP] 2017/05/12 08:41:10,748
ARP RX (LAN-1, INTRANET): ARP-RESP
SrcIp=10.10.10.10 @ 94:de:80:23:59:93
DstIp=10.10.10.1 @ 00:a0:57:22:aa:2d (LANCOM 22:aa:2d)
Cache-10.10.10.10 @ 94:de:80:23:59:93
done
[ARP] 2017/05/12 08:41:12,247
ARP RX (LAN-1, INTRANET): ARP-REQ
SrcIp=10.10.10.14 @ 2c:59:e5:75:a6:c4
DstIp=10.10.10.10 @ 00:00:00:00:00:00 (Xerox 00:00:00)
Response discarded
[DHCP] 2017/05/12 08:41:14,800
DHCP Aging
DHCP Aging complete
[DHCP] 2017/05/12 08:41:35,685
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 10.10.10.10: DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 004FBA42 | Secs = FF00 | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 94 de 80 23 59 93 00 00 00 00 00 00 00 00 00 00
Bad options => frame discard
=> Tx ARP-Request for 10.10.10.10
Hier haben wir das (erste) DHCPDISCOVER von PRTG.
Code: Alles auswählen
[ARP] 2017/05/12 08:41:35,685
ARP : LAN-TX (LAN-1, INTRANET): ARP REQ for 10.10.10.10
Vor 25 Sek. bereits gefragt, aber ok, nehmen wir den aktuellen Stand der Dinge.
Code: Alles auswählen
[ARP] 2017/05/12 08:41:35,686
ARP RX (LAN-1, INTRANET): ARP-RESP
SrcIp=10.10.10.10 @ 94:de:80:23:59:93
DstIp=10.10.10.1 @ 00:a0:57:22:aa:2d (LANCOM 22:aa:2d)
Cache-10.10.10.10 @ 94:de:80:23:59:93
done
[DHCP] 2017/05/12 08:41:35,686
DHCP: ARP-Reply for 10.10.10.10
(no client match) => Discard
So, hier das Problem. Was ist da los? Wieso "no client match"?
(Oder meinst Du, es könnte sein, dass das "Bad options => frame discard" von weiter oben, bis hierhin Auswirkungen hat? Wie ich inzwischen rausgefunden habe, nachdem ich mal Wireshark angemacht habe, ist PRTG nämlich wohl auch nicht ganz sauber. Ich würde da weiter unten noch drauf eingehen.)
Code: Alles auswählen
[DHCP] 2017/05/12 08:41:45,826
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 10.10.10.10: DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 004FB89D | Secs = FF00 | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 94 de 80 23 59 93 00 00 00 00 00 00 00 00 00 00
unknown option: 245 | Len = 80 | Para: cb a4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 f6 19
Bad options => frame discard
=> Tx ARP-Request for 10.10.10.10
So, hier dann nach 10 Sek. das zweite DISCOVER.
Code: Alles auswählen
[ARP] 2017/05/12 08:41:45,827
ARP : LAN-TX (LAN-1, INTRANET): ARP REQ for 10.10.10.10
[ARP] 2017/05/12 08:41:45,828
ARP RX (LAN-1, INTRANET): ARP-RESP
SrcIp=10.10.10.10 @ 94:de:80:23:59:93
DstIp=10.10.10.1 @ 00:a0:57:22:aa:2d (LANCOM 22:aa:2d)
Cache-10.10.10.10 @ 94:de:80:23:59:93
done
[DHCP] 2017/05/12 08:41:45,828
DHCP: ARP-Reply for 10.10.10.10
=> Tx DHCPOFFER
Und was war nun anders?! Wenn ich noch irgendwie was anders tracen soll, einfach Bescheid geben...
Code: Alles auswählen
[DHCP] 2017/05/12 08:41:45,828
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: DHCPOFFER
Op = 02 | HType = 01 | HLen = 06 | Hops = 00
XId = 004FB89D | Secs = FF00 | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 10.10.10.10
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 94 de 80 23 59 93 00 00 00 00 00 00 00 00 00 00
Server-ID: 10.10.10.1
Netmask: 255.255.255.0
Gateway: 10.10.10.1
DNS-Server: 10.10.10.1
Hostname: Server
Domain: intranet.xyz
Broadcast: 10.10.10.255
NBNS-Server: (none)
Leasetime: 86400
Option 42: 10.10.10.1
So, das war's erst mal hierzu.
Jetzt noch kurz zur 9.24.0191, die seinerzeit bei mir sehr lange im Februar lief und die haufenweise Lease-Time-Fehler produziert hat (zugewiesene Lease-Time von 771764400 Sek.), die mir damals aber gewissermaßen durch die Lappen gegangen sind, weil ich für die Lease-Time in PRTG keine Werte hinterlegt hatte für "gut und schlecht". Der Sensor lief ein wenig unbeobachtet vor sich her, weil ich ihn erst mal nur so mit den Standardeinstellungen hinzugefügt hatte. Seit zwei, fast drei Tagen habe ich die Firmware hier laufen, ohne dass das Phänomen mal wieder auftreten würde. PRTG unverändert, LCOS wie damals, aber das Problem tritt nicht auf. Vermutlich fehlen äußere Umstände, die damals zu dem Verhalten geführt haben. Ich habe das Syslog mal an Tagen durchgeschaut, wo 80 % der Messungen fehlerhaft waren, aber ich konnte da jetzt nichts erkennen, was nicht heute auch irgendwo ist. Ein iPhone drehte seinerzeit ziemlich durch und obwohl lange Lease-Time holte sich das Ding alle paar Minuten ein neues Lease. Wen das interessiert:
https://www.net.princeton.edu/apple-ios ... often.html Ist nicht mehr so taufrisch der Artikel, aber wenn ich in Hotels einen DHCP-Trace laufen habe, dann scheinen noch einige iPhones unterwegs zu sein, die derartig das WLAN zumüllen. Aber zurück zum Thema: Ich konnte das Phänomen nicht sichten, aber was ich gesehen habe ist, dass seinerzeit der DHCP noch anders geantwortet hat, nämlich neben der Leasetime mit Renewal und Rebind (siehe nachfolgender Trace). Warum ist das Verhalten geändert worden? Und wieso findet sich das nicht in den Release-Notes? Oder ist die Änderung des Verhaltens gar nicht beabsichtigt und somit ein Bug?
Hier ein ACK mit mit der 9.24.0191:
Code: Alles auswählen
[DHCP] 2017/05/22 08:29:30,032
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: DHCPACK
Op = 02 | HType = 01 | HLen = 06 | Hops = 00
XId = 564DEF6A | Secs = 0000 | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 10.10.10.11
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 8c 70 5a d2 3c e0 00 00 00 00 00 00 00 00 00 00
Server-ID: 10.10.10.1
Client-ID: 01:8c:70:5a:d2:3c:e0
Netmask: 255.255.255.0
Gateway: 10.10.10.1
DNS-Server: 10.10.10.1
Hostname: ThinkPad
Domain: intranet.xyz
Broadcast: 10.10.10.255
TCP-WD: 0
NBNS-Server: (none)
Leasetime: 86400
Renewal: 43200
Rebind: 64800
Option 42: 10.10.10.1
Und hier das Gleiche mit der 9.24.0244:
Code: Alles auswählen
[DHCP] 2017/05/19 09:48:56,570
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: DHCPACK
Op = 02 | HType = 01 | HLen = 06 | Hops = 00
XId = D83F1F58 | Secs = 0000 | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 10.10.10.11
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 8c 70 5a d2 3c e0 00 00 00 00 00 00 00 00 00 00
Server-ID: 10.10.10.1
Client-ID: 01:8c:70:5a:d2:3c:e0
Netmask: 255.255.255.0
Gateway: 10.10.10.1
DNS-Server: 10.10.10.1
Hostname: ThinkPad
Domain: intranet.xyz
Broadcast: 10.10.10.255
NBNS-Server: (none)
Leasetime: 86400
Option 42: 10.10.10.1
So, jetzt noch mal ein paar Bemerkungen zum DHCPDISCOVER von PRTG mit "Bad options => frame discard", wie oben schon angekündigt. Irgendwie könnte ich mich ohrfeigen, nicht schon mal früher Wireshark angeschaltet zu haben. Das lag aber auch daran, dass ich anfangs irgendwie auf die Lease-Time fixiert war und alles andere gar nicht in Frage gestellt habe. Irgendwie scheinen ja trotzdem einige Fehlerbereinigungen bei raus gekommen zu sein. Insofern dann hier vielleicht die Auflösung? Ich weiß es nicht, es ist jedenfalls aufschlussreicher als vermutet.
Nachfolgend ein DHCPDISCOVER von PRTG (wie bisher von mir eingesetzt) im DHCP-Trace (LCOS 9.24.0191) und Wireshark-Trace (auf dem Server):
Code: Alles auswählen
[DHCP] 2017/05/22 22:41:34,741
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 10.10.10.10: DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 0053B406 | Secs = FF00 | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 94 de 80 23 59 93 00 00 00 00 00 00 00 00 00 00
unknown option: 218 | Len = 53 | Para: 4a 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 c2 0f
Bad options => frame discard
=> Tx DHCPOFFER
2017-05-22 23_31_08-RDP-Server.png
Muss ich noch was dazu sagen? Ich glaube nicht... Vielleicht so viel, die Option 53 ist markiert, sieht man auch unten, danach kommen nur noch Nullen.
Nachfolgend ein DHCPDISCOVER von PRTG (neuere Version) im DHCP-Trace (LCOS 9.24.0191) und Wireshark-Trace (auf dem Server):
Code: Alles auswählen
[DHCP] 2017/05/22 22:43:16,737
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 10.10.10.22: DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 00E7925A | Secs = 00FF | Flags = 8000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 1c 4b d6 1e ea 88 00 00 00 00 00 00 00 00 00 00
=> Tx DHCPOFFER
2017-05-22 23_41_45-RDP-Server.png
Vielen Dank und viele Grüße,
Jirka
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
