DoorBird videofoon crasht Telenet HGW

[MaT]

Als iemand komt vertellen dat ik een router moet plaatsen omdat anders zijn product niet werkt... wel dan mag hij z'n product meteen weer meenemen en vertrekken !

Je bedoeld een HGW moeten plaatsen om de digicorder DLNA functie te doen werken?

[Alfa I.S.]

Als iemand komt vertellen dat ik een router moet plaatsen omdat anders zijn product niet werkt... wel dan mag hij z'n product meteen weer meenemen en vertrekken !

Lees eerst alles voor je dit post, fout ligt namelijk aan telenet en ze zoeken naar een oplossing voor in de toekomst via update van hun software.

Maar dit duurt te lang, alle klanten willen dat hun doorbird werkt dus is de router nodig.

Al de rest kan via de HGW werken.

[ubremoved_539]

Je bedoeld een HGW moeten plaatsen om de digicorder DLNA functie te doen werken?

Kom je weer wat onwaarheden verkondigen... mijn DLNA werkt en ik heb nochtans geen HGW van TN staan.

Lees eerst alles voor je dit post, fout ligt namelijk aan telenet en ze zoeken naar een oplossing voor in de toekomst via update van hun software.

Daar ben ik mij volledig van bewust... beide partijen hebben dan ook contact met elkaar... het is dus aan hun hierover duidelijk te communiceren (en spijtig genoeg doet geen van beide dat op dit moment). Wat mij betreft mag Doorbird Telenet gerust publiekelijk in gebreke stellen als dit probleem niet is opgelost na één maand of zo.

[JUVO]

Even een bevinding van een mede DoorBird installateur.
Het lijkt er op dat bij gebruik van UTP, niet WIFI, het plaatsen van een POE injector voldoende is om dit probleem uit de weg te gaan. (raar maar waar...)
Ik gebruik de, door DoorBird geteste, TP-Link TL-POE150S

Moet je ineens ook geen voeding meer voorzien voor je DoorBird.

Via Wifi ben ik bang dat een andere router of Accesspoint de beste oplossing is.
Ondersteund je extra router geen IPTV/STB, dan steek je je digicorder gewoon rechtstreeks op je telenet router en al de rest achter je eigen extra router. Als je telenet router meer dan 1 aansluiting heeft natuurlijk

[ubremoved_539]

Het lijkt er op dat bij gebruik van UTP, niet WIFI, het plaatsen van een POE injector voldoende is om dit probleem uit de weg te gaan. (raar maar waar...)

Een POE injector is volledig transparant tov. het netwerk protocol... dit kan dus nooit een oplossing zijn (maar eerder toeval).

Via Wifi ben ik bang dat een andere router of Accesspoint de beste oplossing is.

Aangezien het probleem in de DHCP server van TN z'n HGW zit is een extra AP ook nooit een oplossing.

Spijtig dat het ondertussen stil blijft langs de kant van zowel TN als Doorbird

[JUVO]

Puur theoretisch geef ik je volledig gelijk. Echter in de praktijk heb ik dit probleem zowel verholpen gekregen met Poe injector, met Ap of met gewone switch tussen doorbird en de Telenet router.

Ik zou zeggen, probeer eerst eens met de goedkopere oplossingen voor je een extra router gaat neerpoten.

Just my 2 cents

Groeten

Juvo

[morisse]

Dear All,

I am living in the netherlands, provider is Ziggo and they use what they call "Ziggo Connect Box".
My Connect Box is having exactly the same problem as your Telenet HGW:
- DHCP server crashes as soon as doorbird tries to connect by DHCP
- Devices that already obtained an IP address before the DHCP crash will continue working properly
- However devices that request a new DHCP address will never get one anymore
- Only way out is to reset the Connect Box
After researching a bit on the internet, it seems the Ziggo Connect Boz is also an COMPAL BROADBAND NETWORKS CH7465LG.

My question is: Have you ever received a fix from Doorbird to solve this issue?

Thanks in advance for your help!

