LANconfig: MAC-Adress-Format-Fehler

[stefanbunzel]

Da hier heute schon mehrfach auf Fehler von LANconfig bzw. LCOS hingewiesen wurde, hier von mir gleich auch noch welche:

LANconfig 9.10.0086 in Verbindung mit LCOS 9.10.0332

Inzwischen wurde ja die Schreibweise der MAC-Adressen auf xx:xx:xx... geändert und angeblich werden verschiedene Schreibweisen dann in dieses Format umgewandelt.
Aber nicht so richtig: Bei einem L-452agn innerhalb der Stationsregeln wird ein Neueintrag ohne ":" als Trennzeichen auch nach dem Schreiben und wieder Auslesen der Config ohne ":" angezeigt. Es werden auch "Verstümmelungen" in der Form aa:bbccdd... sowie überlange ungültige MAC-Adressen akzeptiert und nicht konvertiert bzw. gewarnt!

In WebConfig werden überlange MAC-Adressen mit der Fehlermeldung "Ihre Eingabe "*" für 'SSID-Muster' ist fehlerhaft" abgelehnt. Da ist die Begründung wohl falsch...

Und gleich noch was zum Thema: In der Stationsregel-Tabelle (und einigen anderen Tabellen...) erfolgt auch keine Konvertierung der Kleinbuchstaben der MAC-Adresse in einheitlich Großbuchstaben, wie dies innerhalb der Firewall-Regeln geschieht. Auch hier sind Misch-Schreibweisen möglich: 0A:a25f...

Außerdem kann man in WebConfig MAC-Adressen der Stationsregel-Tabelle doppelt anlegen (kopieren und verändern einer Vorhanden), wenn man die Buchstaben mal groß und mal klein schreibt. Bei identischer Schreibweise gibt es die korrekte Fehlermeldung, dass der Eintrag bereits existiert.

Wenn man in LANconfig in der Stationstabelle einen Eintrag kopiert und dabei nur die Klein-/Großschreibung der MAC-Adresse ändert, wird klammheimlich der ursprüngliche Eintrag gelöscht - was ja korrekterweise doppelte Einträge verhindert. Allerdings sollte hier lieber eine Fehlermeldung kommen, dass der Eintrag schon vorhanden ist.

Und noch einer: In LANconfig -> Geräteeigenschaft -> Informationen: Geräte-MAC-Adresse wird 00:a0:... (mit Doppelpunkt) und WLAN-MAC-Adressen als 00a0... (ohne Doppelpunkt) uneinheitlich angezeigt.

Viele Grüße,
Stefan

[alf29]

Moin,

Aber nicht so richtig: Bei einem L-452agn innerhalb der Stationsregeln wird ein Neueintrag ohne ":" als Trennzeichen auch nach dem Schreiben und wieder Auslesen der Config ohne ":" angezeigt. Es werden auch "Verstümmelungen" in der Form aa:bbccdd... sowie überlange ungültige MAC-Adressen akzeptiert und nicht konvertiert bzw. gewarnt!

Dieses Feld in den Stationsregeln ist aus der Sicht von LANconfig ein Freitextfeld, das erst zur Laufzeit vom LCOS geparst wird. Man kann dort MAC-Adressen in beliebiger Schreibweise (mit Doppelpunkten oder Bindestrichen als Trenner oder auch ganz ohne) eintragen, aber auch Namen von Herstellern - Du kannst dort '*Intel*' reinschreiben und die Regel matcht auf alle MAC-Adressen, die nach der im LCOS hinterlegten OUI-Liste zu Intel gehören. Irgendwelche Versuche von LANconfig, das in eine irgendwie geartete 'kanonische' Schreibweise zu überführen, sind daher zum Scheitern verurteilt.

Und eben weil dort auch Herstellernamen zugelassen sind, würde eine zwangsweise Konvertierung in Groß- oder Kleinbuchstaben zumindest blöd aussehen...

Gruß Alfred

[stefanbunzel]

Hallo Alfred,

Dieses Feld in den Stationsregeln ist aus der Sicht von LANconfig ein Freitextfeld, das erst zur Laufzeit vom LCOS geparst wird.

Ich hatte aber sämtliche von mir angezeigten Fehler immer dahingehend getestet, ob eine Anpassung durch das Schreiben ins Gerät / LCOS erfolgt oder nicht. Dass man in LANconfig da sonst was schreiben kann, ist ja auch okay. Allerdings sollte doch nach dem erneuten Auslesen dann die konvertierte Schreibweise zurückgegeben werden - oder etwa nicht?

Viele Grüße,
Stefan

[alf29]

Moin,

Allerdings sollte doch nach dem erneuten Auslesen dann die konvertierte Schreibweise zurückgegeben werden - oder etwa nicht?

Nein, beim Zurückschreiben der Konfig ins Gerät konvertiert auch das LCOS nichts in irgendeine 'kanonische' Schreibweise. Mit 'zur Laufzeit' meinte ich, wenn ein Client sich einbucht und die Liste mit den Regeln durchlaufen wird, schaut das LCOS sich die Regel an und überlegt sich, was damit gemeinst sein könnte - ein Matching auf die MAC-Adresse oder den Vendor, und wenn auf die MAC-Adresse, dann in welcher Schreibweise (Doppelpunkte, Bindestriche, gar keine Trenner).

Meine Erahrungen mit solchen 'automatischen Konvertierungen' ist eher, daß reihenweise Anwender meckern, wieso das Gerät denn die von ihnen so liebevoll und aufwendig formulierten Regeln kaputtmachen würde. Deshalb habe ich bewußt an der Stelle alle Freiheiten gelassen, auch um den Preis, daß man eventuell Regeln definiert, die nie matchen können (z.B. eine MAC-Adresse mit zu vielen Bytes...).

Gruß Alfred

[Avalanche]

Moin,
Dieses Feld in den Stationsregeln ist aus der Sicht von LANconfig ein Freitextfeld, das erst zur Laufzeit vom LCOS geparst wird. Man kann dort MAC-Adressen in beliebiger Schreibweise (mit Doppelpunkten oder Bindestrichen als Trenner oder auch ganz ohne) eintragen, aber auch Namen von Herstellern - Du kannst dort '*Intel*' reinschreiben und die Regel matcht auf alle MAC-Adressen, die nach der im LCOS hinterlegten OUI-Liste zu Intel gehören. Irgendwelche Versuche von LANconfig, das in eine irgendwie geartete 'kanonische' Schreibweise zu überführen, sind daher zum Scheitern verurteilt.
Gruß Alfred

Warum da jetzt LCOS eine Validierung durchführen kann, die Lanconfig nicht auch schon durchführen könnte, erschließt sich mir als Softwareentwickler nicht so ganz...

Für Mac-Adressen gibt es doch nur eine begrenzte Anzahl an Schreibweisen:
01:02:03:04:05:0a, 01-02-03-04-05-0a, 01020304050a => Darstellung nach dem Laden ist 01:02:03:04:05:0A
01:02:03:04:05:0a:bb => Fehler: ungültige MAC-Adresse
a1:02:03:*, a1-02-03*, a10203* => Darstellung nach dem Laden ist A1:02:03:*
01:02:03:04:05:0a:* => Fehler: ungültige MAC-Adresse
*Intel* => Darstellung nach dem Laden ist *Intel*
*GRML* => Wird beim Speichern schon abgelehnt, weil es in der OUI-Tabelle einen Eintrag gibt der passt

Habe ich Kategorieren von Fällen vergessen?

MAC-Adressen mit zu vielen Bytes zuzulassen machen nicht so richtig Sinn, da es sich in >95% um simple Tippfehler handelt. Ich als Nicht-LCOS-Entwickler müsste erst mal nachschlagen, wo ich jetzt mit welchen Traces rausbekomme, warum denn diese eine Regel nicht so matched wie ich es mir gedacht habe. Das ist doch dramatisch mehr Arbeit für mich, als mich bei der Konfiguration schon mit einem Hinweis auf die falsche MAC-Adresse auseinander zu setzen...

