LL2M: ll2mdetect funktioniert nur mit Interface-Angabe

[Jirka]

Hallo,

ich habe irgendwie feststellen müssen, dass ich bei einem ISG-8000 mit einem ll2mdetect nicht weiter komme, Ergebnis ist in dem Fall ein "0 device(s) detected". Nachdem ich mir das nicht erklären konnte, da ich mit anderen Geräten dann wiederum den ISG-8000 fand, grübelte ich, woran das liegen könnte und kam zu der Erkenntnis, dass es offenbar nur unter Angabe des Interfaces funktioniert. Ein 'll2mdetect -i LAN-4' funktioniert also. Diese Angabe ist aber normal nur zur Filterung gedacht:

Code: Alles auswählen

> ll2mdetect -?
Usage: ll2mdetect <options>
Options: -?, -h: print this help
         -a <MAC-Address>: filter by MAC address (use X or * for wildcard digits)
         -t <Type>: filter by device type
         -r <Release>: filter by hardware release
         -f <Version>: filter by firmware version
         -s <Serial>: filter by serial number
         -v <0...4094>: set VLAN to be used
         -b : use broadcast instead of multicast address
         -i <ifc>: only search on given interface

Daher gehe ich davon aus, dass es sich um einen Fehler handelt. Die genaue Ursache ist mir noch nicht klar. Vielleicht liegt es an der speziellen Situation der Interfaces am ISG-8000 oder daran, dass untere logische LAN-Interfaces (noch) nicht existieren bzw. zugeordnet sind, keine Ahnung. Es ist jedenfalls eigenartig.
Firmware-Version ist die Ver. 10.72.0092SU2 / 16.02.2023.

Vielen Dank und viele Grüße
Jirka

[jfuchs]

Diese Angabe ist aber normal nur zur Filterung gedacht

Was führt dich zu der Annahme, dass das nur zur Filterung gedacht ist, bzw. was meinst du damit konkret?
Ich kann mich dunkel an einige Fälle (damals) erinnern, wo ich das Interface für ll2m eben genauso wie von dir genannt angeben musste, da der Mechnismus zur automatischen Ermittelung des Interfaces über den die "Gegenstelle" erreicht werden kann nicht funktioniert hat. In einfachen Fällen wo man auf einem AP bspw. nur ein LAN-Interface und WLAN konfiguriert hatte, war die Funktion ohne Angabe des Interfaces gewährleistet. In komplexeren Fällen eben jedoch leider nicht. Der zuständige Entwickler meinte auch zu mir, dass das alles so korrekt ist. Man könnte jetzt mutmaßen, dass der Code an der Stelle etwas limitiert ist und sicher noch aufgebohrt werden könnte

Nachtrag: ich hab nicht richtig gelesen. Mein Kommentar bezieht sich auf "ll2mexec" statt auf "ll2mdetect". Und mit der Filterung meinst du sicher, dass du eben ll2m "Ergebnisse" nur von einem Interface haben willst (edit: übrigens schickt der LANCOM das ll2m Paket dann auch nur auf diesem Interface raus). Beispielsweise wenn die Liste sonst zu lang werden würde.
Um trotzdem noch was gehaltvolles beizusteuern: hast du das ll2mdetect mal mit der Option "-b" (zu Verwendung der Broadcast MAC-Adresse als Destination, statt der Multicast-MAC-Addresse) ausprobiert?

