[Wien] HELO AS35492 spontaner besuch in wien => mitfunken

Erich N. Pekarek (spam-protected)
So Apr 13 12:17:27 CEST 2014


Hallo!

Am 2014-04-13 05:54, schrieb Daniel:
> Hallo Erich,
>
>
> On 04/13/2014 03:16 AM, Erich N. Pekarek wrote:
>>>    4mb reichen finde eigentlich auf dem dach (lieber dann noch nen
>>> "grossen" router im wohnbereich, der mehr kann z.b. VoIP oder VPN kram).
>> Mit Markus K. würdest Du Dich in der Hinsicht blendend verstehen ;-)
>> Ich sehe das differenziert: seit IPv6 eingeplant werden muss (und OpenWRT leider
>> nicht alle Mittel an Bord hat), werden die 4Mb beizeiten knapp.
>> Und Bootloops bei vollem Flash sind ungut, wenn das Ding am Dach hängt ...
> IPv6 geht meiner Erfahrung nach schon noch ohne Probleme mit 4Mb flash, selbst
> mit odhcp6c, 6relayd und/oder dnsmasq mit ipv6-support. Und falls OpenSSL wegen
> OpenVPN oder libsrtp fuer Asterisk rein sollen lasse ich dann lieber noch Lua,
> den ganzen LuCI kram und im Notfall auch uhttpd weg. Das wird in Zukunft ja auch
> schmaler werden mit LuCI2, weil HTML5+JS, also zumindest mal kein Lua
> interpreter mehr...
> Und in den batman-adv Netzen kann mensch dann richtig dreckig spahren und ohne
> dnsmasq, iproute2, iptables und so auskommen, aber das geht in nem Layer-3
> geroutetem Netz natuerlich nicht.
Naja, das ip-Utility könnte man zwar beispielsweise auf der busybox 
übernehmen, die Abhängigkeiten bei OpenWRT veranlassen es dann dennoch, 
während des Kompilierens ip(-full) ins Overlay nachzuinstallieren. Das 
ist ohne gröbere Modifikationen der Makefiles beginnend mit base-files 
nicht möglich.
Tayga wird zwar noch nicht gebraucht und uhttpd ist overkill, aber da 
sind ähnliche Probleme vorhanden...
Auf das Webinterface können und wollen wir nicht verzichten, da das 
Debuggen unnötig erschwert würde.
>> Der Quellcode ist auf www.openwrt.org. Die Modifikationen bestehen (meines
>> Wissens) in einem Autoconfig-Skript und Konfigurationsdateien samt
>> dropbear-public-keys und Logo. Du willst das nicht. Du willst Dir den Quellcode
>> von OpenWRT holen und sauber kompilieren, wo dann auch alle Paketquellen
>> vorhanden sind. Allenfalls nimmst Du noch den jow-Reghack laut OpenWRT-Forum
>> dazu...
> Ok, also einfach vanilla OpenWrt mit OLSR aus dem openwrt-routing feed.
Genau.
> jow's-reghack ist nur auf 2.4GHz relevant und ich hab eh immer
> CONFIG_ATH_USER_REGD=y gesetzt ;)
Der Reghack ist für snapshots interessant, wenn man dann doch nicht 
kompilieren will.

