net-snmp auf 7270 mit freetz

[makki]

Hallo,

bin noch ziemlich neu in der freetz Materie, hab aber nun gestern mein erstes Image gebacken bekommen, soweit klappt alles ganz gut..
Daher erstmal ein Danke an die fleissigen, die das ermöglicht haben!

Aber nun kommen auch die ersten problemchen, ich bekomme partout den snmpd nicht ans rennen.

Ist gestartet, läuft und horcht auch (geprüft mit ps&netstat), Regeln aus ar7.cfg entfernt:
Antwortet einfach nicht, weder via LAN noch via VPN

snmpd.conf (1:1 ausser "public")

com2sec notConfigUser  default       public
group   notConfigGroup v1           notConfigUser
group   notConfigGroup v2c           notConfigUser
view    all           included   .1
access  notConfigGroup ""      any       noauth    exact  all none none

Die Suche hab ich auch benutzt, ist zum Thema snmp nur nicht sehr ergiebig.. Ideen ?

Makki

 

[olistudent]

Wir sind hier ja auch kein snmp-Forum. ;-)

Außerdem sind deine Infos sehr spärlich.

MfG Oliver

 

[makki]

@oliver: zu 1) das ist mir schon aufgefallen
zu 2) was für Infos wären denn notwendig ?
Plattform & Version habe ich genannt, sonst ist ausser der snmpd.conf auch nichts verändert worden.
snmpwalk am abfragenden Rechner behaupte ich mal ganz frech kann ich bedienen, ich will also nicht erklärt bekommen wie snmp funktioniert oder wofür man das braucht.

Die primäre Frage wäre ob sich vielleicht um ein generelles Problem handelt, sprich das net-snmp in genannter Konstellation garnicht funktioniert oder wo man ansetzen kann zu suchen ?
Wiegesagt, der daemon läuft und horcht auf Port 161/udp, es wird auch die richtige übers freetz-webif veränderte config genommen

/var/mod/root # cat /var/log/snmpd.log
NET-SNMP version 5.1.2

es kommt nur absolut keine Antwort raus.
Das Problem kann natürlich auch eine mir noch unbekannte Spezialität der Fritz/freet sein, das ist mein "täglich Brot", auf einem Debian bekomme ich net-snmp normalerweise alleine zum laufen

Makki

 

[olistudent]

Du könntest strace auf die Box bringen an den Prozess "attachen" und schauen ob sich was tut, wenn du eine Anfrage schickst. Da ich nichtmal weiß was man mit net-snmp macht kann ich dir leider keine spezifischen Hinweise liefern.

MfG Oliver

 

[makki]

ok, Danke.. der Plan klingt gut, nachdem es auch anhand der 10 hits bei der Suche nach snmp im Forum unwahrscheinlich ist dass jemand anderes das Problem - falls vorhanden - jemals haben wird..
strace, noch nie verwendet, schon gleich garnicht auf einer fritzbox also erstmal zusehen wie ich an eine binary dafür komme; mehr hoffentlich in Kürze..

Makki

 

[olistudent]

make strace-precompiled

Binary aus packages/strace-... auf die Box bringen und mit

./strace -p pidofsnmpd

den Prozess beobachten.

MfG Oliver

 

[makki]

Zu spät, ich hatte bereits strace im make menuconfig aktiviert und die binary aus dem build/modified.. kopiert
aber was "make xxx-precompiled" angeht was gelernt, das wäre die übernächste Frage gewesen, weil auf den Büchsen ja leider so gut wie garkein Platz ist und das wohl öfters vorkommen wird..

Nun denn ich kann mit dem output wenig anfangen, hab aber jetzt einen Verdacht dass es in richtung source-interface geht; kann ich aber erst morgen testen weil die Box im Büro steht und ich momentan nur per VPN draufkomme..
Also (das ist ein snmpwalk) es kommt jedenfalls was an und danach passiert auch irgendwas.

/var/tmp # ps | grep snmp
 2836 root      2336 S    snmpd -c /tmp/flash/snmpd.conf -Lf /dev/null -p /var/run/snmpd.pid
 2839 root      1156 S    grep snmp
/var/tmp # ./strace -p 2836
Process 2836 attached - interrupt to quit
_newselect(5, [4], [], [], NULL)        = 1 (in [4])
brk(0x472000)                           = 0x472000
recvfrom(4, "0\'\2\1\0\4\7public\241\31\2\4;\323\335%\2\1\0\2\1\0000\v0\t"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(40145), sin_addr=inet_addr("172.30.30.18")}, [16]) = 41
gettimeofday({1227132359, 745945}, NULL) = 0
brk(0x473000)                           = 0x473000
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8913, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(6, 0x8913, {ifr_name="lan", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_ALLMULTI|IFF_MULTICAST}) = 0
ioctl(6, 0x8915, {ifr_name="lan", ifr_addr={AF_INET, inet_addr("172.17.16.1")}}) = 0
close(6)                                = 0
gettimeofday({1227132359, 755945}, NULL) = 0
_newselect(5, [4], [], [], NULL)        = 1 (in [4])
recvfrom(4, "0\'\2\1\0\4\7public\241\31\2\4;\323\335%\2\1\0\2\1\0000\v0\t"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(40145), sin_addr=inet_addr("172.30.30.18")}, [16]) = 41
gettimeofday({1227132360, 745945}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8913, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(6, 0x8913, {ifr_name="lan", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_ALLMULTI|IFF_MULTICAST}) = 0
ioctl(6, 0x8915, {ifr_name="lan", ifr_addr={AF_INET, inet_addr("172.17.16.1")}}) = 0
close(6)                                = 0
gettimeofday({1227132360, 765945}, NULL) = 0
_newselect(5, [4], [], [], NULL)        = 1 (in [4])
recvfrom(4, "0\'\2\1\0\4\7public\241\31\2\4;\323\335%\2\1\0\2\1\0000\v0\t"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(40145), sin_addr=inet_addr("172.30.30.18")}, [16]) = 41
gettimeofday({1227132361, 755945}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8913, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(6, 0x8913, {ifr_name="lan", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_ALLMULTI|IFF_MULTICAST}) = 0
ioctl(6, 0x8915, {ifr_name="lan", ifr_addr={AF_INET, inet_addr("172.17.16.1")}}) = 0
close(6)                                = 0
gettimeofday({1227132361, 765945}, NULL) = 0
_newselect(5, [4], [], [], NULL)        = 1 (in [4])
recvfrom(4, "0\'\2\1\0\4\7public\241\31\2\4;\323\335%\2\1\0\2\1\0000\v0\t"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(40145), sin_addr=inet_addr("172.30.30.18")}, [16]) = 41
gettimeofday({1227132362, 755945}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8913, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(6, 0x8913, {ifr_name="lan", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_ALLMULTI|IFF_MULTICAST}) = 0
ioctl(6, 0x8915, {ifr_name="lan", ifr_addr={AF_INET, inet_addr("172.17.16.1")}}) = 0
close(6)                                = 0
gettimeofday({1227132362, 765945}, NULL) = 0
_newselect(5, [4], [], [], NULL)        = 1 (in [4])
recvfrom(4, "0\'\2\1\0\4\7public\241\31\2\4;\323\335%\2\1\0\2\1\0000\v0\t"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(40145), sin_addr=inet_addr("172.30.30.18")}, [16]) = 41
gettimeofday({1227132363, 775945}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8913, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(6, 0x8913, {ifr_name="lan", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_ALLMULTI|IFF_MULTICAST}) = 0
ioctl(6, 0x8915, {ifr_name="lan", ifr_addr={AF_INET, inet_addr("172.17.16.1")}}) = 0
close(6)                                = 0
gettimeofday({1227132363, 785945}, NULL) = 0
_newselect(5, [4], [], [], NULL)        = 1 (in [4])
recvfrom(4, "0\'\2\1\0\4\7public\241\31\2\4;\323\335%\2\1\0\2\1\0000\v0\t"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(40145), sin_addr=inet_addr("172.30.30.18")}, [16]) = 41
gettimeofday({1227132364, 785945}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8912, {128, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"lan", {AF_INET, inet_addr("172.17.16.1")}}, {"lan:0", {AF_INET, inet_addr("169.254.1.1")}}, {"dsl", {AF_INET, inet_addr("169.254.2.1")}}}}) = 0
ioctl(6, 0x8913, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(6, 0x8913, {ifr_name="lan", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_ALLMULTI|IFF_MULTICAST}) = 0
ioctl(6, 0x8915, {ifr_name="lan", ifr_addr={AF_INET, inet_addr("172.17.16.1")}}) = 0
close(6)                                = 0
gettimeofday({1227132364, 785945}, NULL) = 0
_newselect(5, [4], [], [], NULL

Edit: zur Erklärung, 172.17.16.1 ist die LAN-IP der FBF und 172.30.30.18 ist der Rechner an dem snmpwalk ausgeführt wurde.. Teste das aber morgen nochmal lokal.

Makki

 

[makki]

So, das hat mir jetzt doch keine Ruhe gelassen, nachdem ich schon auf den richtigen Weg geführt wurde und gesehen hab dass Pakete rausgehen..

Ursache: die mitgelieferte Default snmpd.conf (die ja anders als die von mir gepostete ist aber gleicher Syntax) funktioniert schlicht nicht. Warum, keine Ahnung..

Schreibt man stattdessen nur folgendes in die snmpd.conf gehts erstmal; syslocation und syscontact sind natürlich optional

rocommunity  public
syslocation Mein-Standort
syscontact [email protected]

Traumhaft, hostmib ist auch vorhanden

Zweites problem dass ich dann jetzt noch hatte: beim Zugriff via VPN scheiterts (mal wieder) an der source-adresse.
Die kann man beim Daemon-start mitgeben, soweit kein Problem, aber wie bekomme ich das init-script (/etc/init.d/rc.netsnmp ?) möglichst sauber und dauerhaft geändert ? Müsste da ja dann noch was dazufummeln, um die jeweils aktuelle, dabei die sich möglicherweise ändernde LAN-IP zu verwenden.
Edit: Vielleicht zur Erklärung, am liebsten wäre mir eine Lösung die auch nach dem nächsten neuerstellen des Images oder freetz-Updates noch funktioniert, weil ich da mehr mit mehreren Fritzboxen vorhabe

Makki

 

[cuma]

Gib doch die IP "0.0.0.0" an, die gilt für alle Interfaces. Und danke für die Info mit der Config, ich hatte das schonmal erfolglos ausprobiert.
PS: Wenn dein Image zu klein ist schau mal im Forum nach external und evtl zusätzlich downloader

 

[olistudent]

Kannst du bitte mal rausfinden was an der Freetz config nicht funktioniert, damit wir das ändern können?

MfG Oliver

 

[cuma]

Ich baue seit 1 Monat wieder ein Image :-] Morgen teste ich das mal

 

[makki]

@cuma: 0.0.0.0 - sprich alle Interfaces - ist ja Standard, das funktioniert aber, warum auch immer, auch bei eigehenden Geschichten nicht übers VPN von aussen (und darum gehts mir eigentlich).
Das mit dem auslagern von Files werd ich noch lernen müssen, bisher seeeehr manuell.. Hat mich heute bestimmt ne Stunde gekostet den dropbear "extern" zum laufen zu bekommen, da kommen bestimmt noch dumme Fragen

@oliver: klar, nachdem ich jetzt weiss wo ich suchen muss, kann das morgen mal durchprobieren;
ich vermute aber fast dass an der "neuen" Syntax evtl. mit der verwendeten net-snmp Version generell was nicht geht. Die Standardconfig ist theoretisch jedenfalls völlig richtig, muss mich da aber erst einlesen.. (Die Lösung, rocommunity ist AFAIR noch die rückwärtskompatible Syntax vom UCD-SNMP)

Wenn das für den 8. Post nicht zu gierig ist, würde ich vielleicht sogar vorschlagen den snmpd "Standardmässig" - so das package überhaupt ausgewählt wurde, was ja die wenigstens "aus Versehen" machen dürften - nur auf die LAN-IP zu binden.
Der Internetseitige-Missbrauch ist damit ausgeschlossen und ich behaupte mal die meisten die SNMP nutzen tun das entweder von "innen" oder (hoffentlich) via VPN aus der Zentrale; der "unschuldige" wäre damit aureichend geschützt und wers will, kann es ohne grosses rumprobieren und ändern von configs nutzen. (damit snmp *nicht* geht ha ja AVM schon weitreichend vorgesorgt ["was haben die geraucht"])
Das init-script entsprechend anpassen und posten kann ich machen, der Rest mit Makefile&Co ist jenseits meiner aktuellen Möglichkeiten

Trotzdem wär ich für nen kurzen Tipp dankbar wie man das init-script effektiv ändert (einfach auf der build-VM in ./root/etc/init.d reinlegen ?), weil snmp ist für mich doch ein relatives "Key-feature"..

Makki

 

[cuma]

Die Dateien liegen in ./make/<paketname>/files/root

 

[makki]

Also mein Vorschlag für eine Default snmpd.conf wäre wie folgt

rocommunity public 192.168.0.0/16
sysname fritz.box
syslocation unknown - edit via freetz webif
syscontact unknown@unknown - edit via freetz webif
sysservices 78

Das ist sicher (Zugriff beschränkt auf 192.168.0.0/16), vollständig, funktioniert und IMHO wesentlich übersichtlicher als das "Standardbeispiel" das dem net-snmp als beiliegt (com2sec, group, view, access - das braucht ja kein Mensch..)


Optional, für SNMP-zugriff via VPN notwendig (x = LAN-IP der Fritzbox)

agentaddress x.x.x.x

Damit ist auch keine Änderung des Init-scripts notwendig..

Damit wird auch unabhängig von Firewallregeln der Zugriff von aussen unterbunden weil sich der snmpd nur auf diese IP bindet, die Default Firewallregeln in der ar7.cfg verhindern das aber auch..

Makki

 

[cuma]

2 Punkte verstehe ich nicht:
-Von Aussen ist eh kein Zugriff auf snmp möglich, ausser man hat ein Portvorwarding eingerichtet. Oder gibts da eine Hintertür?
-Weshalb muss man die interne IP angeben, wenn man per VPN darauf zugreifen will? Man gibt damit doch nur die Server-IP an, auf der gehorcht wird
Das ganze ist natürlich wesentlich lesbarer als die alte (vorhandene) Konfiguration funktionier nur leider noch nicht bei mir "error on SnmpMgrRequest 40" :-[

 

[makki]

Ich kenne Linux und "normale" Router, da wäre es erstmal so, dass wenn kein Filter existiert und der snmpd sich auf alle Interfaces bindet, das auch erstmal fürs WAN gilt. Da weiss ich aber zuwenig über die Fritz-spezifischen internas, das läuft ja irgendwie anders.. Es sollte so (mit dem binden nur auf die LAN-IP jedenfalls völlig unbedenklich sein.

Das binden auf die LAN-IP, ändert gleichzeitig die Sourceadresse für die Antworten, die sonst schlicht nicht ankommen. Warum und wieso es das nun bringt weiss ich nicht, es reicht mir aber auch wenns einfach geht

Was geht denn bei Dir nicht (lokal oder via VPN) und woher stammt die Fehlermeldung "error on SnmpMgrRequest 40" ? Vielleicht kann ich mich ja revanchieren..

Makki

 

[derheimi]

Also wenn ich auchmal was dazu sagen darf: ich finde, dass die derzeite Default-Konfiguration, welche bei Freetz enthalten ist, allen Bedürfnisse entspricht und ohne sachliche Argumente NICHT geändert werden sollte. Denn was macht diese Default-Konfiuguration? Sie ist gerade dafür ausgelegt, dass man das Paket ohne tiefere Kenntnisse von der Materie auswählen und aktivieren kann und schon kann man die Box via SNMP abfragen.
Dabei wird unterschieden, ob die Abfrage aus einem privaten IP-Adressbereichen kommt (192.168.0.0/16 bzw. 168.254.0.0/16 -> deckt damit die meisten Standardinstallationen ab). In diesem Fall erhält man Lesezugriff auf den gesamten MIB-Baum. Sollte wiedererwarten eine andere Adresse anfragen, erhält sie nur Lesezugriff auf den system-Zweig der MIB.
Wer ausgeklügeltere Zugriffsrechte braucht, kennt sich mit der Materie aus und kann das selbst einfach konfigurieren.

Die mitgelieferte Default-Konfig funktioniert im übrigen und ist von mir selbst getestet. Ich würde es gut finden, wenn Du solche Behauptungen in Zukunft mit Fakten untermauerst.

Den Vorschlag, die Listen-Address auf die LAN-Adresse einzuschränken, halte ich für inakzeptabel, da Du nicht weißt, welche Interfaces auf dem Zielsystem vorhanden sind und auf welchem der User SNMP verwenden will. Ich halte es nicht für sinnvoll, dann im WebInterface eine Liste o.ä. anzubieten, wo man dass dann konfigurieren kann.
Es kann allerdings durchaus sein -das hab ich selbst noch nicht getestet-, dass der snmpd wirklich mit der falschen IP-Adresse antwortet. Dies ist gerade bei udp-basierten Diensten ein alter Hut. Wenn dies so ist, sollten wir das Problem aber bei der Wurzel packen und ein entsprechenden Patch einbinden, anstatt durch eine Workaround-Konfiguration das Problem zu verschleiern. Wir haben hier ja den Vorteil von OpenSource - nutzen wir sie doch.

com2sec, group, view, access - das braucht ja kein Mensch..)

Achso, na dann. Und mehr als 640 KB RAM braucht ja auch keiner. SCNR

 

[makki]

Denn was macht diese Default-Konfiuguration? Sie ist gerade dafür ausgelegt, dass man das Paket ohne tiefere Kenntnisse von der Materie auswählen und aktivieren kann und schon kann man die Box via SNMP abfragen.

Ich habe nicht behauptet dass die Default-cfg generell nicht geht (sondern das Gegenteil geschrieben, dass sie syntaktisch richtig ist), nur dass es eben bei mir nicht ging.

Gut, was ich erst jetzt rausgefunden habe und eben nochmal getestet: Es lag letztlich an der Source-IP, weil das erstbeste Interface zum antworten verwendet wird und 169.254.x.y, was bei mir in /dev/null landet
Letztlich also ein Bug, der behoben werden sollte, für hier und heute hilft mir aber der Workaround mit "agentadress".
Ich würde es zwar trotzdem aus Sicherheitsgründen explizit auf die LAN-IP binden, aber das ist Geschmackssache..

Die Default-config ist trotzdem unvollständig: syslocation und syscontact sollten nicht fehlen, das muss der Anwender nämlcih sonst erst irgendwo rausfieseln und eben IMHO unnötig kompliziert, weil man dasselbe, funktionierenden SNMP-Zugriff aus dem LAN auch mit einer einzigen statt 14 Zeilen realisieren kann und jeder sofort erfasst wo er was für seine Bedürfnisse anpassen muss ohne stundenlang Doku zu wälzen..
Von aussen, wo "paranoid" und "system" greifen würden gehts wegen der Regeln in der ar7.cfg von AVM eh nicht..

Das mit der Listen-adresse steht unter "optional" und war eher als Hinweis für diejenigen gedacht die es eben über VPN nutzen wollen. Ebensowenig habe ich vorgeschlagen die Source-IP im webif auswählen zu können..

Ist mir auch egal, das Ziel wäre aber dasselbe: es sollte aus der Box einfach funktionieren.

Achso, na dann.

Naja, ich hab ~400 Hosts mit SNMP am laufen, arbeite seit rund 10 Jahren damit und hatte AFAIR genau ein einziges mal den Bedarf den Zugriff mit einer View einzuschränken. Die verwendung des anderen wird ja deswegen nicht verboten. Aber warum einfach wenns auch kompliziert geht

Makki

 

[cuma]

Die syslocation, sysname und syscontact sollte man dann noch zusätzlich aufnehmen. Und agentaddress mit der default-IP 192.168.178.1 ist eigentlich auch sinnvoll, da das Probleme geben kann solange kein Patch zum beheben vorhanden ist.
Den einen oder anderen Kommentar zu den bestehenden Einträgen würde mich auch freuen, die sind doch sehr kryptisch, und ich bin mir nicht so ganz sicher ob ich diese tatsächlich alle brauche. Ich wollte eigentlich nur den Status der Box abfragen :-]

Hab es jetzt auch hinbekommen, Ursache war wahrscheinlich die IP. Meine Box ist im ATA Modus und Port 4 des Switches ist gesplittet mit einer IP aus einem anderen Bereich. Die 169.x.x.x gibt es bei mir nicht (mehr)

 

[derheimi]

Also ich stimme zu, dass die Sachen syslocation... konfigurierbar gemacht werden sollten. Was schwebt Euch da vor? Ein Eingabefeld oder soll die Zeile einfach nur in der Konfigdatei auftauchen?

Ich habe mir gerade nochmal die Erklärungen auf der net-snmp-Webseite durchgelesen. Von mir aus können wir das auch mit rocommunity machen, ich persönlich finde die neuere Syntax besser - aber es ist halt Geschmackssache.

Wenn wir agent address wirklich verwenden wollen, brauchen wir für die initiale Konfiguration eine Erkennung der derzeitigen IP-Addresse. Außerdem sollte dann ein Kommentar in der Konfig mit auftauchen, dass diese IP ggf. später manuell geändert werden muss. Oder aber, die Zeile wird gänzlich automatisch eingefügt.
Es hängt also davon ab, wie die Konfiguration zukünftig gemanaged werden soll.

Ich schlage vor, dass als Ticket für freetz-1.2 festzuhalten da 1.1 vermutlich bald kommen wird. Ich hab auch zur Zeit ziemlich viel um die Ohren, also wenn jemand nen Patch liefert, ich stehe gern als Tester zur Verfügung.