DHCP-Server antwortet mit bad address requested - DHCPNAK?

Jirka · Beitrag von **Jirka** » 17 Apr 2017, 17:57

DHCP-Server antwortet mit bad address requested - ist das ein korrektes DHCPNAK?

Hallo zusammen,

ich wollte mal nachfragen, ob sich der LANCOM DHCP-Server (Firmware 9.24.0231) korrekt verhält oder ob etwa Windows 10 in der neuesten Version irgendwas falsch macht in folgender Situation: Der (Windows-)Client erhält vom (LANCOM-)DHCP-Server ein DHCP-Lease mit der IP 10.10.13.80 (Lease-Time 1 Tag). Das gefällt mir jedoch nicht und so habe ich kurz darauf die MAC-Adresse des Clients in die BOOTP-Tabelle eingetragen und ihm die IP 10.10.13.10 zugewiesen. Man muss an dieser Stelle der Vollständigkeit halber erwähnen, dass in der BOOTP-Tabelle für die 10.10.13.10 bereits ein Eintrag bestand, den ich geändert habe. (Es gab aber natürlich keinen aktiven Client mit der IP-Adresse 10.10.13.10.)
Der Windows-Client wurde nun komplett neu gestartet. Darauf, dass ich ihn über die gewünschte IP-Adresse 10.10.13.10 erreichen könnte, konnte ich aber lange warten. Es tat sich nichts. Weiterer Neustart. Immer noch nichts. Völlig verzweifelt ein Kaltstart des LANCOM-Routers. Anschließend nochmals ein Neustart des Windows-Clients. Immer noch nichts. Nun dachte ich, jetzt reichts, was ist denn da los? Also DHCP-Trace gestartet:

Code: Alles auswählen

[DHCP] 2017/04/14 14:23:12,538
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = FE2D6112 | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:40:8d:5c:b1:1e:08
Req.-IP:         10.10.13.80 => ignored (static assigned address 10.10.13.10)
Hostname:        Dach
unknown option:  81 | Len =   7 | Para: 00 00 00 44 61 63 68
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 121 249 252
 (bad address requested) => Tx DHCPNAK

[DHCP] 2017/04/14 14:23:12,538
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: BOOTP
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = FE2D6112 | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00
Server-ID:   10.10.13.1
Client-ID:   01:40:8d:5c:b1:1e:08
Server-Msg:  bad address requested

[DHCP] 2017/04/14 14:23:13,450
DHCP Aging
DHCP Aging complete

[DHCP] 2017/04/14 14:23:17,548
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = FE2D6112 | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:40:8d:5c:b1:1e:08
Req.-IP:         10.10.13.80 => ignored (static assigned address 10.10.13.10)
Hostname:        Dach
unknown option:  81 | Len =   7 | Para: 00 00 00 44 61 63 68
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 121 249 252
 (bad address requested) => Tx DHCPNAK

[DHCP] 2017/04/14 14:23:17,548
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: BOOTP
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = FE2D6112 | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00
Server-ID:   10.10.13.1
Client-ID:   01:40:8d:5c:b1:1e:08
Server-Msg:  bad address requested

[DHCP] 2017/04/14 14:23:21,560
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = FE2D6112 | Secs  = 0400 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:40:8d:5c:b1:1e:08
Req.-IP:         10.10.13.80 => ignored (static assigned address 10.10.13.10)
Hostname:        Dach
unknown option:  81 | Len =   7 | Para: 00 00 00 44 61 63 68
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 121 249 252
 (bad address requested) => Tx DHCPNAK

[DHCP] 2017/04/14 14:23:21,561
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: BOOTP
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = FE2D6112 | Secs  = 0400 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00
Server-ID:   10.10.13.1
Client-ID:   01:40:8d:5c:b1:1e:08
Server-Msg:  bad address requested

[DHCP] 2017/04/14 14:23:29,578
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = FE2D6112 | Secs  = 0C00 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:40:8d:5c:b1:1e:08
Req.-IP:         10.10.13.80 => ignored (static assigned address 10.10.13.10)
Hostname:        Dach
unknown option:  81 | Len =   7 | Para: 00 00 00 44 61 63 68
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 121 249 252
 (bad address requested) => Tx DHCPNAK

[DHCP] 2017/04/14 14:23:29,578
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: BOOTP
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = FE2D6112 | Secs  = 0C00 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00
Server-ID:   10.10.13.1
Client-ID:   01:40:8d:5c:b1:1e:08
Server-Msg:  bad address requested

[DHCP] 2017/04/14 14:23:44,585
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 4832D9D3 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:40:8d:5c:b1:1e:08
Req.-IP:         10.10.13.80 => ignored (static assigned address 10.10.13.10)
Hostname:        Dach
unknown option:  81 | Len =   7 | Para: 00 00 00 44 61 63 68
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 121 249 252
 (bad address requested) => Tx DHCPNAK

[DHCP] 2017/04/14 14:23:44,585
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: BOOTP
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 4832D9D3 | Secs  = 0000 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00
Server-ID:   10.10.13.1
Client-ID:   01:40:8d:5c:b1:1e:08
Server-Msg:  bad address requested

[DHCP] 2017/04/14 14:23:47,587
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 4832D9D3 | Secs  = 0300 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:40:8d:5c:b1:1e:08
Req.-IP:         10.10.13.80 => ignored (static assigned address 10.10.13.10)
Hostname:        Dach
unknown option:  81 | Len =   7 | Para: 00 00 00 44 61 63 68
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 121 249 252
 (bad address requested) => Tx DHCPNAK

[DHCP] 2017/04/14 14:23:47,587
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: BOOTP
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 4832D9D3 | Secs  = 0300 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00
Server-ID:   10.10.13.1
Client-ID:   01:40:8d:5c:b1:1e:08
Server-Msg:  bad address requested

[DHCP] 2017/04/14 14:23:56,591
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 4832D9D3 | Secs  = 0C00 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:40:8d:5c:b1:1e:08
Req.-IP:         10.10.13.80 => ignored (static assigned address 10.10.13.10)
Hostname:        Dach
unknown option:  81 | Len =   7 | Para: 00 00 00 44 61 63 68
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 121 249 252
 (bad address requested) => Tx DHCPNAK

[DHCP] 2017/04/14 14:23:56,592
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: BOOTP
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 4832D9D3 | Secs  = 0C00 | Flags = 8000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00
Server-ID:   10.10.13.1
Client-ID:   01:40:8d:5c:b1:1e:08
Server-Msg:  bad address requested

[DHCP] 2017/04/14 14:24:13,450
DHCP Aging
DHCP Aging complete

[DHCP] 2017/04/14 14:25:13,450
DHCP Aging
DHCP Aging complete

Ist das soweit korrekt? Oder nicht?
Es geht weiter, anschließend auch mit Ethernet-Trace, um wirklich sicher zu gehen, was hier vor sich geht:

Code: Alles auswählen

[DHCP] 2017/04/14 14:30:46,974
DHCP Rx (LAN-1, INTRANET):
DHCP Client Message (request) from 0.0.0.0: DHCPREQUEST
  Op    = 01       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 5A5F1B9B | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00

Client-ID:       01:40:8d:5c:b1:1e:08
Req.-IP:         10.10.13.80 => ignored (static assigned address 10.10.13.10)
Hostname:        Dach
unknown option:  81 | Len =   7 | Para: 00 00 00 44 61 63 68
Vendor-Class-ID: MSFT 5.0
Option List      1 3 6 15 31 33 43 44 46 47 121 249 252
 (bad address requested) => Tx DHCPNAK

[DHCP] 2017/04/14 14:30:46,974
DHCP Tx (LAN-1, INTRANET):
DHCP Server Message (reply) to 255.255.255.255: BOOTP
  Op    = 02       | HType = 01   | HLen  = 06   | Hops  = 00
  XId   = 5A5F1B9B | Secs  = 0000 | Flags = 0000
  CIAdr =          0.0.0.0 | YIAdr =          0.0.0.0
  SIAdr =          0.0.0.0 | GIAdr =          0.0.0.0
  CHAdr = 40 8d 5c b1 1e 08 00 00 00 00 00 00 00 00 00 00
Server-ID:   10.10.13.1
Client-ID:   01:40:8d:5c:b1:1e:08
Server-Msg:  bad address requested

... (das wiederholt sich jetzt etliche Male, deswegen jetzt zum Ethernet-Trace)

[Ethernet] 2017/04/14 14:33:35,313
Received 342 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-4
IPv4 Hdr Checksum   : OK
IP Proto Checksum   : OK
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : 40:8d:5c:b1:1e:08
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 328
ID                  : 10974
Fragment            : Offset 0
TTL                 : 128
Protocol            : UDP
Checksum            : 3784 (OK)
Src Address         : 0.0.0.0
Dest Address        : 255.255.255.255
-->UDP Header
Src Port            : BOOTPC
Dest Port           : BOOTPS
Length              : 308
Checksum            : 25739 (OK)
-->BOOTP Packet
Operation           : Request
Hardware Type       : Ethernet
Hardware Length     : 6
Hops                : 0
Transaction ID      : 0xd8398a60
Seconds             : 0
Flags               :
Client Address      : 0.0.0.0
Your Address        : 0.0.0.0
Server Address      : 0.0.0.0
Gateway Address     : 0.0.0.0
Client HW Address   : 40:8d:5c:b1:1e:08
Server Name         :
Boot File Name      :
Magic Cookie        : 0x63825363
-->DHCP Options
Message-Type        : Request
Client-ID           : 01 40 8d 5c b1 1e 08    .@.\...
Requested-Address   : 10.10.13.80
Host-Name           : Dach
Unknown(81)         : 00 00 00 44 61 63 68    ...Dach
Vendor-Class        : 4d 53 46 54 20 35 2e 30 MSFT 5.0
Request-List        : Netmask
                      Gateway
                      DNS-Server
                      Domain
                      Router-Discovery
                      Static-Routes
                      Vendor-Specific
                      NBNS-Server
                      NetBIOS-Type
                      NB-Scope
                      Unknown(121)
                      Unknown(249)
                      Unknown(252)
