Hi,

We playing around with B.A.T.M.A.N. 0.3-beta rv767 in our leipziger Freifunk-testing-Firmware (based on v1.6.10):

the Routing works fine (if i start "batmand eth1:bat vlan1:bat") - great work!

exciting to hear. Keep us informed about all the trouble you experience so that we can work on it.

but the gateway-function (option "-r 2") drives me mad:

• why the tunnel-interface (gateX) now have IP-Adresses!?

Simply said the "get virtual IP on demand" mode had some problems especially with the fact that the interface has no IP address when the first packets arrive. So we went through a whole process of fixing that following problems by setting the new address in these packets, then recalculating the checksums, implementing a lightweight NAT for returning packets. After all that there were still issues which could not be addressed easily. On the other hand we give away the chance to check whether the tunnel port is blocked or not until the user needs the connection. Now batman hands out IP addresses proactively. We are waiting for real world feedback to see if we run into new problems. So far it seems to work.

• what this log-message (on gateway) wants to tell me? (105.61.89.81 is

an Node who wants to build up an gateway-tunnel)

...

Nov 3 16:49:38 (none) kern.err batmand[1819]: Error - got packet

from

...

unknown client: 105.61.89.81 (virtual ip 104.61.13.37)

The batman gateway checks if the tunnelled packet has a known wifi IP address corresponding to a known virtual IP address. 104.61.13.37 is obviously a wrong IP address. I would guess that this is an OLSR address ? May be we have a problem with gatewaying alias interfaces ?

@Axel: Did you experience that kind of problem ? May be we have to set the source address explicitely. I look into that.

• I noticed, that LAN-clients (on batmannodes) sometimes get 169.x.y.z

Addresses per DHCP if i start batmand with "-r 2"-option?

If so that has nothing to do with batman. Even if batman has an internal mini "give IP" server it is an own lightweight protocol which is not compatible with the real DHCP. Actually this IP range is to be used if you can't connect to a DHCP server and have no fixed address set.

B.A.T.M.A.N. 0.2 worked fine, but we want/must use B.A.T.M.A.N. 0.3, because the available policy-routing cause no problems with parallel driven olsrd.

I understand.

Regards, Marek

Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail