Matthijs van Du

Level 1
  • 3Posts
  • 0Oplossingen
  • 0Likes

ConnectBox stuurt LLDP packets door (in strijd met IEEE 802.1 standaarden)

Vandaag viel me ineens iets merkwaardigs op. In de lijst van processen op mijn laptop zag ik dit staan:

  609 ?        Ss     0:07 lldpd: monitor. 
657 ? S 0:29 \_ lldpd: connected to gerbil.


Dit geeft aan dat lldpd van mening was dat ik direct met een netwerk kabel aangesloten was op "gerbil", m'n server. Dit vond ik vrij fascinerend aangezien dit niet waar is: zowel m'n laptop als m'n server zijn aangesloten op m'n ConnectBox.

Even een packetsniffer aangezet en jawel...
8c:70:5a:05:ac:cc > 01:80:c2:00:00:0e: LLDP, length 233: squirrel
e0:cb:4e:b4:8a:af > 01:80:c2:00:00:0e: LLDP, length 62: gerbil
8c:70:5a:05:ac:cc > 01:80:c2:00:00:0e: LLDP, length 233: squirrel
e0:cb:4e:b4:8a:af > 01:80:c2:00:00:0e: LLDP, length 62: gerbil


Hier zien we zowel de LLDP packets die m'n laptop verstuurt alsmede die van m'n server. Normaliter is het doorsturen van packets precies wat je verwacht van een switch of router, maar in dit geval is het juist foute boel:

Om er zeker van te zijn dat alleen het apparaat aan de andere kant van de netwerkkabel gedetecteerd wordt worden LLDP packets verstuurt naar het MAC adres 01:80:C2:00:00:0E, wat een van de speciaal gereserveerde multicast adressen is waarvan standaarden voor ethernet switches/bridges (zowel de oudere IEEE 802.1D als de nieuwere 802.1Q) vereisen dat geen enkele switch, bridge, of ander stuk netwerkapparaatuur onder enige omstandigheid packets met deze bestemming door mag sturen naar andere poorten... wat de ConnectBox echter dus vrolijk wel doet.

Dusch... een vriendelijk verzoek aan de firmware programmeurs van de ConnectBox om zich aan de standaarden de houden en te voorkomen dat packets met bestemming 01:80:C2:00:00:00 t/m 01:80:C2:00:00:0F doorgestuurd worden van de ene naar de andere Ethernet poort, of tussen Ethernet en Wifi.

Referenties:
IEEE 802.1Q-2014, sectie 8.6.3 en specifiek tabel 8-1
5 Reacties 5
hanh

Oud Community-lid
  • 17054Posts
  • 661Oplossingen
  • 3463Likes
Hallo Matthijs,
Een doorwrocht stukje werk!
Heb het nog ff snel nagekeken en het klopt vlgs mij helemaal, dat dit niet ok is.
Puur toeval, dat je hier tegenaan liep.

Heb m'n virtuele Centos Linux bakkie gestart maar zag dat lldpd daar niet op loopt.
Hij is wel aanwezig maar weet nog niet hoe ik hem als service kan starten.
Heb trouwens geen ConnectBox maar een Technicolor 7210 & van rechtstreekse aansluiting aan de TC is bij mij al helemaal geen sprake.
Een test die enigszins lijkt op jouw situatie gaat dus niet lukken zo.
Gr Han
Matthijs van Du
Topicstarter
Level 1
  • 3Posts
  • 0Oplossingen
  • 0Likes
Aangenomen dat het systemd-networkd gebruikt kan je ook LLDP=on en EmitLLDP=on in de [Network] sectie van de relevante /etc/systemd/network/*.network file zetten ipv lldpd te gebruiken.
Gusto

Level 7
  • 1490Posts
  • 34Oplossingen
  • 147Likes
Heb mijn netwerk ook eens nagekeken op LLDP pakketten:
PC (debian) - niet
Ubee - niet
Mikrotik - niet
HP-1810 - wel
Gusto

Level 7
  • 1490Posts
  • 34Oplossingen
  • 147Likes
Ik zie dat lldpd meerdere protocollen ondersteund:
lldpd
supports several discovery protocols and is smart enough to select the right protocol on each interface:

  • LLDP, of course
  • CDP (Cisco)
  • EDP (Extreme)
  • SONMP (Nortel)
  • FDP (Foundry)
mischien dat hier een verklaring in zit?
Matthijs van Du
Topicstarter
Level 1
  • 3Posts
  • 0Oplossingen
  • 0Likes
Verklaring voor wat? De packetsniffer laat zien dat de connectbox packets met bestemming 01:80:C2:00:00:0E doorstuurt, en ongeacht de verdere inhoud van de packets is dat een schending van de standaard.

De "verklaring" is ongetwijfeld dat de programmeurs van de connectbox firmware dit gewoon over het hoofd gezien hebben. Dat neem ik verder niemand kwalijk, maar het zou fijn zijn als een bug report naar ze verstuurd kan worden.

Uitgelicht topic