Trailer             : ff 00                   ..


[Ethernet] 2017/04/14 14:33:35,317
Sent 342 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-4
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : 00:a0:57:23:96:e8 (LANCOM 23:96:e8)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 328
ID                  : 27815
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 63987 (OK)
Src Address         : 10.10.13.1
Dest Address        : 255.255.255.255
-->UDP Header
Src Port            : BOOTPS
Dest Port           : BOOTPC
Length              : 308
Checksum            : 33435 (OK)
-->BOOTP Packet
Operation           : Reply
Hardware Type       : Ethernet
Hardware Length     : 6
Hops                : 0
Transaction ID      : 0xd8398a60
Seconds             : 0
Flags               :
Client Address      : 0.0.0.0
Your Address        : 0.0.0.0
Server Address      : 0.0.0.0
Gateway Address     : 0.0.0.0
Client HW Address   : 40:8d:5c:b1:1e:08
Server Name         :
Boot File Name      :
Magic Cookie        : 0x63825363
-->DHCP Options
Server-Identifier   : 10.10.13.1
Client-ID           : 01 40 8d 5c b1 1e 08    .@.\...
Message             : bad address requested
Trailer             : ff 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00       ......

...

[Ethernet] 2017/04/14 14:33:40,347
Received 342 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-4
IPv4 Hdr Checksum   : OK
IP Proto Checksum   : OK
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : 40:8d:5c:b1:1e:08
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 328
ID                  : 10975
Fragment            : Offset 0
TTL                 : 128
Protocol            : UDP
Checksum            : 3783 (OK)
Src Address         : 0.0.0.0
Dest Address        : 255.255.255.255
-->UDP Header
Src Port            : BOOTPC
Dest Port           : BOOTPS
Length              : 308
Checksum            : 25739 (OK)
-->BOOTP Packet
Operation           : Request
Hardware Type       : Ethernet
Hardware Length     : 6
Hops                : 0
Transaction ID      : 0xd8398a60
Seconds             : 0
Flags               :
Client Address      : 0.0.0.0
Your Address        : 0.0.0.0
Server Address      : 0.0.0.0
Gateway Address     : 0.0.0.0
Client HW Address   : 40:8d:5c:b1:1e:08
Server Name         :
Boot File Name      :
Magic Cookie        : 0x63825363
-->DHCP Options
Message-Type        : Request
Client-ID           : 01 40 8d 5c b1 1e 08    .@.\...
Requested-Address   : 10.10.13.80
Host-Name           : Dach
Unknown(81)         : 00 00 00 44 61 63 68    ...Dach
Vendor-Class        : 4d 53 46 54 20 35 2e 30 MSFT 5.0
Request-List        : Netmask
                      Gateway
                      DNS-Server
                      Domain
                      Router-Discovery
                      Static-Routes
                      Vendor-Specific
                      NBNS-Server
                      NetBIOS-Type
                      NB-Scope
                      Unknown(121)
                      Unknown(249)
                      Unknown(252)
Trailer             : ff 00                   ..


[Ethernet] 2017/04/14 14:33:40,351
Sent 342 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-4
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : 00:a0:57:23:96:e8 (LANCOM 23:96:e8)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 328
ID                  : 30185
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 61617 (OK)
Src Address         : 10.10.13.1
Dest Address        : 255.255.255.255
-->UDP Header
Src Port            : BOOTPS
Dest Port           : BOOTPC
Length              : 308
Checksum            : 33435 (OK)
-->BOOTP Packet
Operation           : Reply
Hardware Type       : Ethernet
Hardware Length     : 6
Hops                : 0
Transaction ID      : 0xd8398a60
Seconds             : 0
Flags               :
Client Address      : 0.0.0.0
Your Address        : 0.0.0.0
Server Address      : 0.0.0.0
Gateway Address     : 0.0.0.0
Client HW Address   : 40:8d:5c:b1:1e:08
Server Name         :
Boot File Name      :
Magic Cookie        : 0x63825363
-->DHCP Options
Server-Identifier   : 10.10.13.1
Client-ID           : 01 40 8d 5c b1 1e 08    .@.\...
Message             : bad address requested
Trailer             : ff 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00       ......

Ich meine sicherlich hat das ursprüngliche DHCP-Lease mit der 10.10.13.80 noch Gültigkeit, aber dass es so schwer ist, das wieder weg zu bekommen, das kenne ich aus meinen bisherigen Erfahrungen nicht. Einen Tag später hatte der PC dann übrigens endlich die gewünschte IP-Adresse.

Vielen Dank und viele Grüße,
Jirka

Dr.Einstein · Beitrag von **Dr.Einstein** » 17 Apr 2017, 19:26

Hi Jirka,

sieht für mich nach einem DHCP Client Fehler aus. Der Client fragt explizit nach seiner letzten ihm bekannten IP Adresse und möchte diese wieder bekommen (Req.-IP: 10.10.13.80), dies ist ein völlig legitimes DHCP Verhalten. Dies wird dann auch völlig korrekt vom Lancom mit DHCPNAK quittiert, da die angefragte IP nicht verfügbar ist. Jetzt müsste der DHCP Client nach ein zwei Fehlversuchen die Requested IP auf 0.0.0.0 umstellen, tut er aber nicht. Vermutlich hätte ein DHCP Release / Renew im Client gereicht. Das lustige ist, mit Windows Server Betriebssystemen habe ich dein Verhalten auch schon mehrfach festgestellt, Lancom unabhängig (auch nach Boot des Servers). Bei festgefressener IP Adresse zB beim iPhone half immer ein Neustart.

Gruß Dr.Einstein

Jirka · Beitrag von **Jirka** » 18 Apr 2017, 13:16

Hallo Dr. Einstein,

vielen Dank für Deine Antwort.

Dr.Einstein hat geschrieben:Dies wird dann auch völlig korrekt vom Lancom mit DHCPNAK quittiert

Das ist genau meine Frage, ob das wirklich so völlig korrekt ist. Ich dachte, man würde da ein "DHCPNAK" so auch im Antwortpaket sehen. Ich glaube Dir das gerne, dass das so völlig korrekt ist. Wenn mir das noch jemand bestätigen würde, wäre ich mir sicherer, dass es damit ein Fehler im Client ist (oder zumindest ein gewisses unerwünschtes Verhalten, wenn der Client sich auf das zugeteilte, jedoch mittlerweile überholte, DHCP-Lease beruft).

Ich habe auch mal in die RFCs geschaut. Normal könnte ich z. B. beim Monitoren des DHCP-Servers im LANCOM mit PRTG auch die Antwort des DHCP-Servers mit PRTG auswerten, also ob z. B. die gewünschte IP zugewiesen wird oder ob die Antwort überhaupt vom gewünschten DHCP-Server kommt (ist ja auch nicht ganz unwichtig). Das letztere funktioniert auch bei den üblichen DHCP-Servern. LANCOM aber z. B. übergibt die eigene IP (also die DHCP-Server-IP-Adresse) nicht im Standard-Feld (Server Address), sondern im Server-Identifier unter DHCP Options. Kann man machen... Ich kann damit aber die Adresse nicht prüfen, bzw. prüfe auf die 0.0.0.0. Gewisse Sachen sind also Auslegungssache. Da ich nicht den kompletten Überblick über DHCP habe und auch nicht die Zeit, mich damit zu beschäftigen, weil noch so viele andere Probleme anliegen, frage ich einfach, ob das Verhalten so ok ist.

Dr.Einstein hat geschrieben:Vermutlich hätte ein DHCP Release / Renew im Client gereicht.

Kann sein. Ich habe mich auch schon gefragt, warum ich es nicht - zumindest nach dem Trace - nicht damit probiert habe. Aber mir saß etwas die Zeit im Nacken. Dazu kommt, dass ich oftmals DHCP-Umstellungen vornehmen muss und dann gar nicht die Zeit oder den Zugriff habe, ein Renew durchzuführen. Da gehe ich davon aus, und das war meiner Ansicht nach auch bisher so der Fall, dass wenn ich mal eben das Ethernet deaktiviere oder das WLAN und die Clients sich dann wieder neu verbinden, dass sie sich dann die von mir gewünschte IP holen, auch wenn sie theoretisch noch ein gültiges Lease haben. Es gibt sogar WLAN-Clients, die nach jedem Roaming-Vorgang erst mal ein DHCP-Request durchführen, weil es Leute gab, die eine gleiche WLAN-SSID für ein unterschiedliches Netzwerk genutzt haben und das auch unmittelbar nebeneinander...

Dr.Einstein hat geschrieben:Das lustige ist, mit Windows Server Betriebssystemen habe ich dein Verhalten auch schon mehrfach festgestellt

Hmm. Das war jetzt hier ein einfaches Windows 10 Prof.

Vielen Dank und viele Grüße,
Jirka

backslash · Beitrag von **backslash** » 18 Apr 2017, 15:59

Hi Jirka,

das LANCOM sagt im Trace zwar, daß es bit einem DHCPNAK antwortet will (=> Tx DHCPNAK), im dann getracten Paket fehlt aber offensichtlich die Message-Option und das Paket wird als BOOTP-Paket ausgegeben. Da ist wohl ein kleiner Bug...

Gruß
Backslash

Koppelfeld · Beitrag von **Koppelfeld** » 18 Apr 2017, 16:38

Hi Jirka,
unglaublich, was Du so alles herausfindest ...

Jirka hat geschrieben:
Dr.Einstein hat geschrieben:Vermutlich hätte ein DHCP Release / Renew im Client gereicht.
Kann sein. Ich habe mich auch schon gefragt, warum ich es nicht - zumindest nach dem Trace - nicht damit probiert habe. Aber mir saß etwas die Zeit im Nacken.

Lustigerweise hatte ich heute *genau* das gleiche Problem. In meinem Falle half es aber, den Lease im Lancom zu löschen.

