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

[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