[Berlin-wireless] Best Practice on updating to ff_1.5.13

[Sven-Ola Tuecke]

Good morning,

well, to manage a couple of nodes via Web is time consuming. But you 
bring me to a nice idea. I will add a simple hook for a shell script in 
cron.minutely, say "/tmp/.autorun". Then you can create a small 
script and transfer it via scp. For example:

root at pcacer:/tmp# vi .autorun
  #!/bin/sh
  nvram set wl0_mrate=2000000 commit
  wifi
  rm $0
root at pcacer:/tmp# chmod +x .autorun
root at pcacer:/tmp# wine /opt/wine/drive_c/Programme/PuTTY/pscp.exe /tmp/.autorun root at 104.198.65.65:/tmp
root at 104.198.65.65's password:

The above example uses the "wifi" command to transfer the setting to the 
wifi card immediately. Also this does not work, because the PuTTY-scp 
running under Linux/Wine does not accept the Password for some reason
(a Wine bug I presume). One may use pubkeys or (under Linux) the 
standard command line scp. Another tip: google for "winscp3".

// Sven-Ola

Am Dienstag, 10. Juli 2007 03:30 schrieb Bluse:
> Hi Freifunker,
>
> I am be aware of using the testing version of the freifunk release. My post
> is just an impression about the last baby from the often and early release
> strategy ;)
> I did use the login in the way you both mentioned it... ssh to the node ...
> remap to a local host port unused like 8080 ... and put my browser to to
> localhost:8080 url ... sure ... but .. adjustng 42 nodes ... one tool
> (putty.exe) more in game ... so 42 times putty start & remap localhost to
> some port from 8080 up to 8122 ... thats in compartion to the update
> process over the last 2 years (only via web wlan ) to time expensive for my
> side...might be I?m the only one administrating a whole mesh. Is the NVRAM
> variant really an option ?
>
> Bye Bluse
>
> "Sven-Ola Tuecke" <sven-ola at gmx.de> schrieb im Newsbeitrag
> news:f6udo8$2v2$1 at quamquam.org...
>
> > Hello Bluse,
> >
> > nice to hear that. Of course you know, this is still a testing version,
> > do you? Obviously, others are stumbling about the "not being able to
> > administer via http" thingy too. While a full blown https server needs to
> > much space, I may add a screenshot for putty instead, like this one:
> >
> > http://www.damtp.cam.ac.uk/user/jp107/xp-remote/ssh-map/puttytun.png
> >
> > You need Source Port==80 and Destination==localhost:80 for example, then
> > browse to http://localhost:80/ after the ssh connection is establised.
> > Maybe it's wise to enable http-admin for a couple of minutes after
> > restarting the device...
> >
> > If you pre-set the "wl0_mrate" variable before updating a node (e.g
> > "nvram set wl0_mrate=0 commit") no default 6mbit setting will be applied.
> > My personal optionion about this is: we have too much bad nodes placed on
> > kitchen tables. Which simply not move or get a better antenna because it
> > works (to some extent) and degrades the performance for all others
> > because of the txpwr / worst-case-compat-settings. Maybe lowering the
> > mcast rate automatically if really no routes are found in a couple of
> > minutes will help...
> >
> > BTW. Did you know you can update a firmware very easy using the command
> > line? Something like these commands (do not try to install software
> > concurrently and do not use without further killalls on 8Mb-RAM-Nodes):
> >
> > cd /tmp
> > wget http://whereever/openwrt-whatever.trx
> > firmware-burn /tmp/openwrt-whatever.trx
> > [connection lost]
> >
> > For the mentioned 8-Mb-RAM-Nodes (e.g. WAP54G, WRT54Gv5/6 or SE505), you
> > need to stop some processes first. For me this works - but you need to
> > ensure with the "ps" command with a real over-the-air-update:
> >
> > killall httpd
> > killall crond
> > telnetd
> > [now connect via telnet]
> > killall dropbear
> > cd /tmp
> > wget ...
> > firmware-burn /tmp/...
> > [connection lost]
> >
> > // Sven-Ola
> >
> > Bluse schrieb:
> >> Hello Freinfunkers,
> >>
> >> Just today I updated our hole Mesh with 42 nodes from ff firmware
> >> release 1.5.11 to 1.5.13. In summary, with some changes, I would say..
> >> the fucking fastest mesh network we ever had since november 2006 ;o)
> >>
> >> Here are some experience and changes I made today.
> >>
> >> -because of the mrate threshold of 6MBit/sek, all nodes lost the links
> >> rechable below this rate. My recommendations to this are:
> >> -> increase the tx power of all nodes BEFOR UPDATING TO 1.5.13, even the
> >> good ones with many neigborh to be sure not loosing contact to some poor
> >> nodes!!!, I increased nodes from 5mW up to 20 mW and 20mW nodes up to
> >> 60mW. After updateing to 1.5.13 you can change the power back depending
> >> on the neighbors you see now with the mrate threshold.
> >>
> >>   -so we have one node with a bad connection everytime, because of its
> >> in room setup. After the update to 1.5.13, the node was lost and did not
> >> reconnect after a couple of minutes. In this case, ssh to the best
> >> neighbor of this unreachable node (you have to reminde its ip ;) and
> >> change its mrate to auto (# wl mrate auto) & try to ssh to the
> >> unreachable node ... on my side it took some minutes till i got the
> >> node. and than  change the nodes radio setup to a better one, new
> >> antenna.. other lacation ... or increase the txpower of this node as a
> >> quick´n dirty workaround.
> >>
> >> -there is a new recommendation in the "overview"-tab with say
> >> rts-threshold=2345 ... I gues this is an error, becaus you can use or
> >> not-use the rts/cts mechanism. To disable the rts/cts mechanism, the
> >> rts-threshold should be greater than the cts-threshold and to enable the
> >> rts/cts mechanism, rts<cts. To get the most performance I recommend
> >> using CTS=2346 & RTS=2347!
> >> And if you want to use RTS/CTS mechanism, the optimum RTS-threshold is
> >> 128 with CTS=2346 (not rts=2345)!!! My recommendation to you is
> >> disabling rts/cts, because the capacty increase from theorathical
> >> maximum of 13MBit/sek with rts/cts, up to 27MBit/sek without rts/stc.
> >> And the latency gets half, so your transmittiontime of a tcp ip paket
> >> with aknowledge speed up from 830microseks to 400microseks.
> >>
> >> -the new security featur of not been able to login to a nodes via wlan
> >> rigth after flashing is bad... bad for my side. because i´m in the
> >> position of centralized administration of all nodes. So changing all
> >> httpd.conf scripts of all nodes to get this admin over wlan feature ...
> >> I didnt recongized it is as such one ;) ...  is really hard work.
> >> to sven ola: I would prefer secure web login .. might be to big in flash
> >> I could guess with https deamin .. but how would be a new NVRAM variable
> >> to allow the owner of a node, to specify in web gui if and which network
> >> are allowed to configure via wlan using web gui ?????????
> >>
> >> That´s my impression of updating from today ... so I have still one
> >> thing to say, just see my next thread ;)) ..
> >>
> >>
> >> Bye Bluse