Sorry, diese Seite ist im Aufbau und vermittelt erstmal rudimentaere Informationen zum Freifunk (FF) in Magdeburg/Cracau.
Hier eine vorlaeufige Uebersichtskarte aus OpenStreetMap.

Uebersichtskarte cracau

Suche Freifunker in Sichtweite meines FF-Knotens:
10.16.4.16 Sicht West
Uebersicht Freifunknetz Magdeburg/Cracau:
 ESSID:      mdcracau.freifunk.net
 Kanal:      11 = 2.462 GHz (5MHz-Raster)
 IP-range:   10.16.0.0/19 = 10.16.0.1 - 10.16.31.254 (max. 8190 Knoten)
 Netzmaske:  255.255.224.0
 Domain:     mdcracau.freifunk.local
 
Liste Freifunk-Knoten:
 IP/Range      Geo-Koordinaten   Dienste       Bemerkungen SSH-FP? GW?
 10.16.0.0/12  N52.123  E11.659  olsr          (54Mbps, Holger, Nov2009, 'range' zu gross)
 10.16.4.16    N52.117  E11.660  olsr,http,ssh (WRT54GL, 2.462 GHz, 54Mbps, Stab+BQuad-Hori Richtung NNW, Joerg Nov09,Dez09)
 10.16.4.17    N52.117  E11.660  olsr,http,ssh (WRT54GL, 2.462 GHz, 54Mbps, 2*Stab          Richtung ENE, Joerg Dez09)
 10.16.4.18    N52.117  E11.660  olsr,http,ssh (233MHz-i586 192MB RAM + DWL-660,11Mb/s + QQuad-Vert, Provisorisch, z.Z. nur Richtung E, channel 10, 2.457GHz, Joerg, Nov2009)
 10.16.4.16/28 N52.117  E11.660  14 IPs reserviert fuer Experimente (joerg Nov09)
 10.16.4.28/30 N52.117  E11.660  2 IPs fuer Vergabe per OLSR-DHCP (test, Joerg Dez09)
 ...
 10.16.31.1/24 reserviert fuer kurzzeitige Experimente und Gaeste (?)


--------------------------------------------------------------------------
Moegliche (geplante?) Dienste + ToDo-List:
 - Mesh-Statistiken (IPs+Datenmenge,letzteSendezeit,Latenzen) + FF-MSG-board(gpg)
 - olsr(meshing/routing), dhcp+NAT(connect), http(web), https(secweb), jabber(chat), mumble(voice),
   tinc(vpn-gw), Gateway zu VPNs, imap(FF-email), ssh, dns-fw, ...
   via Avahi (Zeroconf/UPnP announciert?)
 - Einrichtung OLSR-Router fuer neue Mitglieder, Verkauf gegen Selbstkostenpreis?
 - Tunnel ins FF-Halle
 - IP-Range muss wegen IP-Konflikten geaendert werden?
   Warum: erleichtert Routing zwischen Freifunknetzen via Tunneling?
   Vorschlag: 10.116.0.0/18 fuer magdeburg.freifunk.net
   (parallel-Betrieb ueber multi-SSID oder eth0:1?)
 - eigene server/client-SSL-Zertifikatsverwaltung
 - Anschluss Radioaktivitaetsmessstation via FF (solarbetrieben) (2011)

----------------------------------------------------------------------------- 
FAQ:
 Q: Was ist Freifunk?
 A: WLAN im Ad-Hoc-Modus + Meshing-Software(olsr),
    gleicher Funkkanal, gleiche ESSID, gemeinsamer (privater) IP-Range,
    IP-Adressen werden per Hand vergeben
 
 Q: Wie funzt OLSR (Beispiel-IP+Routingtabellen, Varianten)?
 A: Olsrd sendet und empfaengt via IP-Port 698 UDP Pakete an Funknachbarn und veraendert Routing-Tabelle.
 route -n | grep wlan0 # Beispiel 7 Hosts, 2 direkte Links + 5 indirekte Links
  Destination   Gateway       Genmask         Flags Metric Ref Use Iface
  10.16.0.17    10.16.0.211   255.255.255.255 UGH   3      0     0 wlan0
  10.16.0.49    10.16.0.209   255.255.255.255 UGH   3      0     0 wlan0
  10.16.0.50    10.16.0.209   255.255.255.255 UGH   2      0     0 wlan0
  10.16.0.81    10.16.0.211   255.255.255.255 UGH   2      0     0 wlan0
  10.16.0.211   0.0.0.0       255.255.255.255 UH    1      0     0 wlan0
  10.16.0.177   10.16.0.209   255.255.255.255 UGH   3      0     0 wlan0
  10.16.0.209   0.0.0.0       255.255.255.255 UH    1      0     0 wlan0
  10.16.0.0     0.0.0.0       255.255.224.0   U     0      0     0 wlan0
  # Metric kann Hop-Anzahl sein, muss aber nicht (es gilt nur: kleiner ist besser)
  # Flags: Up, Gateway, Host; Metric und Ref wird von Linux nicht benutzt

  OLSR-Routing Beispiel
  # test: ping -R -c 1 -n 10.16.0.209
  ToDo: Vortrag? Video?

 Q: OLSR Debugging? 
 A:
  netstat -antup
   Proto Recv Send Local Address        Foreign Address         State       PID/Program name
   tcp6     0    0 :::80                :::*                    LISTEN      2713/thttpd
   tcp6     0    0 :::22                :::*                    LISTEN      2565/sshd
   tcp6     0    0 ::ffff:10.16.0.71:22 ::ffff:10.16.0.70:40830 ESTABLISHED 12625/0
   udp      0    0 0.0.0.0:698          0.0.0.0:*                           5261/olsrd
  tcpdump -ni wlan0 # UDP broadcast packets via port 698  
   21:50:02.790209 IP 10.16.0.71.698 > 10.16.31.255.698: OLSR, seq 0xb1e7, length 20
   21:50:08.321130 IP 10.16.0.71.698 > 10.16.31.255.698: OLSR, seq 0xb1e8, length 20
   21:50:14.497475 IP 10.16.0.71.698 > 10.16.31.255.698: OLSR, seq 0xb1e9, length 20
    
 Q: Umstieg von OLSR (Optimized Link State Routing) auf B.A.T.M.A.N. (Better Approach to mobile Ad-Hoc Networks)?
 A: ab bestimmter Netzgroesse? Interoperabel?
    Vorteil: sonst nicht im MESH sichtbare aber am Router haengende PCs koennen vom Router mit angemeldet werden
 
 Q: Geeignete preiswerte Hardware?
 A: Wichtig ist sparsamer Verbrauch und minimale Lautstaerke.
    - Alte Laptops + WLAN-Karte/USB-Stick (genug RAM, 8-20W) geeignet als Dienste-Server.
      Leider haben alte Laptops (486er) oft nur 1-2 16bit-PCMCIA Steckplaetze, kein Ethernet oder USB.
      Hier ist der Einsatz nur mit vorhandenen alten PCMCIA-16bit-WLAN/Ethernet sinnvoll.
      Mit USB-Ports insbesondere 2.0 ist man deutlich flexibler.
      Alte USB-faehige Notebooks bzw. 16bit-PCMCIA-Karten sammelt Joerg gern ein.
    - OpenWRT-faehige APs (RAM ist knapp, 1-10W) als reine OLSR, evl. Solarbetrieb
    ... optimal mit externer Antenne.
    Nov09: WRT54GL 40EUR bei Alternate (ct 23.11.2009), 50EUR bei Reichelt, Amazon
    
 Q: Alte nicht-OpenWRT-faehige APs als (Solar-) Freifunk-Repaeter?
 A: ... Ad-Hoc + Repeat-Mode?

 Q: Verbinden zweier Funk-Nodes node16 + node17 via Ethernet-Kabel?
 A:
    (wlan0=.16/12 node16 eth0=.21/30)----(eth0=.22/30 node17 wlan0=.17/12)
    
    Enge Netmasken (/30) werden gegenueber anderen (/12) priorisiert.
    ToDo: testen!
 
   SQ: ... via fester WLAN-Route als Kabelersatz? *smile*
      (wlan0=.16/12 node16 wlan0:1=.21/30)----(wlan0:1=.22/30 node17 wlan0=.17/12)
   A:
    node16: ifconfig wlan0:1 10.16.0.21 netmask 255.255.255.252 up
    node17: ifconfig wlan0:1 10.16.0.22 netmask 255.255.255.252 up
    # /30 ist das kleinst-moegliche Subnetz (Netzadr=0,Hosts=1-2,Broadcast=3)
    # /31 fuer Point-to-Point-Verbindungen zu Endpunkten (nicht nutzen!)
    node16: ip address show dev wlan0
      3: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc prio qlen 1000
          link/ether 00:23:4b:32:46:bd brd ff:ff:ff:ff:ff:ff
          inet 10.16.4.16/19 brd 10.16.31.255 scope global eth1
          inet 10.16.0.21/30 brd 10.255.255.255 scope global eth1:1
 
   SQ: via Switch vom DSL-Router?
   A: ...
   
   SQ: ssh zu $ip1 (mit 2 IPs) via $ip2?
   A: ssh -o HostKeyAlias=$ip1 -o VisualHostKey=yes $ip2

 Q: Verbinden zweier OLSR-Wolken via PtP oder WLAN-Bridge?
 A: ...
 
 Q: OLSR-Zuverlaessigkeit?
 A: Der OLSR-FF ist stark gefaehrdet durch DoS-Attacken. Verursacher
    koennen aber lokalisiert werden.
    Hijacking von HTTP-Verbindungen ist leicht (SSL/TLS oder VPN nutzen).
    Original RFC3626 (OLSR-0.4.7 aus 2004 und vorher) funktioniert schlecht
    oder garnicht (http://www.open-mesh.org/wiki/the-olsr-story,
    see routing-loop-problem).

 Q: Benchmarks?
 A: nc $ip 2048 + nc -l -p 2048
 
 Q: Paketverluste?
 A: ping -s 512 -c 400 -f -n $IP
     
 Q: Daten-Sicherheit?
 A: Fuer die Verschluesselung von sensiblen Daten muss selbst
    gesorgt werden (ssh, vpn, ssl/tls)!
    Korrekte Pruefung aller beteiligten Zertifikate ist dabei wichtig.
   
  SQ: ssh-vpn von node16 zum Netzwerk 10.0.0.x mit node18 (ssh-4.3++, dropbear=no)
  A: node16: sshd + root access, PermitRootLogin=yes PermitTunnel=yes
     node18: ssh access to node16 + root access, mit Internet-IP = VPN-GW
     node18: echo 1 > /proc/sys/net/ipv4/ip_forward
             ssh -NTCf -w 0:0 node16  # optional: -f = background, -NTC = ...
             # erzeugt (verbundene) tun0's auf beiden Nodes
             ifconfig tun0 10.0.0.200 pointopoint 10.0.0.100
     node16: ifconfig tun0 10.0.0.100 pointopoint 10.0.0.200
     node18: route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0
     node16: arp -sD 10.0.0.200 eth0 pub
     optional: default-route zum VPN-GW verschieben
   Bemerkung: nicht die beste VPN-Methode, benoetigt beidseitig Rootrechte
      mit iface automatisierbar

Sources:
  - Guide to IP Layer Network Administration with Linux, Version 0.4.5,
    2002-2007,  Author: Martin A. Brown,
    http://linux-ip.net/html/linux-ip.html