Dazu kommt, dass ich oftmals DHCP-Umstellungen vornehmen muss und dann gar nicht die Zeit oder den Zugriff habe, ein Renew durchzuführen. Da gehe ich davon aus und das war meiner Ansicht nach aus bisher auch so der Fall, dass wenn ich mal eben das Ethernet deaktiviere oder das WLAN und die Clients sich dann wieder neu verbinden, dass sie sich dann die von mir gewünschte IP holen, auch wenn sie theoretisch noch ein gültiges Lease haben.

Die Antwort von Backslash habe ich zur Kenntnis genommen und bestimmt wird der Fehler demnächst behoben.

ABER:
Erwäge doch einmal, bei komplexeren Setups die fabelhafte "DHCPRELAY" - Option der Lancoms zu nutzen und, beispielsweise auf Basis Debian, einen "großen" DHCP- und DNS - Server einzurichten.
Die Axt im Haus erspart den Zimmermann und grep+syslog erspart den PRTG. Und den freiwerdenden Server würde ich für Infrastrukturdienste nutzen.

Jirka · Beitrag von **Jirka** » 19 Apr 2017, 03:22

Hallo Backslash,

danke, dass Du Dir es angeschaut hast und den Fehler gefunden hast.

Hallo Koppelfeld,

Koppelfeld hat geschrieben:Erwäge doch einmal, bei komplexeren Setups die fabelhafte "DHCPRELAY" - Option der Lancoms zu nutzen

es ist nicht so, dass ich überall den LANCOM DHCP-Server nutze. Eher im Gegenteil. Als ich vor 4 Monaten mal ein gewisses Verhalten an anderen Stellen verifizieren wollte, musste ich feststellen, dass weit mehr als die Hälfte der LANCOM-Router bei mir gar kein DHCP an haben...
Allerdings verrichtet in den meisten Fällen ein Windows-Server dann diesen Dienst.

Koppelfeld hat geschrieben:beispielsweise auf Basis Debian, einen "großen" DHCP- und DNS - Server einzurichten.

Wenn Du auch mal greifbar wärst, dann könnte man drüber nachdenken. Ich alleine schaffe es nicht, mich um zig Systeme zu kümmern, ich muss ja auch noch Geld verdienen und nicht nur Einarbeitung und Troubleshooting betreiben.

Koppelfeld hat geschrieben:Die Axt im Haus erspart den Zimmermann und grep+syslog erspart den PRTG.

Letzteres erspart definitiv nicht PRTG! Syslog schön und gut, das mache ich natürlich mit Benachrichtigung und allem Drum und dran. Aber das zeigt mir nicht auf, dass der RAM flöten geht, dass ein Call hängt, dass die CPU-Last am Anschlag ist, dass der LANCOM-DHCP-Server von der 9.24.0153RU3 auf die 9.24.0187 irgendwie modifiziert wurde und urplötzlich wie aus dem Nichts in einigen Fällen utopische Lease-Times verteilt (ein Trace dazu habe ich noch nicht gemacht).

Koppelfeld hat geschrieben:Und den freiwerdenden Server würde ich für Infrastrukturdienste nutzen.

Die da wären?
Dass der Server nicht nur PRTG macht, dürfte ja wohl klar sein.

Vielen Dank und viele Grüße,
Jirka

Koppelfeld · Beitrag von **Koppelfeld** » 19 Apr 2017, 10:31

Hallo Jirka,

Jirka hat geschrieben:
Koppelfeld hat geschrieben:Erwäge doch einmal, bei komplexeren Setups die fabelhafte "DHCPRELAY" - Option der Lancoms zu nutzen
es ist nicht so, dass ich überall den LANCOM DHCP-Server nutze. Eher im Gegenteil. Als ich vor 4 Monaten mal ein gewisses Verhalten an anderen Stellen verifizieren wollte, musste ich feststellen, dass weit mehr als die Hälfte der LANCOM-Router bei mir gar kein DHCP an haben...
Allerdings verrichtet in den meisten Fällen ein Windows-Server dann diesen Dienst.

... bis der Kunde ein Lizenz-Audit bekommt. Dann erscheinen zwei Rechtsanwälte und ein Techniker: "Schöne neue Feuermelder haben Sie da. Ach, die benutzen unseren DHCP-Server? Das wird aber jetzt teuer.". Nein, kein Witz.

Jirka hat geschrieben:
Koppelfeld hat geschrieben:beispielsweise auf Basis Debian, einen "großen" DHCP- und DNS - Server einzurichten.
Wenn Du auch mal greifbar wärst, dann könnte man drüber nachdenken. Ich alleine schaffe es nicht, mich um zig Systeme zu kümmern, ich muss ja auch noch Geld verdienen und nicht nur Einarbeitung und Troubleshooting betreiben.

Du sollst ja GERADE mit der Implementierung Geld verdienen.

Ein LANCOM - Router ist KEINE "Fritzbox". Natürlich müssen die Jungs einen DHCP-Server drin haben. Und einen DNS-Server. Aber die eingebauten Minimallösungen ersetzen nicht "richtige" Implementierungen. Beispiel DHCP: Da braucht man oft gerätespezifische DHCP-Optionen. Beispiel DNS: Da hätte man gerne ein (auch 'negatives') Caching.
Ein "Voice Call Manager" ist auch nicht als Telephonanlage zu verwenden.

Es ist richtig und gut, daß LANCOM die ISDN-Schnittstellen anbietet, um noch bestehende Altanschlüsse während der Restlaufzeit zu bedienen und danach sauber auf VoIP umzustellen. Ein vollwertiges ISDN<-->SIP - Gateway ist das nicht, da nimmst Du einen PATTON. Nur ein Stichwort: Uhrzeitsynchronistation. Und, weil es so schön ist: "Partial Rerouting".

Auch das "Aufbohren" der Firewall ist nicht umbedingt schlau. Denn auch die neue LANCOM - Firewall läßt ganz elementare Dinge vermissen, besipielsweise die Möglichkeit der durchgängigen, transparenten Verwendung der Objektnamen, die außerhalb der FW-Konfig angelegt werden.

Es ist super, nicht nur für uns, sondern auch für LANCOM, daß Du so viele Bugs aufspürst und weitgehend einkreist.

Ob man aber wirklich alle angebotenen Features in einem Gerät nutzen sollte ? Meine Antwort ist nein.
Der LANCOM ist ein guter Access-Router, das, was Bintec einmal war. Man kann damit viele Dinge tun, die mit so einer verschwiemelten "Watchguard" überhaupt nicht gehen, Stichwort "'echte' DMZ".
Aber wie sagte Scotty: "Für jeden Zweck das richtige Werkzeug".

Jirka hat geschrieben:
Koppelfeld hat geschrieben:Die Axt im Haus erspart den Zimmermann und grep+syslog erspart den PRTG.
Letzteres erspart definitiv nicht PRTG! Syslog schön und gut, das mache ich natürlich mit Benachrichtigung und allem Drum und dran. Aber das zeigt mir nicht auf, dass der RAM flöten geht, dass ein Call hängt, dass die CPU-Last am Anschlag ist,

Ja, das hört sich super an. Und Dir glaube ich sogar die gute Absicht. Und ich schäme mich, die nächsten drei Worte zu schreiben: 'In Deinem Alter' fand ich das auch alles ganz klasse. Da habe ich Steuerungen für Kunststoffanlagen gebaut.
Für jeden Prozess gab es ein "P&ID", 'Process & Identification Diagram'. Eine zeitlang habe wir da alles möglich an Meß- und Überwachungstechnik 'reingepackt. Weil wir den Prozess kennenlernen und optimieren wollten, weil wir die Chefin ärgern wollten (Juristin), welche behauptete, unsere Welt bestehe nur aus übergroßen Egos und einem "Fischertechnik-Baukasten für sexuell unausgeglichene Freaks". Das ging so lange gut, bis dann irgendwann einmal der Herr Pfesdorf von der Zimmer AG bei mir erschien und mir mein P&ID gnadenlos um die Ohren haute. Mit den Worten: "Ein Hund rennt, seinem Jagdtrieb folgend, hinter einem Motorrad her. Irgendwann hat er es eingeholt. Was macht er jetzt mit dem Motorrad ? Und Sie benehmen sich genau so blöd wie ein triebgesteuerter Köter. Sie vergessen dabei:
- quis custodiet ipsos custodes ?
- es ist großer Bockmist, irgendwelche Ausnahmebedingungen anzuzeigen, wenn Sie nicht darauf reagieren können.
- Sie bekämpfen Komplexität mit Komplexität. Damit machen Sie den Kunden nicht unabhängig, sondern abhängig von Ihrem Geraffel.
- Sie geben dem Bediener das Gefühl, Sie hätten das "idiotensichere" System gebaut. Aber erstens ist der Bediener gar kein Idiot (der sind Sie) und zweitens "verläßt" er sich auf Ihr System, wird unvorsichtig und produziert so bei nächster Gelegenheit maximalen Schaden.
- Sie veruntreuen das Geld für teure Überwachungstechnik, um Ihre persönliche Spielwiese zu bepflanzen.
- Durch die Aufzeichnung aller möglicher Unstände liefern Sie unter Umständen auch noch Ihren eigenen Auftraggeber ans Messer.
Zitatende. Damals war ich 32, ich bin erstmal aufs Klo, habe ausgiebig gekotzt, geheult und mit viel Wasser nachgespült.
Denn der Mann hatte genau recht. Und er gab mir eine zweite Chance. Das P&ID, vorher auf A1 geplottet, paßte auf einmal auf eine A3-Blatt. Und diese Anlage läuft bis heute.
So viel zum Thema "Lessons learned".

Laß' andere monitoren. Du bist so intelligent, eigensichere Systeme hinzukriegen. Und die Pfesdorfs dieser Welt sind knapp geworden, aber es gibt sie noch. Gottseidank.

COMCARGRU · Beitrag von **COMCARGRU** » 19 Apr 2017, 11:24

Zimmer AG

Zimmer AG? Anlagenbau? Frankfurt? - Die sind aber schon lange "dicht" - ist bei Air Liquide S.A. überhaupt noch etwas von Zimmer AG und Lurgi übrig?

Koppelfeld · Beitrag von **Koppelfeld** » 19 Apr 2017, 11:42

COMCARGRU hat geschrieben:
Zimmer AG
Zimmer AG? Anlagenbau? Frankfurt? - Die sind aber schon lange "dicht" - ist bei Air Liquide S.A. überhaupt noch etwas von Zimmer AG und Lurgi übrig?

Ein echtes Trauerspiel. Hatte neulich in der Gegend zu tun und wollte dann 'mal in der Borsigallee 1 vorbeigucken. Da wurden die Reste des Hauptgebäudes gerade zum Schutt gefahren.

Die sind zu oft verkauft worden. Lurgi, AL ... Zimmer war allerdings einer der letzten mir bekannten "Turn-Key" - Lieferanten für komplette Kunststoff-Fertigungslinien - von der Polyesterproduktion über Extrusion bis zur Verspinnung ("Zimmer Microfaser"). Und die hatten verdammt gute Leute. Wenn man dort nichts über Sicherheitstechnik lernte, dann nirgendwo.
Echt, ich will wieder zurück in den lauten Fabrikhallendreck.

COMCARGRU · Beitrag von **COMCARGRU** » 19 Apr 2017, 11:55

Fertigungslinien - von der Polyesterproduktion über Extrusion bis zur Verspinnung ("Zimmer Microfaser")

Ich war da mal als WUM (Werks-Unabhängiger-Mitarbeiter) - oder nutzte Lurgi dieses WUM? - tätig. Und ich erinnere mich sehr gut an den Projektleiter. Der war nämlich von der Arbeit der Zimmer AG alles andere als überzeugt. Das war Ende der 1990er. Über die Anlage an der ich beteiligt war sagte er: "Wir planen hier eine Anlage, von der wir nicht Wissen ob der Prozess überhaupt funktioniert."

Hab gerade mal das "große" Internet befragt - die Anlage ging tatsächlich in Betrieb und kaum zwei Jahre später in die Insolvenz...

Hach fast 20 Jahre her - das waren Zeiten...

Koppelfeld · Beitrag von **Koppelfeld** » 19 Apr 2017, 12:33

COMCARGRU hat geschrieben:Ich war da mal als WUM (Werks-Unabhängiger-Mitarbeiter) - oder nutzte Lurgi dieses WUM? - tätig. Und ich erinnere mich sehr gut an den Projektleiter. Der war nämlich von der Arbeit der Zimmer AG alles andere als überzeugt. Das war Ende der 1990er. Über die Anlage an der ich beteiligt war sagte er: "Wir planen hier eine Anlage, von der wir nicht Wissen ob der Prozess überhaupt funktioniert."

Das war nicht zufällig das Projekt, das als Codename den Vornamen der russischen Übersetzerin bekommen hatte? Da war ich zuständg für die Farb-Masterbatch-Trocknung. Und wie ich gehört habe, hat das Werk nach einiger Zeit dichtgemacht.
Die großtechnische Umsetzumg eines im Labor mit Kleinmengen realisierten Prozesses ist *immer* ein Fall, von dem man nicht weiß, ob er funktioniert. Wenn dann noch extreme klimatische Bedingungen dazukommen...

Weil es so schön war und "fast" OnTopic, hier ein besonders schöne Klinke, die kein Überwachungssystem findet: In einem anderen Zimmer-Projekt beschwerte sich der Anfahrleiter, eine meiner Regelungen würde grauslich alternieren mit einer Temperaturschwankung von fast 10 K.
Ausgelegt war das Ding auf 0.2 K. Hingeflogen, nachgesehen, stimmte. Tagelang gesucht. Die Oktabins mit dem Ausschußmaterial füllten die halbe Halle. Und dann sind wir eher durch Zufall darauf gekommen, daß bei der Montage ein Meßrohr, in dem sich ein Pt100-Widerstandsthermometer befand, gekürzt und mit einem Distanzstück an einen versetzten DN100-Flansch adaptiert worden war.
Bis etwa 17 m/s kannst Du in einer gezogenen Rohrleitung einen Luftstrom laminar führen, ab dieser Grenze ergibt sich eine Zirkularströmug. Die führte dann zu einer erhöhten Reibung zwischen Prozessgas und Thermometer, die indizierte Temperatur stieg abrupt um 5 K und die steilflankig ausgelegte P-Komponente des Reglers machte dicht. Dadurch sank die Dichte des Prozeßgases und somit auch der Volumenstrom, sodaß die 17 m/s unterschritten wurden. In der Laminarströmung adaptierte sich die indizierte Temperatur wieder an die realen Bedingungen, der Regler drehte auf und der circulus vitiosus begann von neuem.

Momente, die begeistern, zumal sich diese "Kippelposition" nur ganz selten einstellte.

Da kannst Du vorher so sorgfältig gearbeitet haben wie Du willst -- da hilft Dir keiner aus der Scheiße, vor allem nicht die stukadierten QS-Weiber...

cpuprofi · Beitrag von **cpuprofi** » 19 Apr 2017, 12:42

Hallo Koppelfeld,

