Antennen richtig ausrichten (5GHz)

Forum zu den aktuellen LANCOM Wireless Accesspoint Serien

Moderator: Lancom-Systems Moderatoren

Benutzeravatar
Endorphin
Beiträge: 33
Registriert: 12 Mai 2005, 16:09
Kontaktdaten:

Beitrag von Endorphin »

alf29 hat geschrieben:in der Tabelle Status/WLAN/Interpoint/Accesspoint
auf das 'Link-PHY-Signal' schauen, das ist die Stärke, mit der die Beacons des
Partners empfangen werden - und die kommen 10-mal in der Sekunde.
Mal eine andere Frage: was für eine Einheit wird da ausgegeben? Ist das der Rauschleistungsabstand des empfangenen Signals in dB?

Gleiches für den LANmonitor. Dort gibt es ja eine Anzeige für "signal strength", die Prozentwerte anzeigt. Was entspricht denn dort 100%? Offenbar ist das ja der gleiche Wert wie das "Rx-PHY-Signal". Kann ich mir was drauf einbilden, dass unsere P2P-Strecke jetzt im Winter mit laublosen Bäumen in der Fresnelzone ~51% erreicht? ;-)

Irgendwie fehlt zur Kommandozeile eine genaue Dokumentation. Ideal wäre natürlich eine Online-Hilfe an der Kommandozeile, wo mit "help ." (oder so) alle Werte in einem Verzeichnis genauer erklärt werden. Die Zahlen sind ja schön anzusehen, nur sagen sie nichts aus, wenn man nicht weiß, wie man sie interpretieren kann.
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Mal eine andere Frage: was für eine Einheit wird da ausgegeben? Ist das der Rauschleistungsabstand des empfangenen Signals in dB?

Gleiches für den LANmonitor. Dort gibt es ja eine Anzeige für "signal strength", die Prozentwerte anzeigt. Was entspricht denn dort 100%? Offenbar ist das ja der gleiche Wert wie das "Rx-PHY-Signal". Kann ich mir was drauf einbilden, dass unsere P2P-Strecke jetzt im Winter mit laublosen Bäumen in der Fresnelzone ~51% erreicht? Wink
100% -> 64dB SNR oder mehr, kleinere Werte skalieren linear herunter.
Irgendwie fehlt zur Kommandozeile eine genaue Dokumentation. Ideal wäre natürlich eine Online-Hilfe an der Kommandozeile, wo mit "help ." (oder so) alle Werte in einem Verzeichnis genauer erklärt werden. Die Zahlen sind ja schön anzusehen, nur sagen sie nichts aus, wenn man nicht weiß, wie man sie interpretieren kann.
Das mit der Kommandozeilendoku ist so eine Sache. Irgendwie findet keiner Zeit dafür.
und so viele Leute benutzen die CLI dann doch wieder nicht...

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
Benutzeravatar
Endorphin
Beiträge: 33
Registriert: 12 Mai 2005, 16:09
Kontaktdaten:

Beitrag von Endorphin »

Danke für die Information.
zig123
Beiträge: 11
Registriert: 27 Nov 2005, 16:57

Beitrag von zig123 »

Das mit der Kommandozeilendoku ist so eine Sache. Irgendwie findet keiner Zeit dafür.
und so viele Leute benutzen die CLI dann doch wieder nicht...
Also zu den Interfaces kann ich sagen: Als ich vor ein paar Wochen das erste mal einen L-54ag in der Hand hatte waren mir alle unsympathisch - zuerst habe ich mich nur durch das Basic-Webfrontend gekämpft. Mittlerweile bevorzuge ich die CLI weil ich dadurch einfach schneller und von überall auf den Geräteoperieren kann. Zum Management-Programm greife ich wenn ich mangels keine Ahnung habe, welche Werte er in diesem Feld will - ich ändere sie im Manager und schau mir an wie die im CLI aussehen und benutz dann selbiges ab diesem Zeitpunkt.

Auch die MIB läßt zu wünschen übrig - positiv zu vermerken das sie überhaupt mitgeliefert wird und doppelt gut das sie auf jedem Gerät direkt abrufbar ist... aber wenn ich die Dokumentation in der Mib vergleiche - ohje gar nichts.... Beispiel:

staWlanInterpAccRxphys OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "Rx-Phy-Signal"
::= { staWlanInterpAccEntry 13 }

Die Description ist schon sehr aussagekräftig... *soifz*