Kind Regards,

Marc

[philippe_d]

After researching a bit on the internet, it seems the Ziggo Connect Boz is also an COMPAL BROADBAND NETWORKS CH7465LG

Dus duidelijk een (DHCP) probleem tussen de DoorBird en de HGW / Compal kabelmodem.

Aangezien het probleem in de DHCP server van TN z'n HGW zit is een extra AP ook nooit een oplossing.

Theoretsich heb je waarschijnlijk gelijk: een extra AP, of een switch zijn "transparant".
Aan de andere kant kan je toch de berichten niet ontkennen van sommige installateurs, die het probleem hebben "opgelost" met een extra AP/switch.
Ik heb geen enkel verstand van layer 1/2/3, maar kan de DoorBird in zijn DHCP request geen zaken meegeven, die door een AP/switch wel tegengehouden worden en dus niet tot aan de DHCP server van de HGW geraken?

[ubremoved_539]

My question is: Have you ever received a fix from Doorbird to solve this issue?

While Doorbird maybe sends out a corrupt DHCP request... COMPAL/Ziggo/TN should make sure its DHCP server doesn't crash.

Ik heb geen enkel verstand van layer 1/2/3, maar kan de DoorBird in zijn DHCP request geen zaken meegeven, die door een AP/switch wel tegengehouden worden en dus niet tot aan de DHCP server van de HGW geraken?

Er bestaat zoiets als DHCP snooping... maar ik zie niet in hoe het in deze context (al ken ik die niet exact) het probleem zou oplossen.

[CCatalyst]

After researching a bit on the internet, it seems the Ziggo Connect Boz is also an COMPAL BROADBAND NETWORKS CH7465LG

Dus duidelijk een (DHCP) probleem tussen de DoorBird en de HGW / Compal kabelmodem.

Aangezien het probleem in de DHCP server van TN z'n HGW zit is een extra AP ook nooit een oplossing.

Theoretsich heb je waarschijnlijk gelijk: een extra AP, of een switch zijn "transparant".
Aan de andere kant kan je toch de berichten niet ontkennen van sommige installateurs, die het probleem hebben "opgelost" met een extra AP/switch.
Ik heb geen enkel verstand van layer 1/2/3, maar kan de DoorBird in zijn DHCP request geen zaken meegeven, die door een AP/switch wel tegengehouden worden en dus niet tot aan de DHCP server van de HGW geraken?

Client kan DHCP options meesturen in zijn request, die kunnen vendorspecifiek zijn. Maar een switch mag die niet tegenhouden (maar kán dat wel natuurlijk).

Ook corrupte DHCP requests kunnen onderweg tegengehouden worden (niet enkel de request zelf, ook de encapsulatie kan corrupt zijn).

Zoals in de eerste replieken al aangehaald zal er nood zijn aan een packet capture aan de bron om hier iets van zinnige uitspraken te kunnen doen.

[ubremoved_539]

Feit is dat beide partijen in de mogelijkheid zijn om het probleem op te lossen;

- Telenet kan/moet zorgen dat z'n DHCP server niet langer crashed op ongeldige DHCP requests
- Doorbird kan/moet zorgen dat ze niet langer ongeldige DHCP requests doen

We zijn ondertussen 1 maand verder... maar geen van beide hebben dus al iets opgelost

[cadsite]

We zijn ondertussen 1 maand verder... maar geen van beide hebben dus al iets opgelost

Er gaat eerst een of andere pipo met een zielige foto in de krant moeten staan denk ik.

[ubremoved_539]

Een apotheker die gaan klant kon binnen laten

[cadsite]

Een apotheker die gaan klant kon binnen laten

bijvoorbeeld

[CCatalyst]

ongeldige DHCP requests

Is dat al effectief bewezen of is dat nog steeds niets meer dan de meest voor de hand liggende assumptie op dit ogenblik.

Indien het tweede, is de eerste stap nog steeds het probleem positief identificeren.

[ubremoved_539]

We hebben dit verder laten onderzoeken en het probleem lijkt bij Doorbird zelf te liggen, 1 van de dhcp pakketten van Doorbird blijkt een foute parameter te geven die een crash veroorzaakt op onze witte modems.

Volgens TN alvast wel... maar toen werd het langs beide kanten stil

[JUVO]

Ik heb uit goede bron vernomen dat DoorBird een update heeft klaar staan om het probleem te verhelpen...
-- latest firmware update (105)

Groeten,

Juvo

[ITnetadmin]

Ik heb geen enkel verstand van layer 1/2/3, maar kan de DoorBird in zijn DHCP request geen zaken meegeven, die door een AP/switch wel tegengehouden worden en dus niet tot aan de DHCP server van de HGW geraken?

Bij deze: DHCP is een layer 7 protocol, dat zich dus volledig op de application layer bevindt.
Nu is het OSI model wel theoretisch.
De TCP/IP implementatie ervan voegt een aantal layers samen: layers 1 (physical) en 2 (datalink, maw mac adressen) vormen 1 layer, en layers 5/6/7 (session/presentation/application) vormen ook 1 layer.

Switchen bevinden zich volledig op layer 2.
APs zitten iets ingewikkelder in mekaar (zijn eigenlijk wifi switchen, maar er zit nog een hele authentication en encryption op, die de payload van het layer 3 packet encrypteert, zodat enkel management info als mac en ip nog zichtbaar is).

Maar elke layer werkt independent, en is onbelangrijk voor elke andere layer.
Een packet wordt klaargemaakt op een bepaalde layer, en dan doorgegeven aan de volgende.
Een lagere layer ziet een packet van een hogere layer als een gesloten doos en plakt er gewoon zijn header (en op layer 2 dus ook footer) aan vast.
Alvorens een packet een layer terug omhoog te sturen, wordt die header eraf gehaald.

Het enige dat switchen wél doen is misvormde frames (zo noemen layer 2 packetjes) droppen.
Op layer 2 heeft een frame een checksum achteraan, dus een frame waarbij de checksum niet klopt (meestal een gevolg van een slechte transmissie op physical niveau) passeert de switch niet. (het is iets ingewikkelder: je kan sommige switchen het bevel geven om de checksums niet te controleren om sneller te kunnen werken)

Maar aangezien layer 2 zich niets gaat aantrekken van zijn payload, gaat een misvormd DHCP request normaal gezien geen verkeerde checksum opleveren. De checksum is letterlijk om te zien of de transmissie over het fysiek medium geslaagd is, en of er door storingen of dergelijke geen nulletje als een eentje is ingelezen of omgekeerd.

Het lijkt mij hier dus te gaan om een DHCP server die zijn error handling fout afhandelt, en in de war geraakt als de request (zijn we zeker dat het de discover niet is?) verkeerd geformuleerd is.
Dat een switch ertussen gooien het probleem oplost is dus een raadsel.
Ik zou enkel kunnen bedenken dat de broadcast of unicast van de doorbird verkeerd geformuleerd is en de switch het packetje dropt ipv forward.

[nicolasl2001]

Ik heb uit goede bron vernomen dat DoorBird een update heeft klaar staan om het probleem te verhelpen...
-- latest firmware update (105)

Groeten,

Juvo

Bedankt Juvo. Inderdaad firmware update 105 lost het DHCP probleem met de witte Telenet router/modem op.
Ik heb hiervoor even mijn smarthone als hotspot ingesteld. Nadien Doorbird hierop aangesloten met een andere smartphone en nadien een paar uur gewacht dat Doorbird zijn firmware upgrade. Nadien kon ik weer op Telenet netwerk aansluiten met Doorbird

Je kan eventueel ook een extra router plaatsen na de telenet modem die een andere ip-regio gebruikt dan die van Telenet. Van zodra Doorbird internet verbinding heeft kan de firmware ge-upgrade worden en zou het probleem verholpen moeten zijn.

Gr,
Nicolas