Re: [B.A.T.M.A.N.] dublicate HNAs / certificates

Hi, On Dienstag 06 Januar 2009, Alexander Morlang wrote: > Axel Neumann schrieb: > > We wanted batmand (and especially its core routing algorithm) to be > > decentral and simple. So no central point of control/failure and > > therefore also no HNA server. Of course there are many potential attack

Re: [B.A.T.M.A.N.] dublicate HNAs / certificates

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Axel Neumann schrieb: > HI, > > I like brainstorming like this. > We wanted batmand (and especially its core routing algorithm) to be decentral > and simple. So no central point of control/failure and therefore also no HNA > server. Of course there

Re: [B.A.T.M.A.N.] dublicate HNAs / certificates

Hi again, is there a way to set a TTL value for each hna that is different from OGM TTL? If I assume that an HNA internet host is reachable via two nodes (e.g. running icvpn - bgp) batmand currently ignores one of this hna and also the node and its traffic (right?). What if we use the ttl valu

Re: [B.A.T.M.A.N.] dublicate HNAs / certificates

Hi, > I like brainstorming like this. me too. > We wanted batmand (and especially its core routing algorithm) to be decentral > and simple. So no central point of control/failure and therefore also no HNA > server. Perhaps there is a different solution. What if everybody may broadcast their HNA l

Re: [B.A.T.M.A.N.] dublicate HNAs / certificates

HI, I like brainstorming like this. We wanted batmand (and especially its core routing algorithm) to be decentral and simple. So no central point of control/failure and therefore also no HNA server. Of course there are many potential attack vectors in a community mesh and probably there will al

Re: [B.A.T.M.A.N.] dublicate HNAs / batmand / certificates

Hi Axel, > Theoretically, if the node can reestablish a new connection after its forced > disconnection within the dad timeout (100secs by default) then it should not > be kicked out. But, the preliminary for this is that: the node must re-appear > using the same primary IP for its primary interfa

Re: [B.A.T.M.A.N.] dublicate HNAs

Hi, On Samstag 13 Dezember 2008, Stephan Enderlein (Freifunk Dresden) wrote: > Hi, > > I'm not so deep involved in batman routing to find a solution. I hope > you can find a way. But for now it is not so important. > But if one node announces a HNA and a different node that just has fun to > "turn

Re: [B.A.T.M.A.N.] dublicate HNAs

Hi, I'm not so deep involved in batman routing to find a solution. I hope you can find a way. But for now it is not so important. But if one node announces a HNA and a different node that just has fun to "turn off" this node can simply send the same HNA. If you say the first HNA is the right one,

Re: [B.A.T.M.A.N.] dublicate HNAs

Hi, On Donnerstag 11 Dezember 2008, Freifunk wrote: > Hi Axel, > > thanks for your description. Would it be better to only ignore the HNA that > is already received from another node instead of ignoring the node > completely? Sounds reasonable. What were the consideratios from those days - there w

Re: [B.A.T.M.A.N.] dublicate HNAs

Hi Axel, thanks for your description. Would it be better to only ignore the HNA that is already received from another node instead of ignoring the node completely? I currently use one node that is connected to icvpn (inter-city vpn) that connects different freifunk cities together. The network ru

Re: [B.A.T.M.A.N.] dublicate HNAs

Hi, On Dienstag 09 Dezember 2008, Stephan Enderlein (Freifunk Dresden) wrote: > --- > Another question: in previous versions I have seen that if two batmand > announce the same HNA ip (-a) one of the batmand are ignored and complete > ignored any batmand traffic. As result the node was rem