> Alles weitere kann dann ja noch konfiguriert werden.
>
>
>> Nur wenn Du es sehr eilig hast, probierst Du die vorkompilierten Firmwares von
>> z.B. hier:
>> ftp://oe1xrw.ozw.wien.funkfeuer.at/0xFF-Bubbles/2014-RC1/naked.Bubble/r109-2013-10-25/
> Ja ne, wenn das eh nur stock OpenWrt mit "normalen" OLSR ohne grossartige hacks
> ist, dann ist das schon erledigt. Trotzdem neugierig :)
>
>> Ein build.config findest Du dort.
> Danke!
>
>>> falls ihr OpenWrt forked am besten ne git quelle, ansonsten halt die quelle zu
>>> eurem Paket feed sowie standart-paketauswahl und was ich sonst noch wissen muss,
>>> damit alles wie erwartet da ist und das provisioning klappt.
>> Du willst das nicht. Du willst ein Vanilla-OpenWRT.
Ich habe etwas vergessen: die Regdb ist bei unseren Builds für 5 GHz 
meines Wissens eingeschränkt: all jene Frequenzen, die auch für 
Wetterradar in .at etc in Frage kommen, sind vorsichtshalber 
herausgenommen. Genau kann ich Dir das nicht sagen, ich habe mich damit 
nie befasst.
> Naja, will ich vielleicht schon. Aber wenn ich die Dinger hier so hinterlassen
> will, dass sie sich schoen in die lokale Umgebung einfuegen, ist es schon schoen
> zumindest das LuCI-theme zu uebernehmen.
Das Theme ist Nebensache. Die neuen Builds haben eh alle das Bootstrap 
drinnen.
Ein Logo macht das Kraut auch nicht fett.
> SSH public key setzen ist auch immer ne
> gute Idee, gerade wenn IPv6 an ist und SSH ueber die link-local addressen als
> OTA-rescue-methode relevant ist. Und das autoconfig skript im squashfs ist
> natuerlich auch schoen, weil dann restore-factory sinn machen kann und es somit
> weniger wahrscheinlich ist, dass die hardware irgendwann ungenutzt verstaubt.
Das Autoconfig funktioniert meines Wissens noch nicht zu 100% und das 
andere Skript überschrieb in der Vergangenheit (sehr zur Verwunderung 
einiger Nutzer) einfach Werte bei jedem Reboot. Du willst das nicht.
Einzig die zur Absicherung von ntpd und Dnsmasq notwendigen Kommandos 
brauchst Du, die passen aber auch ohne viel Aufwand in die /etc/rc.local 
eines Eigen-Builds.
>
>> Nein: v2 ist ein Vorschlag für neue Konzepte. Nimm OLSR so, wie es in OpenWRT ist.
>> Broadcast bitte auf 255.255.255.255 (wir haben mehere Ranges (193.238.156.0/22
>> und 78.41.112.0/21).
> Sowieso immer /32 netmask und 255.255.255.255 als broadcast auf dem OLSR
> interface, alles andere macht chaos...
In der Tat. Die neueren Konfigurationen haben zumindest auf dem 
Wireless-Interface /32 in der Schnittstellen-Konfig und den Broadcast 
255x4 lediglich in der OLSR-Konfiguration. Früher war das leider nicht 
der Fall und viele Knoten machen es noch anders.
>
>> config LoadPlugin
>> ...
> Super, dass sind brauchbare infos.
Bitte.
>
>
>> Und achte bitte darauf, dass der dnsmasq nicht auf dem Interface mit der
>> offiziellen IP, die Du hoffentlich morgen bekommt, nicht läuft.
> Werde ich zu verhindern wissen ;)
:) guter Mann!
>
>
>>>    Jeder bekommt ne public IPv4! Statisch? Denn
>> Jup!
> Was fuer ein Luxus :)
Ein Relikt aus der Anfangszeit, das einerseits ein Vorteil ist, 
andererseits Verwaltungsaufgaben nach sich zieht, wie eben "das Ritual" ;-).
>
>
>>> dann will mensch sich dann eigentlich gleich wieder nen relakks oder anderes vpn
>>> dazu holen bzw. socks server verwenden, bevor ich google nutze oder sowas, sonst
>>> privacy-maessig weniger ideal...
>> Wenn Du Privacy willst, solltest Du auch kein unverschlüsseltes Wlan-City-Netz
>> nützen.
> Janeinja bzw. laesst sich imho so pauschal nicht beantworten.
Ja, schon irgendwie. Heartbleed + offenes WLAN + Abhörvillen (urban 
myth) + ... lassen schon eine gewisse Paranoia aufkommen.
>   Eve and Mallory
> got many faces. Ich dachte aber auch eher an den Schutz naiiver Menschen (z.B.
> Gaeste hier) davor bei der Nutzung kommerzieller Diensten (webmail,
> schlimmstenfalls Received-by:.*via HTTP 1.2.3.4-header; social networks; ...)
> mehr von sich preiszugeben als das bei der Nutzung von dyanimischen IPs aus
> dial-in ranges kommerzieller ISPs der Fall ist.
Seit es Browser-Footprints gibt, sind die Naiven sowieso im Nachteil, sorry.
Außerdem sind bei Providern (3G zB) auch unterschiedliche NAT(Bündel) je 
nach Location vorhanden.
Das ist zwar gut für die Privacy, aber schlecht für die Netzneutralität.
Das Thema Netzneutralität können wir aufgreifen, aber bei der Privacy 
ist letztlich jeder selbst dafür verantwortlich, geeignete Maßnahmen zu 
ergreifen.
Und das mit den dynamischen IPs ist eben so eine Sache, wenn Tracking 
auch anders funktioniert.
>   Denn das meiste Data-mining
> findet afaik eher selten in der lokalen Umgebung statt. (noch?)
Bist Du sicher?
http://derstandard.at/1395364480308/Format-NSA-speichert-wahrscheinlich-saemtliche-Kommunikation-Oesterreichs
http://www.format.at/articles/1414/524/374054/nsa-oesterreich
> Selbst ausgegangen von lokalem mining wuerde WPA und dergleichen bestenfalls den
> IP-Layer obfuskieren (da nur die wenigstens Menschen ihre WiFi MAC Adresse
> verwuerfeln) waerend Identitaet, Ort und Verkehrsmenge/-last/ToS immer noch
> zugeordnet werden koennen.
Es spielt eben alles zusammen. Jeder Layer ist zumindest etwas 
Energieaufwand.
>
>
>> Im "gewöhnlichen" Mesh reicht entweder der Client oder Adhoc-Modus je nach
>> Betreiber.
> Ja prima, das geht ja dann mit barrier braker und ath9k.
Sicherlich. Vorsicht aber bitte: wir haben bei Versionen von vor etwa 
sechs-zwölf Monaten Probleme mit der Latency im 2.4-ISM-Band beobachtet, 
die möglicherweise mit der ANI zusammenhängen (abdrehen half teilweise). 
Ich vermute einmal, dass neuere Treiber damit besser umgehen können.
Bitte um einen Erfahrungsbericht.
>
>
>>>> ob du nochwas auf 2,4 (eher adhock) empfang hast bezweifle ich
>>> laut scan-result mit laptop-omni:
>>> BSS c4:27:95:ba:39:97 (funkfeuer)
>>> BSS 00:0f:b5:78:a1:c0 (matrix)
>>> beide auf Kanal 9
>> Ob das nicht bei Euch im Haus die verschollene Hardware am Dachboden ist?
> Ausschliessen wuerde ich das nicht, aber Zugang zum Dachboden ist nicht gegeben.
>
>
;-) Ihr werdet der Sache schon auf den Grund gehen.

LG
Erich




Mehr Informationen über die Mailingliste Wien