[Discuss] Adress-Vergabepraxis, Aktualität der Daten, neue Konfigurationskonzepte - war: Re: [Wien] ip-adresse (KNOTENDICHTE)

[Markus Kittenberger]

> 90% laufen mit (am webinterface) leicht zu erkennenden firmwares, gibt
auch schon 2-3 fertige tools die derartiges machen,..

Allerdings wirklich oft gebraucht/verwendet wurden diese (im allgemeinen)
nie, imho ists auch meist nit so wichtig welche firmware wo lauft,
wichtiger ist ob sie funktionieren, und da gibts meisten wenig zusammenhang
mit der firmware version, viel öfter liegts an der config.

lg Markus


2013/11/26 (spam-protected) <(spam-protected)>

> Am 25. November 2013 21:59 schrieb Felix Ehritz <
> (spam-protected)>:
>
>> Ich möchte hier auch meinen senf dazu geben:
>> <SENF>
>> Auch wenn ich bei diesem Thema weit weg von der Materie bin wäre es evtl
>> zu überlegen ob man nicht irgendwo etwas einbaut, das die aktuelle
>> hard/firmware der eingesetzten Geräte zusammen zentral abfragt. Ähnlich des
>> aktuellen olsr interface am z.b. tunnelserver nur halt
>> knoten/ips/hardware/firmware+version.
>>
> Ja, diese Daten wären sicher auch interessant. Aber vermutlich nur bei von
> uns (Joe) entwickelter Firmware machbar. Bei Geräten die mit Fremdfirmware
> laufen wirds sehr schwer werden, automatisiert Hard- und Firmware
> festzustellen. Müsste man sich für jedes Gerät ansehen, was für
> spezifisches Verhalten es zeigt, an Hand dessen man es von Anderen
> unterscheiden könnte. Eher nicht mit realistischem Aufwand bewältigbar.
>
>
>> Erstens würde man sehr schön sehen wie die einzelnen IPs aufgeteilt sind
>> und welche Geräte mit welcher Firmware-Aktualität im Einsatz sind.....das
>> würde vielleicht Aufschluss geben auf welche images man mehr Rücksicht
>> nehmen sollte.
>> </SENF>
>> LG Felix
>>  Am 25.11.2013 16:36 schrieb "(spam-protected)" <(spam-protected)>:
>>
>>> Am 25. November 2013 16:31 schrieb L. Aaron Kaplan <(spam-protected)>:
>>>
>>>>
>>>> On Nov 25, 2013, at 4:26 PM, (spam-protected) wrote:
>>>>
>>>> > Bin auch dafuer, aber achtung, ich glaube da braucht es einen
>>>> Schalter im Webinterface / im UCI config:
>>>> > "Ich will dass mein Router per SNMP abgefragt werden kann JA/NEIN"
>>>> (mit default Wert "Nein")
>>>> >
>>>> > Also den Schalter halte ich auch für sinnvoll, um ein opt-out einfach
>>>> möglich zu machen.
>>>> > Ich würde dennoch default Wert auf JA setzen. Sonst können wir uns
>>>> die Arbeit gleich spaaren, denn großen Nutzen bringt uns das nur, wenn wir
>>>> damit einen großen Teil des Netzes abfragen können, was nur möglich ist mit
>>>> opt-out statt opt-in. (denn selbst bei opt-out haben wir nur einen gewissen
>>>> prozentsatz der diese firmware überhaupt verwenden wird)
>>>> >
>>>> >
>>>>
>>>>
>>>> Eh! Das stimmt schon.
>>>> Allerdings ist einfach der Opt-in der fairere Ansatz. Warum? Weil es
>>>> gab hier (oder auf wien@) mal  eine ganz grosse Diskussion wegen
>>>> Datenschutz. Im Zuge dessen wurde auch argumentiert, dass das Volumen an
>>>> Traffic von einem Node auskunft darueber gibt, ob die Person zu Hause ist
>>>> oder nicht. Der Effekt ist, dass diese Daten besser geschuetzt wurden.
>>>>
>>>
>>> Also Trafic-Volumen würd ich da sowieso nicht mitreinnehmen, weil es wie
>>> du schon argumentiert hast viel zu privat ist. Ich hatte eher an Latenz,
>>> Bandbreite (aus einer iperf messung oder sowas), Packet-Loss usw. zu jedem
>>> der vorhandenen Nachbarn gedacht.
>>>
>>>
>>>>
>>>> SNMP Daten sind aber potentiell viel genauer als das.
>>>> Sprich: entweder man macht ein opt-in Verfahren oder man ueberlegt sich
>>>> ein Opt-out aber dann muss man sich auch sehr genau ueberlegen, wie man die
>>>> Daten klassifizert, wie sie behandelt werden, welche Schutz-Mechanismen da
>>>> sind etc etc.
>>>> Sprich: es wird komplexer.
>>>>
>>>> Aber natuerlich gebe ich dir recht, dass ein Opt-in den Nachteil haben
>>>> wird, dass wenige Leute mitmachen.
>>>>
>>>
>>> Ein möglicher Kompromiss wäre vielleicht, die Entscheidung
>>> verprflichtend in den auch schon (bei den letzten Testtagen) viel
>>> diskutierten Config-Wizard der beim ersten aufrufen der Web-Config-Maske
>>> nach dem Firmware-flashen aufpoppen soll mit reinzunehmen, und somit den
>>> User zu zwingen ja oder nein zu drücken.
>>>
>>>
>>>>
>>>> lg,
>>>> a.
>>>>
>>>>
>>> LG, Thomas
>>>
>>>
>>> --
>>> Discuss mailing list
>>> (spam-protected)
>>> https://lists.funkfeuer.at/mailman/listinfo/discuss
>>>
>>
>
> --
> Discuss mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/discuss
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20131126/30e219b4/attachment.htm>