In einem separaten Test zieht sich der TVstick/Gen2 mit DHCP für alle privaten Netze (Klasse A,B,C) eine dyn.IPv4 korrekt, wenn die FritzBox als Router sowohl das WLAN aufspannt und der DHCP-Dienst einen DHCPOFFER anbieten kann.

In privaten Netzen verwendbare Adressbereiche sind: 

Klasse A: 10.0.0.0 bis 10.255.255.255.

Klasse B: 172.16.0.0 bis 172.31.255.255.

Klasse C: 192.168.0.0 bis 192.168.255.255.

PROBLEM / FEHLER:

Der MagentaTVstick erhält keine dynamische IPv4/DHCP, wenn der Router / die FritzBox (7490_07.60) mit DHCP so konfiguriert ist, dass für den Magenta-TVstick keine IPv4 reserviert ist bzw. vergeben werden kann. An der FritzBox ist der DHCP-Dienst nur aktiv, um das Netz für den Router zu bestimmen. Alle relevanten DHCPOFFER kommen von einem zweiten DHCP-Dienst im LAN, z.B. einem pi-hole.

Die Situation:

An einer (weiteren) FritzBox mit WLAN im IP-Client-Modus (Accesspoint) zieht sich der MagentaTVstick die dyn.IPv4 über DHCP nicht vom zweiten / zusätzlichen DHCP-Dienst, der auf einem pi-hole läuft.

Vermutlich hat der Stick in der Firmware einen Fehler im DHCP-Handshake (Discover, Offer, Request, Acknowledge) oder ein sehr kurzes Timing. Offensichtlich fällt "during SELECTING state" mit "multiple DHCPOFFER" der TVstick/Firmware die falsche (nicht die beste) Entscheidung. Sofern überhaupt berücksichtigt wurde, dass DHCPDISCOVER auf Layer 2 bei allen DHCP-Diensten im LAN ankommen muss, um dann entweder positiv oder gar nicht beantwortet zu werden.

Clients send DHCPREQUEST messages as follows:

o DHCPREQUEST generated during SELECTING state:

"Note that the client may choose to collect several DHCPOFFER

messages and select the "best" offer. The client indicates its

selection by identifying the offering server in the DHCPREQUEST

message. If the client receives no acceptable offers, the client

may choose to try another DHCPDISCOVER message." page 30, RFC 2131

"When a server receives a DHCPDISCOVER message from a client, the

server chooses a network address for the requesting client. If no

address is available, the server may choose to report the problem to

the system administrator." page 26, RFC 2131

"It is important for all DHCP servers to return the same

parameters (with the possible exception of a newly allocated network

address) to ensure predictable client behavior regardless of which

server the client selects." page 28, RFC 2131

"The server MAY choose to return the 'vendor class identifier' used to

determine the parameters in the DHCPOFFER message to assist the

client in selecting which DHCPOFFER to accept." page 29, RFC 2131

Jedenfalls bastelt sich die TVstick-Firmware (für das ausgewählte WLAN mit korrektem Passwort) aus dem "refuse to allocate an address to a particular client even though free addresses are available" der FritzBox anhand der "vendor ci" eine "falsche" fallback IPv4 192.168.178.x , anstatt "die beste (weil einzige) DHCPOFFER" als DHCPREQUEST auszuwählen, um ein DHCPACK zu erhalten.

Mit der fallback-IP 192.168.178.26 bekommt der TVStick zwar eine WLAN Verbindung, funktioniert aber nicht im LAN, einem 21-er Klasse A Netz, also "kein Internet" "kein TV". Mit allen anderen Geräten, wie PS2, Xbox, handys, tablets, PC's, funktioniert diese LAN-Konfiguration völlig problemlos. Immer kommt die zugeordnete IPv4 für eine WLAN-Verbindung mit bekanntem WLAN-Interface (der hardware MAC-Adresse) korrekt und standardkonform vom zweiten DHCP-Dienst/pi-hole.

"predictable client behavior regardless of which server the client selects" (https://datatracker.ietf.org/doc/html/rfc2131)

Mein "würg around", die korrekte IPv4 wird statisch/fest eintragen, mit 10.0.x.y/21 Gateway 10.0.0.1, und funktionierte auch erst mit den Standardvorgaben für die DNS-Server: 8.8.8.8 und 8.8.4.4, beidemale Google. Im LAN wird dieser Dienst von der FritzBox bzw. von pi-hole bedient und per DHCP verteilt. Mit statischer IPv4/21, Gateway und (nur mit) Google als DNS-Dienst steht jetzt die Internetverbindung mit TV. Der Stick hat die aktuellste Firmware beim anschließenden Updateversuch gemeldet, siehe Anhang.