Man könnte sich mal ein Beispiel an den Cisco-Mibs nehmen:
tftpAction OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- none of the following
downloadConfig(2),
uploadConfig(3),
downloadSw(4),
uploadSw(5),
downloadFw(6),
uploadFw(7)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION "Setting this object to one of the acceptable
values initiates the requested action using the
information given in tftpHost, tftpFile,
tftpModule.

downloadConfig(2): receive configuration from
host/file
uploadConfig(3) : send configuration to
host/file
downloadSw(4) : receive software image from
host/file
uploadSw(5) : send software image to
host/file
downloadFw(6) : receive firmware image from
host/file
uploadFw(7) : send firmware image to
host/file
Setting this object to any other value results in
an error."
::= { tftpGrp 4 }

mit so einer Description kann man mit der Mib auch vernünftig arbeiten - vor allem wenn man versucht wie ich alles in SNMP umzusetzen :)
eddia
Beiträge: 1239
Registriert: 15 Nov 2004, 09:30

Beitrag von eddia »

Hallo zig123,
Mittlerweile bevorzuge ich die CLI weil ich dadurch einfach schneller und von überall auf den Geräteoperieren kann.
Tja - leider scheint bei Lancom die Dokumentation von CLI und SNMP keine Priorität zu besitzen. Selbst im Webinterface kann man oft nur raten, wofür eine Option nun steht. Und LanConfig stellt ja nur ein Subset aller Optionen bereit.
Auch die MIB läßt zu wünschen übrig
Ich hab mal vor über einem Jahr versucht, die MIB zur Überwachung des Lancoms in ein Management-System zu integrieren. Klappte trotz der vorhandenen TRAP-Types nicht - abgesehen davon, dass die NMS-Erweiterungen für Traps in der MIB ebenfalls nicht vorhanden sind.

Gruß

Mario
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,

die jetzigen MIBs haben den Vorteil, daß sie automatisch aus dem Menübaum erzeugt
werden können und damit wenigstens immer mit der Realität des Menübaum
übereinstimmen - ganz früher wurden sie mal manuell 'gepflegt', da hat dann noch nicht
einmal das geklappt...
Tja - leider scheint bei Lancom die Dokumentation von CLI und SNMP keine Priorität zu besitzen. Selbst im Webinterface kann man oft nur raten, wofür eine Option nun steht. Und LanConfig stellt ja nur ein Subset aller Optionen bereit.
Eigentlich sollte das die Aufgabe des Referenzhandbuchs sein, aber da gibt es aus
verschiedenen Gründen leider einen ziemlichen 'Backlog'. Und mal ehrlich: Würde
irgendjemand freiwillig auf eine neue LCOS-Version einen weiteren Monat warten
wollen, bis die Doku bis aufs i-Tüpfelchen fertig ist? Die Doku kann nun einmal erst
beginnen, wenn das Feature fertig ist...
Klappte trotz der vorhandenen TRAP-Types nicht - abgesehen davon, dass die NMS-Erweiterungen für Traps in der MIB ebenfalls nicht vorhanden sind.
Was soll das bitte sein?

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
eddia
Beiträge: 1239
Registriert: 15 Nov 2004, 09:30

Beitrag von eddia »

Hallo Alfred,
Und mal ehrlich: Würde irgendjemand freiwillig auf eine neue LCOS-Version einen weiteren Monat warten
wollen, bis die Doku bis aufs i-Tüpfelchen fertig ist? Die Doku kann nun einmal erst
beginnen, wenn das Feature fertig ist...
Na ja - die Doku fehlt aber prinzipiell für den Bereich CLI und Webinterface.
Was soll das bitte sein?
Das sind Erweiterungen zur Auswertung im NMS. Die sind eigentlich in den MIBs aller Hersteller enthalten. Mal ein Beispiel für einen USV Trap-Type:

Code: Alles auswählen

communicationLost TRAP-TYPE
   ENTERPRISE upsman
   DESCRIPTION
       "SEVERE: Communication to the UPS has been lost. Check cable or network
        connections, steps to reestablish communication are in progress."
   --#TYPE "UPS: Communication failure"
   --#SUMMARY "Communication with the UPS has been lost."
   --#ARGUMENTS { }
   --#SEVERITY CRITICAL
   --#TIMEINDEX 1
   --#HELP ""
   --#HELPTAG 0
   --#STATE DEGRADED
   ::= 1
Die Einträge hinter --# sind die Erweiterungen. Besonders die Klassifizierung unter 'SEVERITY' dienen einfach der Übersicht in einem NMS, welchen Traps man sich besonders zuwenden sollte.