[alf29]

Warum da jetzt LCOS eine Validierung durchführen kann, die Lanconfig nicht auch schon durchführen könnte, erschließt sich mir als Softwareentwickler nicht so ganz...

Die DSC-Sprache der Beschreibungsdateien hat nicht ganz die Mächtigkeit von C/C++, in dem das LCOS geschrieben ist...

a1:02:03:*, a1-02-03*, a10203* => Darstellung nach dem Laden ist A1:02:03:*

Explizit nein. Wie ich oben schon begründet hatte, gibt es genug Anwender, die massiv anfangen zu schimpfen, wenn man sie in dieser Form 'zwangsbeglückt'.

*GRML* => Wird beim Speichern schon abgelehnt, weil es in der OUI-Tabelle einen Eintrag gibt der passt

Zum einen kann LANconfig das nicht ablehen, weil es den Umfang der OUI-Tabelle im LCOS nicht kennt, zum anderen ist das mit dem Ablehnen von Konfigs so eine Sache. Das LCOS kann zwar sagen, daß ihm irgendetwas nicht paßt, aber nicht warum.

MAC-Adressen mit zu vielen Bytes zuzulassen machen nicht so richtig Sinn, da es sich in >95% um simple Tippfehler handelt.

Das wäre der einzige Punkt, den ich akzeptieren würde - wenn ich aktuell Zeit für das Thema hätte...

Gruß Alfred

[win]

Ich denke, damit kann man leben. Tippfehler sollten dem achtsamen Admin da einfach nicht passieren. Das lernt man ja mit der Zeit, spätestens dann, wenn man mal wieder eine Nacht lang nach einem Fehler gesucht hat, um dann über einen simplen Tippfehler zu stolpern. Und es gibt zahlreiche Stellen, wo man durch blöde Tippfehler nicht weiter kommt. Vieles davon lässt sich gar nicht vom System abfangen.

Kurzum, alles was man eintippt, sollte 100% geprüft sein. Von dem, der vor der Tastatur sitzt.

In diesem Zusammenhang: Ich hasse Fonts, wo man nicht klar "l" und "1" oder "0" und "O" unterscheiden kann.

[cpuprofi]

MAC-Adressen mit zu vielen Bytes zuzulassen machen nicht so richtig Sinn, da es sich in >95% um simple Tippfehler handelt.

Das wäre der einzige Punkt, den ich akzeptieren würde - wenn ich aktuell Zeit für das Thema hätte...

Hallo Alfred,

vielleicht sollten wir mal ein paar Supportfälle zu dem Thema eröffnen, damit Du dann auch die Zeit dafür bekommst?

Denn auch ich finde, dass dieses verbessert werden sollte.

Grüße
Cpuprofi

[Avalanche]

Die DSC-Sprache der Beschreibungsdateien hat nicht ganz die Mächtigkeit von C/C++, in dem das LCOS geschrieben ist...

Nachdem weder DSC-Sprache OUI DSC, noch DSC-Language bei Google Treffer zu diesem Zusammenhang bringt, kann ich auf dieses Argument ohne weitere Hintergrundinformationen leider nicht sinnvoll antworten oder es überhaupt einschätzen.

Explizit nein. Wie ich oben schon begründet hatte, gibt es genug Anwender, die massiv anfangen zu schimpfen, wenn man sie in dieser Form 'zwangsbeglückt'.

Nach dieser Logik könnte man genauso argumentieren, dass man für ein Zahlenfeld (z.B. Konfigurations-Login-Sperre) auch "X" als Wert eingeben können wollen würde. Das könnte man ja einfach genauso ignorieren und still und heimlich einen Default annehmen. Statt dessen erscheint hier (zumindest im Webinterface) eine Fehlermeldung. Was erwarten denn diese "schreienden" Anwender, dass bei einer ungültigen MAC sinnvolles passieren soll?

Technisch ließe sich das doch auf verschiedene Arten umsetzen (fehlerhafte Eingabe => Speichern der Konfig nicht möglich oder fehlerhafte Eingabe => Textfeld wird nur rot hinterlegt). Und: nur weil ein paar Schreihalse gerne nach Fehlern suchen, sollen das auch alle anderen Anwender tun?

Zum einen kann LANconfig das nicht ablehen, weil es den Umfang der OUI-Tabelle im LCOS nicht kennt, zum anderen ist das mit dem Ablehnen von Konfigs so eine Sache. Das LCOS kann zwar sagen, daß ihm irgendetwas nicht paßt, aber nicht warum.

Lanconfig weiß doch oft, von welchem Gerät die Config stammt. Für jede Version ist bekannt, wie die OUI-Tabelle aussieht. Gerade __da__ würde ich doch als Anwender einen Hinweis erwarten, dass meine Eingaben sich gar nicht so auswirken werden, wie ich das bei der Konfiguration erwarte. Der Benutzer müsste ja selbst irgendwo eine Liste mit LCOS-Version <> OUI-Tabelle im Kopf haben...

Das wäre der einzige Punkt, den ich akzeptieren würde - wenn ich aktuell Zeit für das Thema hätte...

[/quote][/quote]

Ich finde es immer wieder erstaunlich, welchen Ansatz Lancom hier generell immer fährt: Die Geräte werden für den Profimarkt verkauft, Lanconfig dabei immer als die beste Erfindung seit geschnittenem Brot angepriesen. Da kann man schon erwarten, dass man auch eine ordentliche und intuitive Benutzeroberfläche bekommt. Die Realität ist leider das Gegenteil. Die Software versucht mit einem Minimum an Eingabemöglichkeiten ohne Rücksicht auf Verluste die maximale Zahl an Anwendungsfällen abzudecken. Usability ist dabei ein absolutes Fremdwort. Nur weil ein paar Hardcore-User seit den 80er Jahren jedes Feature in und auswendig kennen, heißt nicht dass das für den "normalen" Admin auch so ist.

Dass man z.B. hier sogar OUI mit Wildcards eintragen kann, scheint den Autoren der Dokumentation auch nicht bewusst zu sein. Im 9.00 Reference Manual findet sich darauf kein Hinweis. Ich weiß jetzt leider nicht, ob das Feature in 9.10 neu ist. Wenn dem so wäre, bitte ich diese Anmerkung zu ignorieren (weil das dann ja sicher noch in die Doku aufgenommen wird).

[stefanbunzel]

Dass man z.B. hier sogar OUI mit Wildcards eintragen kann, scheint den Autoren der Dokumentation auch nicht bewusst zu sein. Im 9.00 Reference Manual findet sich darauf kein Hinweis.

Siehe LCOS-Addendum-910-RC2-DE.pdf Seite 151 Abschnitt 12.3

Viele Grüße, Stefan

[alf29]

Nachdem weder DSC-Sprache OUI DSC, noch DSC-Language bei Google Treffer zu diesem Zusammenhang bringt, kann ich auf dieses Argument ohne weitere Hintergrundinformationen leider nicht sinnvoll antworten oder es überhaupt einschätzen.

Das ist eine Beschreibungssprache, die im LANconfig benutzt wird, um den Konfigurationsdialog für ein bestimmtes Gerät aufzubauen. Mit LANconfig bekommst Du eine Reihe solcher DSC-Dateien installiert. Und bestimmte Dinge, wie z.B. komplexere Syntaxprüfungen solcher Felder, lassen sich in den DSC-Dateien einfach (im Moment) nicht formulieren.

Was erwarten denn diese "schreienden" Anwender, dass bei einer ungültigen MAC sinnvolles passieren soll?

Es ging hier nicht um eine fehlerhafte Eingabe, sondern um MAC-Adressen, die man legitimerweise auf verschiedene Weise schreiben kann.

Lanconfig dabei immer als die beste Erfindung seit geschnittenem Brot angepriesen.

Also von mir nicht...was soll ich als Linux-Anwender damit auch...

