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
--
Wien mailing list
Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien
