DynDNS.org Update Scripte ohne DNS-Check von LoUiS

Jirka · Beitrag von **Jirka** » 01 Jun 2007, 11:07

Hallo,

> Dddddas, scheint's gewesen zu sein.

Ich bin mir da noch nicht ganz so sicher - aber Du ja auch nicht ("scheint's").

Ich vermute ja, dass das Kabelmodem für diese private IP verantwortlich ist. Denn nach den nichtssagenden Bedienungsanleitungen für diese Modems von Motorola kann man auch mehrere Rechner direkt an das Modem anschließen, was ja bedeutet, dass das Modem irgendwo NAT machen muss und damit anfängt private IPs zu verteilen.
Im obigen Fall (gestern 17:08 Uhr) hattest Du auch einen Kaltstart des LANCOM durchgeführt. Mich würde noch mal interessieren, was passiert, wenn nur das Kabelmodem aus-/eingeschaltet wird und der LANCOM anbleibt. Kannst ja bei Gelegenheit mal ausprobieren.

> Wenn mir jetzt noch jemend netterweise den Unterschied dieser Einstellung erklären könnte, währe ich mal wieder wunschlos glücklich.

Ich weiß es, wie oben bereits geschrieben, auch nicht so hundertprozentig.

In der Hilfe von LANconfig steht: "Wählen Sie hier aus, welche MAC-Adresse verwendet werden soll. Muss für die Gegenstelle eine bestimmte MAC-Adresse (Benutzerdefiniert) definiert sein, so kann diese im folgenden Feld angegeben werden. Wird Lokal gewählt, so werden anhand der Geräte-MAC-Adresse weitere virtuelle Adressen für jede WAN-Verbindung gebildet. Wird Global gewählt, so wird die Geräte-MAC-Adresse für alle Verbindungen verwendet."

Der Sinn der Angabe ist folgender: Die Einstellung hat einen Einfluss auf die MAC-Adresse, die dort benutzt wird:

global -> die System-MAC-Adresse, also 00:a0:57:....
lokal -> wie oben, jedoch modifiziert als locally-administered (02:a0:57:...)

'lokal' ist nützlich, wenn aus irgendeinem Grund LAN und WAN auf einem Ethernet-Strang herauskommen und man einfach nur unterschiedliche, aber eindeutige Adressen braucht, damit die Switches nicht durcheinanderkommen, ohne sich gleich eine komplett eigene ausdenken zu müssen.

Folglich sollte das eigentlich bei Dir so ziemlich egal sein, was da eingestellt ist. Oder kann uns da jemand auf die Sprünge helfen?

Backslash, danke für Dein Posting, ich habe wie gesagt schon überlegt, ob nicht auch das Kabelmodem dafür verantwortlich ist.

Viele Grüße,
Jirka

Dungeonwatcher · Beitrag von **Dungeonwatcher** » 01 Jun 2007, 16:48

Jirka hat geschrieben:> Dddddas, scheint's gewesen zu sein.

Ich bin mir da noch nicht ganz so sicher - aber Du ja auch nicht ("scheint's").

Du sagst es.

Ich vermute ja, dass das Kabelmodem für diese private IP verantwortlich ist. Denn nach den nichtssagenden Bedienungsanleitungen für diese Modems von Motorola kann man auch mehrere Rechner direkt an das Modem anschließen, was ja bedeutet, dass das Modem irgendwo NAT machen muss und damit anfängt private IPs zu verteilen.
Im obigen Fall (gestern 17:08 Uhr) hattest Du auch einen Kaltstart des LANCOM durchgeführt. Mich würde noch mal interessieren, was passiert, wenn nur das Kabelmodem aus-/eingeschaltet wird und der LANCOM anbleibt. Kannst ja bei Gelegenheit mal ausprobieren.

Gerade eben getestet:

01.06.2007 16:44:55 mailto:xxxxxxx@gmx.de?subject=Update www.dungeon-bbs.de fehlgeschlagen?body=Das DNS-Update des FQDN www.dungeon-bbs.de mit der WAN-IP 192.168.100.11 ist fehlgeschlagen. Bitte pruefe die Konfiguration (derzeit inaktiver Account, fehlerhafte oder privat mail sent
01.06.2007 16:44:55 lastresult: status=412
01.06.2007 16:44:55 lastresult: status=412
01.06.2007 16:44:55 http://carol.selfhost.de/update?usernam ... 168.100.11 status=412
01.06.2007 16:44:55 lastresult: 88.134.2.80
01.06.2007 16:44:55 exec:getenv IPnameselfhostde

01.06.2007 16:40:04 repeat:300 timer started
01.06.2007 16:40:04 lastresult: DNS lookup failure
01.06.2007 16:40:04 lastresult: DNS lookup failure
01.06.2007 16:40:04 lastresult: DNS lookup failure
01.06.2007 16:40:04 lastresult: DNS lookup failure
01.06.2007 16:40:04 http://carol.selfhost.de/update?usernam ... 168.100.11 DNS lookup failure
01.06.2007 16:40:04 lastresult: 88.134.2.80
01.06.2007 16:40:04 exec:getenv IPnameselfhostde

Es funktioniert also doch nicht.

Jirka · Beitrag von **Jirka** » 01 Jun 2007, 17:48

Hi,

hmm.

Schade. Wär zu schön gewesen.

Ok, was nun?
Erstmal würde mich noch mal die ganz exakte Bezeichnung des Kabelmodems interessieren, vom Motorola Surfboard gibt es verschiedene Typen.
Und weiterhin sollten wir jetzt den von Backslash vorgeschlagenen DHCP-Trace durchführen. Dazu logst Du Dich per Telnet auf den 1511 ein und gibst dann trace # dhcp ein. Dann schaltest Du das Kabelmodem aus und wieder ein und postest dann hier in einem "Code-Feld" das Ergebnis. Ich hoffe mal das passt platzmäßig soweit, ansonsten musst Du die Fensterpuffergröße hochstellen oder musst das mit PuTTY machen, kennst das Programm? Damit kann man den Output gleich in eine Textdatei schreiben lassen.

Viele Grüße,
Jirka

Dungeonwatcher · Beitrag von **Dungeonwatcher** » 01 Jun 2007, 18:41

Jirka hat geschrieben:Erstmal würde mich noch mal die ganz exakte Bezeichnung des Kabelmodems interessieren, vom Motorola Surfboard gibt es verschiedene Typen.

Es nennt sich genau SURFBoard SB5100E

Und weiterhin sollten wir jetzt den von Backslash vorgeschlagenen DHCP-Trace durchführen.

Code: Alles auswählen

[DHCP] 2007/06/01 18:34:44,670
DHCP Client Tx (WAN): 
DHCP Client Message (request) to 255.255.255.255: DHCPDISCOVER
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 06A3 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Client-ID       : 01:02:a0:57:0f:d1:a8
ReqIP           : 0.0.0.0
Hostname        : Watcher
Option List     : 1 2 3 4 6 7 44
Vendor-Class-ID : LANCOM 1511 Wireless DSL


[DHCP] 2007/06/01 18:34:47,670
DHCP Client Tx (WAN): 
DHCP Client Message (request) to 255.255.255.255: DHCPDISCOVER
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 06A3 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Client-ID       : 01:02:a0:57:0f:d1:a8
ReqIP           : 0.0.0.0
Hostname        : Watcher
Option List     : 1 2 3 4 6 7 44
Vendor-Class-ID : LANCOM 1511 Wireless DSL


[DHCP] 2007/06/01 18:34:56,670
DHCP Client Tx (WAN): 
DHCP Client Message (request) to 255.255.255.255: DHCPDISCOVER
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 06A3 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Client-ID       : 01:02:a0:57:0f:d1:a8
ReqIP           : 0.0.0.0
Hostname        : Watcher
Option List     : 1 2 3 4 6 7 44
Vendor-Class-ID : LANCOM 1511 Wireless DSL


[DHCP] 2007/06/01 18:34:56,670
DHCP Client Rx (WAN): 
DHCP Server Message (reply) to 0.0.0.0: DHCPOFFER
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =   192.168.100.11
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Server-ID       : 192.168.100.1
Netmask         : 255.255.255.0
Leasetime       : 20


[DHCP] 2007/06/01 18:34:56,670
DHCP Client Tx (WAN): 
DHCP Client Message (request) to 255.255.255.255: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 06A3 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Client-ID       : 01:02:a0:57:0f:d1:a8
Server-ID       : 192.168.100.1
ReqIP           : 192.168.100.11
Hostname        : Watcher
Leasetime       : 20
Option List     : 1 2 3 4 6 7 44
Vendor-Class-ID : LANCOM 1511 Wireless DSL


[DHCP] 2007/06/01 18:34:56,670
DHCP Client Rx (WAN): 
DHCP Server Message (reply) to 0.0.0.0: DHCPACK
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =   192.168.100.11
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Server-ID       : 192.168.100.1
Netmask         : 255.255.255.0
Leasetime       : 20


[DHCP] 2007/06/01 18:35:10,170
DHCP Client Tx (WAN): 
DHCP Client Message (request) to 192.168.100.1: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 06A3 | Flags = 0000
  CIAdr =   192.168.100.11 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Client-ID       : 01:02:a0:57:0f:d1:a8
Hostname        : Watcher
Leasetime       : 20
Option List     : 1 2 3 4 6 7 44
Vendor-Class-ID : LANCOM 1511 Wireless DSL


[DHCP] 2007/06/01 18:35:10,170
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 192.168.100.1: DHCPNACK
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 0000 | Flags = 0000
  CIAdr =   192.168.100.11 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:10,170
DHCP Client Rx (WAN): 
DHCP Server Message (reply) to 0.0.0.0: DHCPNACK
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = A0E94B84 | Secs  = 0000 | Flags = 0000
  CIAdr =   192.168.100.11 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Server-ID       : 192.168.100.1
Netmask         : 255.255.255.0
Leasetime       : 20


[DHCP] 2007/06/01 18:35:11,010
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 91.64.252.82: DHCPOFFER (Server is relay-agent)
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 00004180 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =     10.6.220.217
  SIAdr =   83.169.184.113 | GIAdr =     91.64.252.82
  CHAdr = 00 11 80 9d 20 06 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:13,070
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 91.64.252.82: DHCPACK (Server is relay-agent)
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 00004180 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =     10.6.220.217
  SIAdr =   83.169.184.113 | GIAdr =     91.64.252.82
  CHAdr = 00 11 80 9d 20 06 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:18,890
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 91.64.252.82: DHCPOFFER (Server is relay-agent)
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = B470CFF5 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =     88.134.3.251
  SIAdr =          0.0.0.0 | GIAdr =     91.64.252.82
  CHAdr = 00 e0 4c e6 ab 54 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:18,950
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 91.64.252.82: DHCPACK (Server is relay-agent)
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = B470CFF5 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =     88.134.3.251
  SIAdr =          0.0.0.0 | GIAdr =     91.64.252.82
  CHAdr = 00 e0 4c e6 ab 54 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:19,170
DHCP Client Tx (WAN): 
DHCP Client Message (request) to 255.255.255.255: DHCPDISCOVER
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 283A52E1 | Secs  = 06C6 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Client-ID       : 01:02:a0:57:0f:d1:a8
ReqIP           : 0.0.0.0
Hostname        : Watcher
Option List     : 1 2 3 4 6 7 44
Vendor-Class-ID : LANCOM 1511 Wireless DSL


[DHCP] 2007/06/01 18:35:19,180
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 91.64.252.82: DHCPOFFER (Server is relay-agent)
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 283A52E1 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =      88.134.2.80
  SIAdr =          0.0.0.0 | GIAdr =     91.64.252.82
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:19,180
DHCP Client Rx (WAN): 
DHCP Server Message (reply) to 0.0.0.0: DHCPOFFER
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 283A52E1 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =      88.134.2.80
  SIAdr =          0.0.0.0 | GIAdr =     91.64.252.82
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Server-ID       : 83.169.184.50
Leasetime       : 2936
Netmask         : 255.255.252.0
Option 2       : 00 00 0e 10
Gateway         : 88.134.3.254
DNS-Server      : 83.169.184.33, 83.169.184.97, 10.10.10.252
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 


[DHCP] 2007/06/01 18:35:19,180
DHCP Client Tx (WAN): 
DHCP Client Message (request) to 255.255.255.255: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 283A52E1 | Secs  = 06C6 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Client-ID       : 01:02:a0:57:0f:d1:a8
Server-ID       : 83.169.184.50
ReqIP           : 88.134.2.80
Hostname        : Watcher
Leasetime       : 2936
Option List     : 1 2 3 4 6 7 44
Vendor-Class-ID : LANCOM 1511 Wireless DSL


[DHCP] 2007/06/01 18:35:19,190
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 91.64.252.82: DHCPACK (Server is relay-agent)
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 283A52E1 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =      88.134.2.80
  SIAdr =          0.0.0.0 | GIAdr =     91.64.252.82
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:19,190
DHCP Client Rx (WAN): 
DHCP Server Message (reply) to 0.0.0.0: DHCPACK
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 283A52E1 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =      88.134.2.80
  SIAdr =          0.0.0.0 | GIAdr =     91.64.252.82
  CHAdr = 02 a0 57 0f d1 a8 00 00 00 00 00 00 00 00 00 00

Server-ID       : 83.169.184.50
Leasetime       : 2936
Netmask         : 255.255.252.0
Option 2       : 00 00 0e 10
Gateway         : 88.134.3.254
DNS-Server      : 83.169.184.33, 83.169.184.97, 10.10.10.252
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 
Option 0       : 


[DHCP] 2007/06/01 18:35:21,850
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 91.64.252.82: DHCPACK (Server is relay-agent)
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = F4BC4867 | Secs  = 0000 | Flags = 8000
  CIAdr =     88.134.17.42 | YIAdr =     88.134.17.42
  SIAdr =          0.0.0.0 | GIAdr =     91.64.252.82
  CHAdr = 00 02 44 bd 6a 58 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:21,870
DHCP Rx (INTERNET): 
DHCP Server Message (reply) from 91.64.252.82: DHCPACK (Server is relay-agent)
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = F4BC4867 | Secs  = 0000 | Flags = 8000
  CIAdr =     88.134.17.42 | YIAdr =     88.134.17.42
  SIAdr =          0.0.0.0 | GIAdr =     91.64.252.82
  CHAdr = 00 02 44 bd 6a 58 00 00 00 00 00 00 00 00 00 00

 => forwarded to internal DHCP-Client

[DHCP] 2007/06/01 18:35:25,180
DHCP Aging 
complete

COMCARGRU · Beitrag von **COMCARGRU** » 01 Jun 2007, 18:41

Hi Jirka,

unter Windows reicht auch ein "telnet IP-Adresse -f Laufwerk/Pfad/Dateianme.abk" um die ganze Telnet Session in eine Logdatei zu schreiben - PuTTY wäre da schon umständlich, wenn er es nicht kennt.

Gruß
COMCARGRU

Jirka · Beitrag von **Jirka** » 02 Jun 2007, 18:52

Hallo an alle,

hi COMCARGRU, danke für den Tipp, wieder was dazugelernt

So, das Datenblatt zum Motorola SURFboard SB5100E findet sich hier (pdf). Die Bedienungsanleitung (mit der man nicht viel anfangen kann) befindet sich hier (pdf). Das Kabelmodem bietet die Möglichkeit bis zu 32 Computer per NAT mit dem Internet zu verbinden. Daher hat das Gerät auch einen eingebauten DHCP-Server. Ist aber nur ein Gerät am Kabelmodem, so bekommt dieses die öffentliche IP. Solange das Kabelmodem noch nicht eingebucht ist, bekommt man wohl eine private IP aus dem Bereich 192.168.100.11 bis 192.168.100.42. Über die Seite http://192.168.100.1 kann man das Modem konfigurieren (die Einstellungen können aber evt. wieder überschrieben werden, wenn sich das Kabelmodem per TFTP vom Provider eine neue Konfig holt ..., somit halte ich eine veränderte Konfiguration an dieser Stelle, um das eigentliche Problem zu lösen, für nicht so gut).

Der DHCP-Trace sieht doch erst mal ganz gut aus, oder? Die Leasedauer der privaten IP ist mit 20 Sekunden recht gering und zeigt, dass diese Zuweisung tatsächlich nur für eine kurze Zeit geplant ist. Nach dem DHCPREQUEST des LANCOM kommt dann ein DHCPNAK und dann erfolgt die Aushandlung der neuen IP. Was sagst Du dazu Backslash? Das Kabelmodem verhält sich doch korrekt, oder?

Wie würde eigentlich der Übergang von einer öffentlichen IP zu einer neuen (anderen) öffentlichen IP vonstatten gehen? So wie Dungeonwatcher schreibt, kommt das ja auch ab und an mal vor. Dann müßte ja das Kabelmodem die ETH-Verbindung kurz kappen, damit ein "nahtloser" Übergang gewährleistet ist, tut es das? Denn ansonsten müsste ja erst die Leasetime ablaufen. Hmm. Abenteuerlich. Könnte man höchstens über die Polling-Tabelle erschlagen das Problem. Dungeonwatcher, Du meintest weiter oben ja, dass dieses Problem (IP-Wechsel und dann erst mal "offline") seit LCOS 6.32 nicht mehr auftritt, wodran hast Du das gemerkt?

Vielen Dank und viele Grüße,
Jirka

Dungeonwatcher · Beitrag von **Dungeonwatcher** » 02 Jun 2007, 20:51

'n Abend!

Jirka hat geschrieben:Dungeonwatcher, Du meintest weiter oben ja, dass dieses Problem (IP-Wechsel und dann erst mal "offline") seit LCOS 6.32 nicht mehr auftritt, wodran hast Du das gemerkt?

Wenn KDG neue IP Adressen verteilte, dann bekam der LC diese auch korrekt zugeteilt. Allerdings kam anschließend kein Rechner aus dem LAN in's WAN und umgekehrt. Der LC selber konnte über das LAN angesprochen werden. Nach einem Neustart (egal ob Warm- oder Kaltstart) des LC funktionierte dies dann wieder. Mit der aktuellen FW taucht dieses Problem nicht mehr auf. Egal wie oft KDG seine IPs ändert, sowie der LC eine zugeteilt bekommen hat, kommt auch jeder wieder per LAN in's WAN, ohne Neustart des LC.

backslash · Beitrag von **backslash** » 03 Jun 2007, 16:24

Hi Jirka

Der DHCP-Trace sieht doch erst mal ganz gut aus, oder? Die Leasedauer der privaten IP ist mit 20 Sekunden recht gering und zeigt, dass diese Zuweisung tatsächlich nur für eine kurze Zeit geplant ist. Nach dem DHCPREQUEST des LANCOM kommt dann ein DHCPNAK und dann erfolgt die Aushandlung der neuen IP. Was sagst Du dazu Backslash? Das Kabelmodem verhält sich doch korrekt, oder?

der Trace sieht OK aus.

@Dungeonwatcher:

Baut das LANCOM beim Adreßwechsel die Verbindung ab oder bleibt sie wider erwarten bestehen?

Gruß
Backslash

Dungeonwatcher · Beitrag von **Dungeonwatcher** » 03 Jun 2007, 17:59

Hi!

backslash hat geschrieben:Baut das LANCOM beim Adreßwechsel die Verbindung ab oder bleibt sie wider erwarten bestehen?

Hmmm, das kann ich so auf die Schnelle nicht sagen. Bisher habe ich einen Adresswechsel nie live miterlebt, außer ich schalte das Modem aus/ein. Ich wüsste jetzt auch nicht wie ich einen Adressewechsel provozieren kann ohne das LC oder das Modem auszuschalten? Reicht es evtl. das Zuleitungskabel TV-Dose -> Modem kurz zu trennen?

Bye/2 (der jetzt mit der Nachtschicht beginnt

)

Jirka · Beitrag von **Jirka** » 04 Jun 2007, 14:25

Hallo Backslash,

> Baut das LANCOM beim Adreßwechsel die Verbindung ab oder bleibt sie wider erwarten bestehen?

Meinst Du jetzt den Adresswechsel von einer öffentlichen IP zu einer neuen anderen öffentlichen IP?
Also wenn schon der Wechsel von der privaten IP zu einer öffentlichen ohne Verbindungsab- und -aufbau vonstatten geht (sonst würde ja das Aktions-Tabellen-Script 20 Sek. nach einschalten des Kabelmodems neu starten und das tut es bei Dungeonwatcher ja nicht), dann gehe ich davon aus, dass es beim Wechsel von öffentlich zu öffentlich auch nicht anders aussieht. Im Prinzip war das ja der Grund, warum sich Dungeonwatcher am 26.05. erneut gemeldet hat: "Leider hat das Script bei mir heute [...] versagt, denn es wurde überhaupt nicht gestartet als sich KDG mal wieder entschloss mit den IPs rumzuspielen." Unter der Annahme, dass Dungeonwatcher wirklich in die "Status"-Aktions-Tabelle geschaut hat, kann man also davon ausgehen, dass hier kein Verbindungsab- und -aufbau stattgefunden hat (ansonsten hätte das Script ja auch ordentlich aktualisiert).

Wenn man es genau nimmt, haben wir hier wahrscheinlich einen Grund gefunden, der dazu führt, dass Selfhost mir mitteilte, dass von LANCOMs (mit dem Standardscript) unnötige Updates durchgeführt werden. Denn wenn man unter dieser Konstellation an das Standardscript denkt, wird nach einem IP-Wechsel alle 15 Min. - aus Sicht von Selfhost völlig unnötig - ein Update durchgeführt, es wird immer wieder die gleiche IP übermittelt, die leider nicht die tatsächliche WAN-IP ist. (Komisch ist nur, dass Dungeonwatcher bisher der einzige ist, der bemerkt hat, dass da was mit der DynDNS-Aktualisierung nicht hinhaut, immerhin ist KDG ja nun so selten auch nicht verbreitet ...)

Viele Grüße,
Jirka

Dungeonwatcher · Beitrag von **Dungeonwatcher** » 04 Jun 2007, 17:05

Moin!

Jirka hat geschrieben:Unter der Annahme, dass Dungeonwatcher wirklich in die "Status"-Aktions-Tabelle geschaut hat,

Jupp, er hat es definitiv. Das war rein zufällig, aber ich habe es mehrmals reproduziert.

kann man also davon ausgehen, dass hier kein Verbindungsab- und -aufbau stattgefunden hat (ansonsten hätte das Script ja auch ordentlich aktualisiert).

Hmmm, so gesehen, hast du wohl recht.

Wenn man es genau nimmt, haben wir hier wahrscheinlich einen Grund gefunden, der dazu führt, dass Selfhost mir mitteilte, dass von LANCOMs (mit dem Standardscript) unnötige Updates durchgeführt werden. Denn wenn man unter dieser Konstellation an das Standardscript denkt, wird nach einem IP-Wechsel alle 15 Min. - aus Sicht von Selfhost völlig unnötig - ein Update durchgeführt, es wird immer wieder die gleiche IP übermittelt, die leider nicht die tatsächliche WAN-IP ist.

Das hatte ich allerdings nie im Einsatz.

(Komisch ist nur, dass Dungeonwatcher bisher der einzige ist, der bemerkt hat, dass da was mit der DynDNS-Aktualisierung nicht hinhaut, immerhin ist KDG ja nun so selten auch nicht verbreitet ...)

Oha, wenn das meine Koll. lesen, wird deren Meinung "Dungeonwatcher der 'böse' Betatester..." wieder bestärkt.

Neee, im Ernst, ich betreibe ein kleines unscheinbares unwichtiges Forum und wenn da mal für wenige Minuten der Zugang nicht funktioniert, bimmelt schon mein Telefon...

Bei KDG hat man zwar eine quasi feste IP, nur manchmal tun deren Server leider auch mächtig rumoren und diese ändert sich im Viertelstundentakt. Da währe eine funktionierende DynDNS-Aktualisierung schon nicht schlecht.

Mal so eine Idee als DAU.

Ist es denn möglich die Abfrage "myip=%a" so zu gestalten, das wenn eine IP "192.168.*.*" ergibt, diese solange zu wiederholen, bis es eine andere (öffentliche) IP ergibt.

Dungeonwatcher · Beitrag von **Dungeonwatcher** » 15 Jun 2007, 17:03

Hi große Meister!

Dungeonwatcher hat geschrieben:Mal so eine Idee als DAU.
Ist es denn möglich die Abfrage "myip=%a" so zu gestalten, das wenn eine IP "192.168.*.*" ergibt, diese solange zu wiederholen, bis es eine andere (öffentliche) IP ergibt.

Es ist auf einmal so ruhig geworden?

Ist diese meine Idee so abwegig.

Der nächste IP Wechsel dürfte mich vermutlich am 25.06. treffen, dann stellt KDG meinen Tarif um und bisher gab's auch jedesmal 'ne neue IP. Es währe echt suuuper wenn wir bis dahin eine Lösung hätten.

Bye/2

backslash · Beitrag von **backslash** » 15 Jun 2007, 18:51

Hi Dungeonwatcher

wende dich doch mal an den LANCOM-Support und laß die eine aktuelle 6.36 schicken. Die baut nun wirklich bei einem DHCPNAK die Verbindung ab.

Bei Jirkas Skript wirst du nach einem Kaltstart des Modems zwar immer noch die Mail bekommen, daß das dyndns-Update fehlgeschlagen ist, dann wird aber nach 10 Sekunden vom Modem getrennt und du bekommst eine neue IP und das update müßte funktionieren.

Um die Mail zu unterbinden müßtest du es schaffen, in dem Skript den dyndns-Update um 10 Sekunden zu verzögern...

Gruß
Backslash

Jirka · Beitrag von **Jirka** » 15 Jun 2007, 21:01

Hi Dungeonwatcher, hi Backslash,

backslash hat geschrieben:Bei Jirkas Skript wirst du nach einem Kaltstart des Modems zwar immer noch die Mail bekommen, daß das dyndns-Update fehlgeschlagen ist,

Das nehme ich nicht an. Ich kenne mich nicht so mit Kabelmodems aus, denke aber, dass diese auch synchronisieren müssen. Während der LANCOM-Router die private IP vom Kabelmodem zugewiesen bekommt, ist somit das Kabelmodem noch am synchronisieren. Und deswegen wird eine private IP mit kurzer Leasedauer zugewiesen. Das Script versucht dann natürlich schon ein Update (da für den LANCOM-Router die Verbindung aufgebaut ist), aber das scheitert dann am fehlenden Gateway bzw. an der fehlenden Verbindung ins Internet. Somit liefert der Updateversuch "DNS lookup failure", was zu einem erneuten Versuch in 5 Min. führt. Da daraufhin bei Zuweisung der öffentlichen IP nun aber die Verbindung ab- und wieder aufgebaut wird, erfolgt dann gleich der nächste Versuch. So kann man es auch im letzten Zitatfenster des Postings von Dungeonwatcher hier http://www.lancom-forum.de/ptopic,31223.html#31223 erkennen.
Folglich nehme ich an, dass dann alles klappen sollte.

Viele Grüße,
Jirka

Dungeonwatcher · Beitrag von **Dungeonwatcher** » 15 Jun 2007, 21:08

backslash hat geschrieben:wende dich doch mal an den LANCOM-Support und laß die eine aktuelle 6.36 schicken. Die baut nun wirklich bei einem DHCPNAK die Verbindung ab.

Das tue ich doch sofort.

Bei Jirkas Skript wirst du nach einem Kaltstart des Modems zwar immer noch die Mail bekommen, daß das dyndns-Update fehlgeschlagen ist, dann wird aber nach 10 Sekunden vom Modem getrennt und du bekommst eine neue IP und das update müßte funktionieren.

Warten wir's mal ab.

Bye/2