Da dies jedoch in der Lancom-MIB fehlt, ist jeder auch noch so unnütze Trap nicht klassifizierbar. Und da man im Lancom auch nicht einstellen kann, ab welcher Gefahrenstufe ein Trap versendet wird, bläst man sich sein NMS mit vielen informellen traps zu. Abgesehen davon, dass Meldungen wie 'FwUplStart' oder 'UplFailBadDev' oder auch 'IpFwFlt' nicht gerade selbst erklärend sind.

Gruß

Mario
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,
Na ja - die Doku fehlt aber prinzipiell für den Bereich CLI und Webinterface.
...und ich fürchte, das wird auf absehbare Zeit so bleiben. Im Produktmanagement
wird auf die Geräte nur durch die LANtools-Brille geschaut, und die Großkunden
haben ihre eigenen Managementsysteme, für deren Integration der FAE persönlich
vorbeikommt :-/
Das sind Erweiterungen zur Auswertung im NMS. Die sind eigentlich in den MIBs aller Hersteller enthalten.
Hm - kann mich nicht erinnern das schonmal irgendwo gesehen zu haben - jedenfalls
nicht in den RFCs, in denen ich schonmal MIBs sehe. Gibt's dafür irgendeinen
Standard (RFC, IEEE...)?
Abgesehen davon, dass Meldungen wie 'FwUplStart' oder 'UplFailBadDev' oder auch 'IpFwFlt' nicht gerade selbst erklärend sind.
Wie gesagt, die MIBs werden von Gerät automatisiert aus dem Menübaum der CLI bzw.
der WEBconfig-Expertenkonfig erzeugt. Mehr ist im Moment resourcenmäßig einfach nicht
drin. Tut mir leid...

Gruß Alfred
eddia
Beiträge: 1239
Registriert: 15 Nov 2004, 09:30

Beitrag von eddia »

Hallo Alfred,
Hm - kann mich nicht erinnern das schonmal irgendwo gesehen zu haben - jedenfalls
nicht in den RFCs, in denen ich schonmal MIBs sehe. Gibt's dafür irgendeinen
Standard (RFC, IEEE...)?
Das kann ich Dir auch nicht beantworten. Ich gehe nur von den mir vorliegenden MIBs aller möglichen Hersteller aus - und da sind diese Erweiterungen prinzipiell enthalten. Ich denke mal, dass ich mir weitere Beispiele ersparen kann(?)

Gruß

Mario
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,
und da sind diese Erweiterungen prinzipiell enthalten. Ich denke mal, dass ich mir weitere Beispiele ersparen kann(?)
Nuja, wenn irgendwann bei uns jemand so etwas mal implementieren soll, dann
müßte da schon erstmal eine Spezifikation her...die anderen Hersteller haben sich
das ja wohl auch nicht einfach aus den Fingern gesogen ;-)

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
zig123
Beiträge: 11
Registriert: 27 Nov 2005, 16:57

Beitrag von zig123 »

Klappte trotz der vorhandenen TRAP-Types nicht - abgesehen davon, dass die NMS-Erweiterungen für Traps in der MIB ebenfalls nicht vorhanden sind.
Was soll das bitte sein?

Gruß Alfred[/quote]

Traps sind schon im normalen Standard zu SNMP (RFC1076) enthalten.

Zitat:
It is mandatory that all implementations of the SNMP support the five
PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
SetRequest-PDU, and Trap-PDU.

Ein Trap ist nichts anderes als eine Notification an ein NMS über ein eingetretenes Ereignis was vom Client aus initiiert wird. z.B. Link Down etc...

Traps bestehen als normalen PDU-Paketen und werden ebenfalls durch eine OID eindeutig identifizierbar - Um nun diese Traps sinnvoll zu interpretieren ist es wichtig das man weiss was sie bedeuten - und dazu müssen sie in der Mib stehen.

Gruss,
zig
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6207
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Beitrag von alf29 »

Moin,

ich bezog mich in meiner Frage auf die 'NMS-Erweiterungen'. Daß wir wissen, was
Traps an sich sind, dürfte klar sein...

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
eddia
Beiträge: 1239
Registriert: 15 Nov 2004, 09:30

Beitrag von eddia »

Hallo Alfred,
Nuja, wenn irgendwann bei uns jemand so etwas mal implementieren soll, dann
müßte da schon erstmal eine Spezifikation her...die anderen Hersteller haben sich
das ja wohl auch nicht einfach aus den Fingern gesogen
Ich hab mal ein wenig geschaut. Als Hinweis kommt immer wieder ISO/IEC 10165-4. Und dann gibt es da noch RFC1470 - ok hat nur FYI Status.

Gruß

Mario
Antworten