I'll try to make a brief summary about we talked about, feel free to contribute

1-. Wifi configuration tweaking to improve mesh performance

1-. Use 802.11b instead of 802.11g. This comes as a reccomendation from athens wireless, people at guifi.net says it works better this way

Although we made no testing everybody seemed to agree that, also Paco, teleco professor in our university said that it make sense with theory so we assumed it was true if interference was "heavy" enough. Since I don't know what can be considered "heavy" I suppose that testing in each environtment would be a good idea
2-. Disable RTS/CTS, it seems than that part of wifi specificacitions is useless in outdoor

Axel marked that it was disabled in kamikaze openwrt and made a short explanation about why is like that (all nodes starts sending rts and waits for cts to start transmission, but since every node is attending nobody sends a cts packet). Since it's disabled we should use kamikaze

Now i'm thinking than in whiterussian (freifunk) is also disabled? I suppose it isn't and should be disabled
3-. Distance tweaking (in atheros athctrl -d), I'm not sure if it works in a mesh or even if it works in madwifi

Don't remember what we said about that
4-. Use a kind of metalic grid of an specific size in front the antenna to avoid noise from other sources. Idea given by local university telco professors, still untested

It was said that probably it won't work, although in theory this could lead to a sensibilty increase in the receiver. An idea for a telco student

After the meeting I remembered reading somewhere that also packet size can be tweaked to increase performance, anybody has an idea about that?

2-. Test another workarounds (if any) to solve the madwifi bug (rate calculation errors that ends hanging the harware) in openwrt + ad-hoc mode

We tried to explain this bug to Axel and Roger. Axel seemed to be familiar with that and suggested:

During the meeting we had discussed relieve from the madwifi stuck beacon
problem. Recently I recognized that the information I gave you was partly
outdated. To activate nosbeacon for ad-hoc mode in kamikaze you have set
wifi-iface option sw_merge 1 (see also appendix).
I would still be very interested to hear if this option helps you with your
node-outage problems.

This works with 2.4 and 5Ghz Turbo channels using module parameters
countrycode=724 outdoor=1
Using this config with Alix/kamikaze Roger, Sammy and Pere from SamSitPer, and
me set up a 34 km link achieving 1MByte/second with only 50mW TX power.

At the moment Xavier is testing it in his nanostation, meanwhile we still use xavier's script, this scripts counts errors in dmesg every 5 minutes and reboots the board in case the number of errors exceed a certain number

3-. Get rid of vpn tunnels in our configuration

4-. Any idea you have in what our network can be useful to you

Axel was very interested about the issues we have with OLSR, we can resume them in 3:

Gateway switching: if a node has two gateways with similar ETX goes switching beetwen them. We experimented this, to avoid it we are aware of several aproaches:

1-. Use a proxy

2-. Use LinkQualityMult in OLSR config (not tested) it's supposed this makes harder the gw switching (not tested)

3-. Axel suggests now (not tested)
For the olsr GW plugin (to avoid GW-flipping) you can use this packet:
http://firmware.leipzig.freifunk.net/ipkg/global/freifunk-gwtun_0.1.4_mipsel.ipk

False gateway: when a node announces internet but is not working, the nodes that have it as a internet gw ara not able to find another route. To avoid it:

1-. Dyn-gw plugin, the freifunk one doesn't work very well (traceroute to some ip's), kamikaze (ping only 1 IP) seems to work better

2-. Use a proxy again

Routing loops: I think I haven't understand when asked, I realized that loops appears, I think this happens when a node isn't reacheable anymore but the route is still alive, but this behaviour is limited in time. To avoid this:

1-. Increase refreshing time (more cpu load)

2-. Change routing algorythm

At the end of the meeting Axel suggested to use BMX on the whole network, in parallel with our actual configuration, he offered to prepare packages for it. We've still not talked about that but I think there will no problem

I think that's all, add your cents...