according to the log file node2 behaves correct (despite the thing that node2 generates a route to node6 within the first two seconds). At some point in time node2 purges node6 from its routing table because it could never validate the link between interface 10.1.1.1 and 10.1.1.33 as a bidirectional link. Can you generate another set of log files at node2 and node6 simultaneously? So that we can identify whether node2 simply does not hear or node6 never re-broadcasts any originator messages (OGMs) send by node2.
They are in http://wifi.one-b.it/download/
Hmm... actually another thing but: I see that on node2 the netmask and broadcast addresses for the two interfaces used by batman are different. I've never tried nor considered it that way - might work - but it is (imho) not the intended setup. With batman you can/should use the same netmask (and broadcast addresses) for all interfaces participating in the batman mesh. Otherwise you can get topology fractionation with which the protocol can not deal with automatically. Perhaps you can try to give ALL interfaces a 255.255.255.0 netmask and a 10.255.255.255 broadcast address?
I have disabled eth0.0 (batman only on interface wl0) on node2 and same behavior: after a while route to node6 disappear.
I make another test with only 3 nodes: node2 with one interface (wl0), node6 and node3
node2 (10.1.1.1) ------ node6 (10.1.1.33) \ --- node3 (10.1.1.10)
After 2 minutes with "batmand -g 0 -r 2 -d 1 wl0" on all 3 nodes:
node2 10.1.1.10 10.1.1.10 ( 67): 10.1.1.10 ( 67) 10.1.1.33 10.1.1.33 ( 21): 10.1.1.33 ( 21)
node6 10.1.1.10 10.1.1.1 ( 66): 10.1.1.1 ( 66) 10.1.1.1 10.1.1.1 (120): 10.1.1.1 (120)
node3 10.1.1.33 10.1.1.1 ( 20): 10.1.1.1 ( 20) 10.1.1.1 10.1.1.1 (121): 10.1.1.1 (121)
I suspect that batman does not hear some packets, maybe for wireless problems?