Nachtrag2: "ll2mdetect" sowie auch unter Angabe von einem Interface "ll2mdetect -i LAN-4" verwenden beide die Multicast-MAC-Adresse wie ich im Trace sehen konnte. Die Pakete sehen identisch aus, weswegen ich mir jetzt erstmal kein unterschiedliches Verhalten erklären könnte. Könnte dir nur noch anraten einen Ethernet-Trace (tr # ethernet @ ll2m) zu machen, und zu schauen, ob das Paket wirklich rausgeht. Und dann Tippel Tappel Tour wer das Paket womöglich droppt?

Nachtrag3: vielleicht magst du uns mal Teile deiner Konfig nennen, und erläutern was mit "dass untere logische LAN-Interfaces (noch) nicht existieren bzw. zugeordnet sind" genauer gemeint ist?

[Jirka]

Nachtrag: ich hab nicht richtig gelesen. Mein Kommentar bezieht sich auf "ll2mexec" statt auf "ll2mdetect". Und mit der Filterung meinst du sicher, dass du eben ll2m "Ergebnisse" nur von einem Interface haben willst (edit: übrigens schickt der LANCOM das ll2m Paket dann auch nur auf diesem Interface raus). Beispielsweise wenn die Liste sonst zu lang werden würde.

Genau. Da ich in der Regel nur einzelne Geräte suche und üblicherweise auch nicht mehr als 15 Geräte kommen, "filtere" ich lieber schnell mit dem Auge D. h. den Befehl ll2mdetect habe ich bisher immer nur ohne Optionen verwendet, weswegen es auch ewig gedauert hat, ehe ich rausgefunden habe, dass es mit Angabe der Option geht...

Um trotzdem noch was gehaltvolles beizusteuern: hast du das ll2mdetect mal mit der Option "-b" (zu Verwendung der Broadcast MAC-Adresse als Destination, statt der Multicast-MAC-Addresse) ausprobiert?

Siehe nachfolgend. Aber die Antwort auf die eigentliche Frage: Nein, hatte ich bisher nicht, aber bringt offenbar auch keine Änderung.

Code: Alles auswählen

root@CC-RIS-HGW:/
> ll2mdetect

0 device(s) detected

root@CC-RIS-HGW:/
> ll2mdetect -b

0 device(s) detected

root@CC-RIS-HGW:/
> ll2mdetect -i LAN-4
Address 00:a0:57:1a:28:1e on Interface LAN-4:
  Name CC-ELSTER-HGW
  Type LANCOM 1781A
  Serial Number 4002574918100593
  MAC-Address 00:a0:57:1a:28:1e
  HW-Release B
  Firmware-Version 10.34.0375 / 22.05.2021
Address 00:a0:57:1e:96:28 on Interface LAN-4:
  Name CC-IT-ADMIN-HGW
  Type LANCOM 1781VA (over ISDN)
  Serial Number 4002883518100352
  MAC-Address 00:a0:57:1e:96:28
  HW-Release B
  Firmware-Version 10.34.0469 / 19.07.2022
Address 00:a0:57:5c:79:8a on Interface LAN-4:
  Type LANCOM WLC-30
  Serial Number 4006433932100054
  MAC-Address 00:a0:57:5c:79:8a
  HW-Release C
  Firmware-Version 10.50.1107 / 23.02.2023
Address 00:a0:57:14:86:58 on Interface LAN-4:
  Name CC-IMAGES-HGW
  Type LANCOM WLC-4100
  Serial Number 222591800003
  MAC-Address 00:a0:57:14:86:58
  HW-Release B
  Firmware-Version 10.34.0375 / 22.05.2021
Address 00:a0:57:2e:96:8d on Interface LAN-4:
  Name IMAGES-HGW-VDSL
  Type LANCOM 1783VA (over ISDN)
  Serial Number 4004319518100379
  MAC-Address 00:a0:57:2e:96:8d
  HW-Release A
  Firmware-Version 10.34.0375 / 22.05.2021
Address 00:a0:57:1f:3a:41 on Interface LAN-4:
  Name Wifi-175-3OG
  Type LANCOM L-322agn dual Wireless
  Serial Number 4003048218100842
  MAC-Address 00:a0:57:1f:3a:41
  HW-Release E
  Firmware-Version 9.24.0474 / 28.10.2019
Address 00:a0:57:6d:47:4c on Interface LAN-4:
  Name LX-6400
  Type LANCOM LX-6400
  Serial Number 4006043316102804
  MAC-Address 00:a0:57:6d:47:4c
  HW-Release B00
  Firmware-Version 5.38.0084Rel / 13.09.2022
Address 00:a0:57:46:73:5d on Interface LAN-4:
  Name WIFI-SIP-HGW-VDSL
  Type LANCOM 1906VA (over ISDN)
  Serial Number 4005045118100118
  MAC-Address 00:a0:57:46:73:5d
  HW-Release C
  Firmware-Version 10.72.0092 / 15.02.2023

8 device(s) detected

root@CC-RIS-HGW:/
> tr # ethernet @ ll2m
Ethernet                   ON  @ ll2m

root@CC-RIS-HGW:/
> ll2mdetect

0 device(s) detected

root@CC-RIS-HGW:/
>
[Ethernet] 2023/03/08 15:32:22,566
Sent 42 byte Ethernet packet via LAN-4:
-->IEEE 802.3 Header
Dest                : 01:a0:57:00:10:00
Source              : 00:a0:57:7f:07:d1 (LANCOM 7f:07:d1)
IEEE frame len      : 28
-->LLC Header
DSAP                : SNAP [I]
SSAP                : SNAP [C]
Frame type          : U P/F=0 M=0
SNAP Manufacturer   : 00:a0:57 (LANCOM)
Type                : LL2M (0x0001)
-->LANCOM Layer 2 Management Packet
Version             : 1
Session Id          : 27610
Packet Type         : Request
Flags               :
Packet Length       : 10
 Record Type        : SYSINFO
 Record Length      : 0
 Record Epoch       : 0
 Record Seq.-Number : 1


[Ethernet] 2023/03/08 15:32:22,566
Received 60 byte Ethernet packet via DSL-1 on flow index 2 (computed flow index 2):
Physical Port       : ETH-1
-->IEEE 802.3 Header
Dest                : 01:a0:57:00:10:00
Source              : 00:a0:57:7f:07:d1 (LANCOM 7f:07:d1)
IEEE frame len      : 28
-->LLC Header
DSAP                : SNAP [I]
SSAP                : SNAP [C]
Frame type          : U P/F=0 M=0
SNAP Manufacturer   : 00:a0:57 (LANCOM)
Type                : LL2M (0x0001)
-->LANCOM Layer 2 Management Packet
Version             : 1
Session Id          : 27610
Packet Type         : Request
Flags               :
Packet Length       : 10
 Record Type        : SYSINFO
 Record Length      : 0
 Record Epoch       : 0
 Record Seq.-Number : 1
Trailer             : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00                   ..



root@CC-RIS-HGW:/
> ll2mdetect -b

0 device(s) detected

root@CC-RIS-HGW:/
>
[Ethernet] 2023/03/08 15:34:31,178
Sent 42 byte Ethernet packet via LAN-4:
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : 00:a0:57:7f:07:d1 (LANCOM 7f:07:d1)
IEEE frame len      : 28
-->LLC Header
DSAP                : SNAP [I]
SSAP                : SNAP [C]
Frame type          : U P/F=0 M=0
SNAP Manufacturer   : 00:a0:57 (LANCOM)
Type                : LL2M (0x0001)
-->LANCOM Layer 2 Management Packet
Version             : 1
Session Id          : 27621
Packet Type         : Request
Flags               :
Packet Length       : 10
 Record Type        : SYSINFO
 Record Length      : 0
 Record Epoch       : 0
 Record Seq.-Number : 1


[Ethernet] 2023/03/08 15:34:31,178
Received 60 byte Ethernet packet via DSL-1 on flow index 2 (computed flow index 2):
Physical Port       : ETH-1
-->IEEE 802.3 Header
Dest                : ff:ff:ff:ff:ff:ff (Broadcast)
Source              : 00:a0:57:7f:07:d1 (LANCOM 7f:07:d1)
IEEE frame len      : 28
-->LLC Header
DSAP                : SNAP [I]
SSAP                : SNAP [C]
Frame type          : U P/F=0 M=0
SNAP Manufacturer   : 00:a0:57 (LANCOM)
Type                : LL2M (0x0001)
-->LANCOM Layer 2 Management Packet
Version             : 1
Session Id          : 27621
Packet Type         : Request
Flags               :
Packet Length       : 10
 Record Type        : SYSINFO
 Record Length      : 0
 Record Epoch       : 0
 Record Seq.-Number : 1
Trailer             : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00                   ..



root@CC-RIS-HGW:/
>

Nachtrag3: vielleicht magst du uns mal Teile deiner Konfig nennen, und erläutern was mit "dass untere logische LAN-Interfaces (noch) nicht existieren bzw. zugeordnet sind" genauer gemeint ist?

Die Konfig ist unspektakulär und gerade von einem 9100+ gekommen per Script übertragen (wobei leider auch, trotz meiner jahrelangen Erfahrung, was schief gegangen ist - wird ein eigener Beitrag). LAN-1 und LAN-2 waren früher an den Interfaces ETH-2 und ETH-3. Diese sind aber aktuell auf aus gestellt. Würde ich das Gerät jetzt neu konfigurieren, würde ich LAN-1 statt LAN-4 verwenden. Ich kann es ja auch umändern, falls das der Fehlersuche dienlich ist.
Ich habe natürlich jetzt auch noch mal einen Trace gemacht mit -i LAN-4. Es geht das gleiche Paket raus, nur die Source-MAC-Adresse hat dann hinten eine 4 stehen! Sowas in der Art hatte ich vermutet. Der ISG-8000 hat eben anders als offensichtlich andere LANCOM-Router für jede Ethernet-Schnittstelle eine eigene MAC-Adresse und damit kommt das LL2M-Modul offenbar nicht klar, jedenfalls nicht ohne Angabe des Interfaces. Ich halte das für einen Bug. Wie gesagt, ich bin nur nach langem Überlegen auf die Idee gekommen, hier das Interface anzugeben. Beim exec-Befehl ist mir das ja klar, aber hier nicht.

[Dr.Einstein]

Daran merkt man immer wieder, dass der ISG-8000 kein normaler Lancom ist, sondern ein kleiner Server, ähnlich einem vRouter Image. Und die Interface sind anders als bei den Radioweckern echte Netzwerkkarten statt ein Switch.

[jfuchs]

Ich habe natürlich jetzt auch noch mal einen Trace gemacht mit -i LAN-4. Es geht das gleiche Paket raus, nur die Source-MAC-Adresse hat dann hinten eine 4 stehen!

Ich habe leider keinen ISG-8000 zur Verfügung, aber dann hat der Trace (auch wenn du ihn dafür nicht angehangen hast) ja geholfen. Das scheint dann wohl wirklich schon der Unterschied zu sein. Ich denke das wird dem entsprechenden Entwickler helfen, welcher vielleicht heimlich mitgelesen hat und womöglich "nur" auf die Schnelle mit "LAN-1" getestet hat Wie Dr.Einstein schon sagt und ich mich noch recht erinnere handelt es sich bei dem ISG-8000 um eine zugekaufte (Server-) Hardwareplatform, auf dem grob ein daran angepasstes Derivat vom vRouter läuft.

[Jirka]

Ich habe leider keinen ISG-8000 zur Verfügung

Ich denke das wird dem entsprechenden Entwickler helfen, welcher vielleicht heimlich mitgelesen hat und womöglich "nur" auf die Schnelle mit "LAN-1" getestet hat

Meinst Du? Na ja, könnte sein. Bei Dr. Einstein und mir ist heute Feiertag Habe ich mich aber nicht dran gehalten

Wie Dr.Einstein schon sagt und ich mich noch recht erinnere handelt es sich bei dem ISG-8000 um eine zugekaufte (Server-) Hardwareplattform, auf dem grob ein daran angepasstes Derivat vom vRouter läuft.

Ok. Musste auf alle Fälle auch OID-Nummern von PRTG anpassen für Standardwerte wie z. B. freien RAM, Temperatur oder CPU-Last. Unified MIB ist da also auch nicht mehr ...

[tstimper]

Sorry, das ist jetzt wirklich Off Toppic, es interessiert mich aber doch ...

Wie Dr.Einstein schon sagt und ich mich noch recht erinnere handelt es sich bei dem ISG-8000 um eine zugekaufte (Server-) Hardwareplatform, auf dem grob ein daran angepasstes Derivat vom vRouter läuft.

Das habe ich auch schon mehrfach gehört. Gibt es da genauerere Infos? Also läuft der vRouter auf einem Mini Linux + KVM oder QEMU?
Und noch viel wichtiger, lässt die der ISG-8000 später "Ent-LANCOMisieren und ein normales Linux draufspielen?
Also später, wenn der ISG-8000 EOL ist?
Und lässt sich der RAM aufrüsten? Und die HDD / SSD tauschen? Was ist da überhaupt drin?

Und das würde hoffen lassen, das das HardWare Leben eines ISG-8000 nach EOL sogar mittels vRouter Subcription verlängert werden könnte.

Viele Grüße

ts

[jfuchs]

Das habe ich auch schon mehrfach gehört. Gibt es da genauerere Infos? Also läuft der vRouter auf einem Mini Linux + KVM oder QEMU?

Genauere Infos wirst du nur von Leuten bekommen, die schon mal eins vor sich auf dem Tisch liegen hatten und viel Zeit zum basteln hatten. Die Chance wird denke ich (auch aufgrund des Preises) gegen Null gehen.

Ich hab damals kurzzeitig eins auf dem Tisch liegen gehabt und LCOS-spezifische Tests mit gefahren, soweit ich mich entsinne. Alles weitere wären aber auch Betriebsgeheimnisse deren Publikation gegen die Geschäftsinteressen von LANCOM wären.

Und noch viel wichtiger, lässt die der ISG-8000 später "Ent-LANCOMisieren und ein normales Linux draufspielen?
Also später, wenn der ISG-8000 EOL ist?
Und lässt sich der RAM aufrüsten? Und die HDD / SSD tauschen? Was ist da überhaupt drin?

Glücklicherweise muss ich da auch nicht herumdrucksen, da ich echt nicht mehr weiß, als das oben genannte. Aus meiner (Berufs-) Erfahrung her, kann ich mir aber gut vorstellen, dass das alles im Rahmen des Möglichen für diese x86 Platform ("Native Nutzung von LCOS auf x86-Hardware", Folie 15 [0]) sein könnte - solange der Bootloader/BIOS nicht verrammelt/gesperrt wurde (wie man es aber üblicherweise macht). Der vRouter-Firmware werden nur sicher die spezifischen Sachen (eben gerade Ethernet-Hardware) für den ISG-8000 fehlen - und die wirst du denke ich auch schwer reingedreht bekommen.

[0]: https://www.bachert.de/event/download/2 ... _teil2.pdf

[backslash]

Hi Jirka

der ISG-8000 hat eine 4 Kern x86-64 CPU (mit HT, also 8 virtuelle Cores)... Auf ihm läuft kein vRouter, sondern ein natives LCOS - also *OHNE* einen Hypervisor...
Aber ja: der VRouter und die ISG-8000 Firmware sind sich sehr ähnlich - nur daß der ISG-8000 echte Ethernet-Module hat und der VRouter verschiede virtuelle Netzwerkkarten (e1000, VMXNET3, ...) unterstützt
Zuerst war der VRouter, dann kam die Idee zum ISG 8000, zunächst tatsächlich mit einem VRouter gedacht, dann aus Performancegründen doch mit nativer Firmware...

Gruß
Backslash

[Jirka]

Hallo Backslash,

danke für die Aufklärung, auch wenn nicht ich sondern tstimper gefragt hatte.
Mir war das schon fast klar, wenn man so in die Hardware-Info schaut. Nur bei solchen Sachen wie 'show mem' - der Befehl macht keine Angaben über den Flash-Speicher, wie man es gewohnt ist - sieht man dann einige Unterschiede - man findet die SSD dann aber unter Volumes.

Viele Grüße
Jirka