Dass man z.B. hier sogar OUI mit Wildcards eintragen kann, scheint den Autoren der Dokumentation auch nicht bewusst zu sein. Im 9.00 Reference Manual findet sich darauf kein Hinweis. Ich weiß jetzt leider nicht, ob das Feature in 9.10 neu ist. Wenn dem so wäre, bitte ich diese Anmerkung zu ignorieren (weil das dann ja sicher noch in die Doku aufgenommen wird).

Dieses Feature (genauso wie daß man Wildcards im MAC-Adressen haben darf) ist neu in der 9.10. Und wie bei jedem neuen Feature hat's in der ersten Version ein paar Ecken und Kanten, weil man nicht alles bedacht hat, was Anwender alles haben wollen oder tun könnten. Dafür wird's Release-Updates geben.

Entstanden ist das übrigens, nachdem ich unsere interne 'Feature-Wunschdatenbank' mal durchgegangen war und Dinge rund um die MAC-Liste im WLAN (egal ob Defaulteinträge, Wildcards, oder Einträge, die auf eine bestimmte SSID beschränkt sind) tauchten dort am häufigsten auf. Ich habe das Feature dann mehr oder weniger intern durchgeboxt. Daß hier jetzt darüber von den Leuten nur geschimpft wird, anstelle daß mal zur Kenntnis genommen wird, daß wir hier mit dem Feature auf die Wünsche kleinerer Kunden reagiert haben (wird uns ja häufig vorgeworfen, daß wir das nicht mehr tun), ist dann um so enttäuschender. Ob ich das nochmal mache...

Gruß Alfred

[Avalanche]

Entstanden ist das übrigens, nachdem ich unsere interne 'Feature-Wunschdatenbank' mal durchgegangen war und Dinge rund um die MAC-Liste im WLAN (egal ob Defaulteinträge, Wildcards, oder Einträge, die auf eine bestimmte SSID beschränkt sind) tauchten dort am häufigsten auf. Ich habe das Feature dann mehr oder weniger intern durchgeboxt. Daß hier jetzt darüber von den Leuten nur geschimpft wird, anstelle daß mal zur Kenntnis genommen wird, daß wir hier mit dem Feature auf die Wünsche kleinerer Kunden reagiert haben (wird uns ja häufig vorgeworfen, daß wir das nicht mehr tun), ist dann um so enttäuschender. Ob ich das nochmal mache...

Ich habe meine Aussagen nicht auf Dich bezogen, sondern auf Lancom insgesamt. Den Hintergrund, wie es zu diesem Feature kam, kann ich ja auch unmöglich kennen. Nachdem Du das Feature durchgeboxt hast, gehe ich davon aus, dass Du viele der Dinge, die da so nach außen gehen auch nicht immer als komplett ausgereizt und fertig entwickelt wahrnimmst bzw. auch Features wichtig sind, die nicht vom nächsten potentiellen Großkunden gefordert werden. Typischerweise passiert das mit Software, wenn das Produktmanagement für einzelne Features nicht die Zeit zugesteht, die man für eine angemessene Umsetzung (Validierung, UI/Dialoge, Sonderfälle) wirklich benötigt. Die angesprochene Use Case Überladung einzelner Dialoge ist häufig ein weiteres Symptom dafür. Hier fände ich mal eine weitere Analyse der genauen Ursache-Wirkung-Zusammenhänge spannend. Aber das ist kein Thema für diesen Thread.

Bitte lies das "Schimpfen" nochmal genau. Ich hoffe, Du stellst dann fest, dass das alles Verbesserungsvorschläge sind. Verbesserungsvorschläge macht man nicht für Produkte, die einem egal sind. Oder findest Du die Anmerkungen aus Sicht der tatsächlichen Nutzer (nicht dem Lancom Vertrieb!) nicht nachvollziehbar?

[alf29]

Oder findest Du die Anmerkungen aus Sicht der tatsächlichen Nutzer (nicht dem Lancom Vertrieb!) nicht nachvollziehbar?

Wenn ich sie als konstruktiv empfinde ja - was in diesem Fall nicht so war.

Gruß Alfred