search for: sssp_bfs

...on is : how to be sure that "n->nexthop->connection" will be a "trusted connection" ? (c->name in TrustedNode). One of our question is : if we cancel any ADD_* from untrusted node, can nexthop be a untrusted node ?... As far as we can see, nexthop is set in graph.c [sssp_bfs()]... but we are not very easy with this nice piece of code. :-) Thanks, -- Mat

...connection.o edge.o event.o graph.o logger.o meta.o net.o net_packet.o net_setup.o net_socket.o netutl.o node.o process.o protocol.o protocol_auth.o protocol_edge.o protocol_misc.o protocol_key.o protocol_subnet.o route.o subnet.o tincd.o ../lib/libvpn.a -lcrypto -lz -llzo graph.o: In function `sssp_bfs':/usr/src/tinc/src/graph.c:278: undefined reference to `device' ... tincd.o: In function `main':/usr/src/tinc/src/tincd.c:504: undefined reference to `dump_device_stats' collect2: ld returned 1 exit status make[2]: *** [tincd] Error 1 make[2]: Leaving directory `/usr/src/tinc/sr...

...nges, then the edge would be updated and a new ADD_EDGE message would be broadcast again, thereby dynamically *mutating* the edge as the situation changes. (as a matter of fact, it turns out tinc already supports updating edges in that way, though it currently prints a warning when that happens) - sssp_bfs() would take PMTU into account while traversing the graph, and update each node with the indirect MTU. Indirect MTU would be defined as the minimum of all PMTUs across the edges that form the path to that node. Interestingly, this proposal is not perfectly optimal, because of the following situati...

(Second try to send this. I wonder if the first one gotten eaten by a spam filter; I'll link to patches instead of attaching them.) Here are the tincctl patches I've been working on. They apply to http://www.tinc-vpn.org/svn/tinc/branches/1.1@1545. I intend to commit them once the crypto stuff's fixed. Since they're basically done, I'm emailing them now for review and in case