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

[Sven-Ola Tuecke]

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 
> 
>