Koppelfeld hat geschrieben:...Laß' andere monitoren. Du bist so intelligent, eigensichere Systeme hinzukriegen...

dem ersten Punkt möchte ich widersprechen, dem zweiten nicht:

Nur durch (extremes) Monitoring und Tracen kann man Fehler in komplexen Systemen einkreisen, anders hat man keine Chance!

Deine ach so "intelligenten Kunden" haben den Nachteil, sie sind Menschen! Und Menschen haben die "Angewohnheit" ersten "ungeduldig zu sein", zweitens "nie was gemacht zu haben" und drittens "nie Schuld an einer Misere zu sein" und viertens "dann noch dreist zu lügen"...

Das sollte Dir auch bekannt sein und wie begegnest Du diesem Problem? Mit Monitoring!

Grüße
Cpuprofi

Koppelfeld · Beitrag von **Koppelfeld** » 19 Apr 2017, 13:15

cpuprofi hat geschrieben: Nur durch (extremes) Monitoring und Tracen kann man Fehler in komplexen Systemen einkreisen

Als Arbeitstier und humanoider Paginierstempel vielleicht. Ich bin Regenmacher.

anders hat man keine Chance!

Ich habe ein gesundes Bauchgefühl. Das mir z.B. sagt, "NIEMALS LCOS 10.x installieren".
Das spart mir nicht nur das Tracen, sondern dem Kunden auch das Versuchskaninchenstadium.

Deine ach so "intelligenten Kunden" haben den Nachteil, sie sind Menschen! Und Menschen haben die "Angewohnheit" ersten "ungeduldig zu sein", zweitens "nie was gemacht zu haben" und drittens "nie Schuld an einer Misere zu sein" und viertens "dann noch dreist zu lügen"...

Das sollte Dir auch bekannt sein und wie begegnest Du diesem Problem? Mit Monitoring!

Der Großteil meiner Kunden ist schwer in Ordnung.
Ich überwache meine Kunden nicht. Die wollen Lösungen von mir.

COMCARGRU · Beitrag von **COMCARGRU** » 19 Apr 2017, 13:27

Das war nicht zufällig das Projekt, das als Codename den Vornamen der russischen Übersetzerin bekommen hatte? Da war ich zuständg für die Farb-Masterbatch-Trocknung. Und wie ich gehört habe, hat das Werk nach einiger Zeit dichtgemacht.

Denke nicht - gebaut wurde das Ding Landkreis Havelland - wird aber Langsam OT fürchte ich

cpuprofi · Beitrag von **cpuprofi** » 19 Apr 2017, 13:56

Hallo Koppelfeld,

Koppelfeld hat geschrieben:...Ich habe ein gesundes Bauchgefühl...Das spart mir nicht nur das Tracen, sondern dem Kunden auch das Versuchskaninchenstadium...

das sehen z.B. Telekommunikationsanbieter anders, da kommst Du mit Deinem "Bauchgefühl" nicht weiter, wenn Du denen erstmal noch Beweisen musst, dass die einen Fehler in Ihrem "System" haben...

Koppelfeld hat geschrieben:...Der Großteil meiner Kunden ist schwer in Ordnung.
Ich überwache meine Kunden nicht. Die wollen Lösungen von mir...

Du hast ja mehrheitlich auch nur mittlere und große Kunden, aber bei Deinen wenigen kleinen Kunden hast Du auch so Deine Probleme. Außerdem überwache ich meine Kunden nicht, sondern nur das Verhalten der Geräte. So kommt es öfters vor, dass ein Kunde sagt, zum Zeitpunkt x ging y nicht und ich darf dann raten was war. Oder ein anderes Beispiel: Bei einer Kundin viel unregelmäßig immer die Telefonie aus und ich und der Lancom-Router seien dafür Schuld, kein Anderer käme dafür in Frage! Aber was war es wirklich gewesen? Die Putzfrau war "so schlau" die Steckdose im Server-"Räumchen" zu nehmen, damit sie im Flur Staubsaugen kann. Das in dieser Steckdose eine Verlängerungskabel steckte, an welchem die ganze TK-Anlage hing, war ihr egal. Wahlweise hätte sie auch die Steckdose daneben nehmen können, dann wäre halt die IT Ausgefallen... Aber wie schon erwähnt, LAncom und ich sollten Schuld sein...

Anderes Beispiel: Mein Kunde Dr. L. aus Stade, da konnte ich, dank Monitoring und Tracen, nachweisen, dass die Telekom Bockmist in ihren IMS-Routing-Einstellungen gemacht hatte. Es dauerte drei Monate, bevor die Telekom ihren Fehler eingesehen hatte und diesen korrigierte. Vorher hieß es immer: "Wir machen keine Fehler!".

Wie Du siehst, ist Monitoring schon als "Selbstschutz" sinnvoll.

Grüße
Cpuprofi

LANCOM-Forum.de

DHCP-Server antwortet mit bad address requested - DHCPNAK?

DHCP-Server antwortet mit bad address requested - DHCPNAK?

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA

Re: DHCP-Server antwortet mit bad address requested - DHCPNA