* [B.A.T.M.A.N.] Fwd: [Babel-users] Fwd: Why we switched to Babel [not found] ` <CAF0yFe4xwGomt=gud+7YZ4jfd_qSX9U=B7QYUhaBUjeJjh_D5Q@mail.gmail.com> @ 2015-08-08 21:51 ` Mitar 2015-08-09 10:06 ` Moritz Warning 2015-08-10 7:52 ` Marek Lindner [not found] ` <CAPmmg8swQNQQuEZw3Hhpvv2aj6nXdfhobnpyb8U9RnFR-ZX+Ag@mail.gmail.com> 1 sibling, 2 replies; 7+ messages in thread From: Mitar @ 2015-08-08 21:51 UTC (permalink / raw) To: b.a.t.m.a.n, Jernej Kos, Jenny Ryan, Marc Juul Hi! Comments? Mitar ---------- Forwarded message ---------- From: Jenny Ryan <tunabananas@gmail.com> Date: Fri, Aug 7, 2015 at 11:41 PM Subject: [Babel-users] Fwd: Why we switched to Babel To: babel-users@lists.alioth.debian.org ---------- Forwarded message ---------- From: "Marc Juul" <juul@labitat.dk> Date: Aug 6, 2015 9:58 AM Subject: Why we switched to Babel To: "Jenny Ryan" <tunabananas@gmail.com> Cc: When people share their internet we use a tunnel to hide their IP (and to connect them to the mesh through the Internet). This tunnel takes a few bytes of overhead. All physical connections, whether they're ethernet, wifi or even an abstraction like a tunnel, have an MTU (Maximum Transfer Unit) which is the size of the largest packet that can be sent over the connection. Normally the MTU is 1500 but since the tunnel needs a few bytes for overhead the MTU of the tunnel will be less than 1500. When people connect to the wifi network called peoplesopen.net they will connect with an MTU of 1500 since this is the default for wifi. We need a way to tell them that the MTU is actually less than 1500. In an IP network (which is at layer 3) there is a built-in system for dealing with this. If any router receives a packet larger than what it can pass on through the next connection (in this case through the tunnel) it can report back to the client using the ICMP protocol (a companion protocol to IP, and the protocol used for ping) that the packet was too big and the client can then adjust its MTU accordingly. For batman-adv, because it is a layer 2 protocol, we don't have this system available. We tried different tactics such as using DHCP to tell the clients the MTU they should use, but it turns out that many operating systems completely ignore this. We tried something called TCP MSS clamping, which is a bit of a dirty hack, but that only works for TCP, which is a problem since UDP is widely used for e.g. VOIP, video streaming, gaming, torrenting, etc. Even combining the different tricks we still had a problem where some operating systems would get in trouble if they tried to send large UDP packets. We had a moment where we realized that the only types of common communication that wouldn't work on this mesh would be torrenting and video streaming from windows computers, and joked about that being a feature instead of a bug :) but in the end we switched to Babel. There was another reason: In batman-adv the MAC address is the identifier used for each device. It is possible to configure many devices to randomize their MAC address but it needs the user to do something, so most people will never know to do it. Having the MAC address as the identifier makes it pretty easy for anyone to track anyone else as they move about the city, as long as they know the MAC address of e.g. their phone, which it is easy to discover if you are ever in the same room with them, just by listening to network traffic. We had some ideas for how this could be fixed, but the potential solutions we came up with were never satisfactory. For mesh, each time a user connects to a new node they get a new IP address. In the future we may implement roaming support which will let people keep their IP as they move around the city, but it will still switch after e.g. 10 minutes, so tracking people becomes much harder. That's a lot of text, but eh it's a complicated issue. It sounds like you're having many late night conversations. Hope it is enjoyable! -- marc/juul _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [B.A.T.M.A.N.] Fwd: [Babel-users] Fwd: Why we switched to Babel 2015-08-08 21:51 ` [B.A.T.M.A.N.] Fwd: [Babel-users] Fwd: Why we switched to Babel Mitar @ 2015-08-09 10:06 ` Moritz Warning 2015-08-10 7:52 ` Marek Lindner 1 sibling, 0 replies; 7+ messages in thread From: Moritz Warning @ 2015-08-09 10:06 UTC (permalink / raw) To: b.a.t.m.a.n [-- Attachment #1: Type: text/plain, Size: 4055 bytes --] regarding MACs, would it be possible for batman-adv to use hashed MACs? On 08/08/2015 11:51 PM, Mitar wrote: > Hi! > > Comments? > > > Mitar > > ---------- Forwarded message ---------- > From: Jenny Ryan <tunabananas@gmail.com> > Date: Fri, Aug 7, 2015 at 11:41 PM > Subject: [Babel-users] Fwd: Why we switched to Babel > To: babel-users@lists.alioth.debian.org > > > ---------- Forwarded message ---------- > From: "Marc Juul" <juul@labitat.dk> > Date: Aug 6, 2015 9:58 AM > Subject: Why we switched to Babel > To: "Jenny Ryan" <tunabananas@gmail.com> > Cc: > > When people share their internet we use a tunnel to hide their IP (and > to connect them to the mesh through the Internet). This tunnel takes a > few bytes of overhead. All physical connections, whether they're > ethernet, wifi or even an abstraction like a tunnel, have an MTU > (Maximum Transfer Unit) which is the size of the largest packet that > can be sent over the connection. Normally the MTU is 1500 but since > the tunnel needs a few bytes for overhead the MTU of the tunnel will > be less than 1500. > > When people connect to the wifi network called peoplesopen.net they > will connect with an MTU of 1500 since this is the default for wifi. > We need a way to tell them that the MTU is actually less than 1500. In > an IP network (which is at layer 3) there is a built-in system for > dealing with this. If any router receives a packet larger than what it > can pass on through the next connection (in this case through the > tunnel) it can report back to the client using the ICMP protocol (a > companion protocol to IP, and the protocol used for ping) that the > packet was too big and the client can then adjust its MTU accordingly. > > For batman-adv, because it is a layer 2 protocol, we don't have this > system available. We tried different tactics such as using DHCP to > tell the clients the MTU they should use, but it turns out that many > operating systems completely ignore this. We tried something called > TCP MSS clamping, which is a bit of a dirty hack, but that only works > for TCP, which is a problem since UDP is widely used for e.g. VOIP, > video streaming, gaming, torrenting, etc. > > Even combining the different tricks we still had a problem where some > operating systems would get in trouble if they tried to send large UDP > packets. We had a moment where we realized that the only types of > common communication that wouldn't work on this mesh would be > torrenting and video streaming from windows computers, and joked about > that being a feature instead of a bug :) but in the end we switched to > Babel. > > There was another reason: In batman-adv the MAC address is the > identifier used for each device. It is possible to configure many > devices to randomize their MAC address but it needs the user to do > something, so most people will never know to do it. Having the MAC > address as the identifier makes it pretty easy for anyone to track > anyone else as they move about the city, as long as they know the MAC > address of e.g. their phone, which it is easy to discover if you are > ever in the same room with them, just by listening to network traffic. > We had some ideas for how this could be fixed, but the potential > solutions we came up with were never satisfactory. > > For mesh, each time a user connects to a new node they get a new IP > address. In the future we may implement roaming support which will let > people keep their IP as they move around the city, but it will still > switch after e.g. 10 minutes, so tracking people becomes much harder. > > That's a lot of text, but eh it's a complicated issue. It sounds like > you're having many late night conversations. Hope it is enjoyable! > > -- > marc/juul > > > > > _______________________________________________ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users > > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [B.A.T.M.A.N.] Fwd: [Babel-users] Fwd: Why we switched to Babel 2015-08-08 21:51 ` [B.A.T.M.A.N.] Fwd: [Babel-users] Fwd: Why we switched to Babel Mitar 2015-08-09 10:06 ` Moritz Warning @ 2015-08-10 7:52 ` Marek Lindner [not found] ` <CAL4ejvTuHjffOhmeSyNJJ0FQHv7nD0_a9NG5LjCnbjOy+qmOcw@mail.gmail.com> 1 sibling, 1 reply; 7+ messages in thread From: Marek Lindner @ 2015-08-10 7:52 UTC (permalink / raw) To: b.a.t.m.a.n; +Cc: Jernej Kos, Jenny Ryan, Marc Juul [-- Attachment #1: Type: text/plain, Size: 702 bytes --] On Saturday, August 08, 2015 23:51:42 Mitar wrote: > For batman-adv, because it is a layer 2 protocol, we don't have this > system available. We tried different tactics such as using DHCP to > tell the clients the MTU they should use, but it turns out that many > operating systems completely ignore this. We tried something called > TCP MSS clamping, which is a bit of a dirty hack, but that only works > for TCP, which is a problem since UDP is widely used for e.g. VOIP, > video streaming, gaming, torrenting, etc. What spoke against using the batman-adv layer2 fragmentation: http://www.open-mesh.org/projects/open-mesh/wiki/2012-09-24-GSoC-2012-Martin-Hundebolls-Final-Report ? Cheers, Marek [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAL4ejvTuHjffOhmeSyNJJ0FQHv7nD0_a9NG5LjCnbjOy+qmOcw@mail.gmail.com>]
* Re: [B.A.T.M.A.N.] Why we switched to Babel [not found] ` <CAL4ejvTuHjffOhmeSyNJJ0FQHv7nD0_a9NG5LjCnbjOy+qmOcw@mail.gmail.com> @ 2015-08-15 12:40 ` Marek Lindner [not found] ` <CAL4ejvQDGtSx_NH3SmvmFAOwFvfWbP0ArQ-+b74PCm4dNwimFA@mail.gmail.com> 0 siblings, 1 reply; 7+ messages in thread From: Marek Lindner @ 2015-08-15 12:40 UTC (permalink / raw) To: Marc Juul; +Cc: Jernej Kos, b.a.t.m.a.n, Jenny Ryan [-- Attachment #1: Type: text/plain, Size: 3047 bytes --] On Saturday, August 15, 2015 04:21:27 Marc Juul wrote: > > What spoke against using the batman-adv layer2 fragmentation: > > > > http://www.open-mesh.org/projects/open-mesh/wiki/2012-09-24-GSoC-2012-Mart > > in-Hundebolls-Final-Report ? > > This was a while back now but if I remember correctly we were getting > terrible performance when using fragmentation. We were at the time using > the old Picostation 2 HP routers, which we only later learned perform > terribly even when they're just acting as dumb bridges, so that could > definitely have been a significant factor. None of our team were super > experienced with wifi/mesh when we started out and we are much wiser now > than we were a year ago when we made this switch, so it's possible that we > could go back and use fragmentation and have batman-adv work for us now. I'd expect some impact on performance but nothing as dramatic as what you are describing. Would be interesting to get actual numbers. > However, the privacy issue with a city-wide network using the client MAC > address for identification still stands as something we do not know how to > fix for batman-adv. To make matters worse we've had some people > misinterpret what we're doing and then go out and tell others that we're > making some privacy-focused network with anti-NSA-surveillance measures, > which made it even worse to have to explain that anyone who knows your MAC > can track you as you move about the city. Though I recognize and share the desire for privacy batman-adv is first and foremost a mesh protocol. Not an anonymizer or NSA-defender. That being said, I am not adverse to somebody working on this subject and making batman-adv a better place. I do like to point that even by not using batman-adv one can easily be tracked via the MAC address on a national or global scale. Search online for the magic words 'presence analytics' and you'll get an impressive list of companies (most of them based in the Bay area) offering products & tools able to track you all around the country or even internationally (depends on the size of your business). I myself have been contacted by quite a number of companies asking me to help them to develop such systems. You don't even need to connect to these hotspots to be tracked. Passing by is enough. I am afraid by telling your mesh users that you switched to an IP based mesh protocol you lure them into a false sense of 'non-traceability'. It kind of feels like a debate we had almost a decade ago when WiFi came to the masses. People had the feeling to use WiFi they had to learn what this cumbersome SSL thing is. Because WiFi is insecure as the waves leave your home and the neighbors can eavesdrop on you .. Countless hours had to be invested into educating our mesh users that SSL always is a good thing. Personally, I rotate my MAC address on a daily basis. That works not only with batman-adv but everywhere. Obviously, that won't help you against the countless ad networks, Google, Facebook, etc, etc Cheers, Marek [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAL4ejvQDGtSx_NH3SmvmFAOwFvfWbP0ArQ-+b74PCm4dNwimFA@mail.gmail.com>]
* Re: [B.A.T.M.A.N.] Why we switched to Babel [not found] ` <CAL4ejvQDGtSx_NH3SmvmFAOwFvfWbP0ArQ-+b74PCm4dNwimFA@mail.gmail.com> @ 2015-08-17 8:57 ` Marek Lindner 2015-08-19 1:54 ` Mitar 0 siblings, 1 reply; 7+ messages in thread From: Marek Lindner @ 2015-08-17 8:57 UTC (permalink / raw) To: Marc Juul; +Cc: Jernej Kos, b.a.t.m.a.n, Jenny Ryan [-- Attachment #1: Type: text/plain, Size: 2478 bytes --] On Saturday, August 15, 2015 07:05:17 Marc Juul wrote: > > I am afraid by telling your mesh users that you switched to an IP based > > mesh protocol you lure them into a false sense of 'non-traceability'. It > > kind of feels like a debate we had almost a decade ago when WiFi came to > > the masses. People had the feeling to use WiFi they had to learn what this > > cumbersome SSL thing is. Because WiFi is insecure as the waves leave your > > home and the neighbors can eavesdrop on you .. Countless hours had to be > > invested into educating our mesh users that SSL always is a good thing. > > > > Personally, I rotate my MAC address on a daily basis. That works not only > > with > > batman-adv but everywhere. Obviously, that won't help you against the > > countless ad networks, Google, Facebook, etc, etc > > I hear you. > > The biggest danger I feel is that associating to one of our access points > once with your phone would then allow anyone, even a technically > semi-literate stalker, to track you and find out where you live and work > using something we built. My fear would be that someone could use this data > to put up a public web app where any idiot can put in a MAC address and > instantly get a nice map of movement activity. I think we are at a point in our discussion where we just repeat what was already said. batman-adv certainly can be improved to provide better anonymity by default. Even with such a mechanism in place people can be tracked in your network (with IP mesh routing or without). Tracking without connecting to your network is even easier than that. Therefore, I favor education over a technology arms race. The latter you won't be able to win as you eventually will have to battle people's desire for the 'least effort route'. > Hopefully these tracking services you mention are not quite so easy to > access and use for something like this by an unlicensed individual (but > maybe they are?) though even if others are making these types of services > available, I'd rather not make it easy for them to use our network for their > nefarious purposes. These systems are built for absolutely non-technical users. For those who prefer videos over boring texts: https://www.youtube.com/watch?v=hCGiGaRp7-U I recommend to pay close attention to the section they call 'loyal customers' (around 1:30min into the video). Note that this was just the first search result that came up. There are many more. Cheers, Marek [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [B.A.T.M.A.N.] Why we switched to Babel 2015-08-17 8:57 ` Marek Lindner @ 2015-08-19 1:54 ` Mitar 0 siblings, 0 replies; 7+ messages in thread From: Mitar @ 2015-08-19 1:54 UTC (permalink / raw) To: Marek Lindner Cc: Marc Juul, The list for a Better Approach To Mobile Ad-hoc Networking, Jenny Ryan, Jernej Kos Hi! Wouldn't the MAC issue be addressed if the mesh network would be a mix of L2/L3 network? L2 to cover community spaces and allow roaming in there, but then across such segments, there would be a L3 routing? So one would for example be able to follow you inside Omni, but not across the whole network. Mitar On Mon, Aug 17, 2015 at 1:57 AM, Marek Lindner <mareklindner@neomailbox.ch> wrote: > On Saturday, August 15, 2015 07:05:17 Marc Juul wrote: >> > I am afraid by telling your mesh users that you switched to an IP based >> > mesh protocol you lure them into a false sense of 'non-traceability'. It >> > kind of feels like a debate we had almost a decade ago when WiFi came to >> > the masses. People had the feeling to use WiFi they had to learn what this >> > cumbersome SSL thing is. Because WiFi is insecure as the waves leave your >> > home and the neighbors can eavesdrop on you .. Countless hours had to be >> > invested into educating our mesh users that SSL always is a good thing. >> > >> > Personally, I rotate my MAC address on a daily basis. That works not only >> > with >> > batman-adv but everywhere. Obviously, that won't help you against the >> > countless ad networks, Google, Facebook, etc, etc >> >> I hear you. >> >> The biggest danger I feel is that associating to one of our access points >> once with your phone would then allow anyone, even a technically >> semi-literate stalker, to track you and find out where you live and work >> using something we built. My fear would be that someone could use this data >> to put up a public web app where any idiot can put in a MAC address and >> instantly get a nice map of movement activity. > > I think we are at a point in our discussion where we just repeat what was > already said. batman-adv certainly can be improved to provide better anonymity > by default. Even with such a mechanism in place people can be tracked in your > network (with IP mesh routing or without). Tracking without connecting to your > network is even easier than that. > > Therefore, I favor education over a technology arms race. The latter you won't > be able to win as you eventually will have to battle people's desire for the > 'least effort route'. > > >> Hopefully these tracking services you mention are not quite so easy to >> access and use for something like this by an unlicensed individual (but >> maybe they are?) though even if others are making these types of services >> available, I'd rather not make it easy for them to use our network for their >> nefarious purposes. > > These systems are built for absolutely non-technical users. For those who > prefer videos over boring texts: > https://www.youtube.com/watch?v=hCGiGaRp7-U > > I recommend to pay close attention to the section they call 'loyal customers' > (around 1:30min into the video). Note that this was just the first search > result that came up. There are many more. > > Cheers, > Marek -- http://mitar.tnode.com/ https://twitter.com/mitar_m ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAPmmg8swQNQQuEZw3Hhpvv2aj6nXdfhobnpyb8U9RnFR-ZX+Ag@mail.gmail.com>]
[parent not found: <87zj229nfa.wl-jch@pps.univ-paris-diderot.fr>]
[parent not found: <CAKLmikN6hrDwyC6u4Za94x0FRiyYuqKakO8-Q7zsFc6Gq=zOMw@mail.gmail.com>]
[parent not found: <87fv3twccq.wl-jch@pps.univ-paris-diderot.fr>]
[parent not found: <CABj6hTG8JDRFZxM77B_9mLsK-YOvYkJyFpXQzEt7q65LUVYq3A@mail.gmail.com>]
* [B.A.T.M.A.N.] Fwd: [Babel-users] Fwd: Why we switched to Babel [not found] ` <CABj6hTG8JDRFZxM77B_9mLsK-YOvYkJyFpXQzEt7q65LUVYq3A@mail.gmail.com> @ 2015-08-10 6:39 ` Mitar 0 siblings, 0 replies; 7+ messages in thread From: Mitar @ 2015-08-10 6:39 UTC (permalink / raw) To: The list for a Better Approach To Mobile Ad-hoc Networking Hi! One more precise explanation of issues. Is this really a limitation of Batman? Mitar ---------- Forwarded message ---------- From: max b <maxb.personal@gmail.com> Date: Mon, Aug 10, 2015 at 5:01 AM Subject: Re: [Babel-users] Fwd: Why we switched to Babel Marc will probably chime in here as we had plenty of sit downs trying to figure out how to incorporate BATMAN into our topology, but I (hope) I can help articulate the issue: Our topology was the following (very simplified). It mirrored (and was inspired by) the wlan slovenijia project. Cloud (or colocation) hosted exit server running batman l2tp interface | V l2tp interface OpenWRT wifi router running batman open0 interface | V heterogenous set of hosts connected wirelessly over an open network. The routers create l2tp tunnels to the exit server when they have an direct internet connection (ie. someone is sharing their bandwidth). The open0 and l2tp interfaces were added to batman, along with an adhoc interface which would connect to other routers over wifi. The l2tp interfaces had to have a non-standard MTU, they were an l2tp interface carrying batman-adv "frames". The problem is that the hosts connecting to the open network would generally not respect dhcp options setting an MTU. A significant number of hosts - including I believe all windows machines and at least IOS devices - would just set the MTU of their wireless interface to 1500. Under normal circumstances, this wouldn't be an issue because "When a packet arrives at a node from a client with too large an mtu, what SHOULD happen in a normal forwarding situation (per RFC 1191) is that the node issue a ICMP 'Destination Unreachable' packet with a "Fragmentation required" code. The client then uses this information to reset its mtu." (I'm quoting an email exchange from our mailing list: https://sudoroom.org/pipermail/mesh-dev/2014-October/000019.html) However, in our situation, we were essentially stuck bridging two interfaces that had different MTUs because they were both added to this batman-adv layer 2 forwarding daemon. Because there was no layer 3 routing going on, the ICMP message would never be sent. We were just seeing dropped frames in wireshark analyses - client devices wouldn't adjust their mtu and they wouldn't fragment because they wouldn't know to. We tried a couple workarounds, including an iptables MSS clamping rule, but that only works for TCP traffic. We were eventually stuck with what we came to realize was an unworkable stack+topology. The email exchange https://sudoroom.org/pipermail/mesh-dev/2014-October/000019.html could help out with any additional confusion. I still think that a heterogenous mesh with babel on top of batman-adv could be an excellent combination of dynamic routing with layer 2 mesh roaming, something like this diagram: https://libre-mesh.org/projects/libre-mesh/wiki/Network_Architecture?version=13 The libre-mesh folks mentioned that they've been experimenting with that sort of architecture, but I don't think we're really going to need it any time soon (and we weren't exactly in love with bmx6, but that's probably outside of the scope here). Hope that was reasonably helpful. Max -- http://mitar.tnode.com/ https://twitter.com/mitar_m ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-08-19 1:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAL4ejvQpfAQUUupvDpAx3xek3QggQc_Gi81ucm=EERo+aBwFdQ@mail.gmail.com>
[not found] ` <CAF0yFe4xwGomt=gud+7YZ4jfd_qSX9U=B7QYUhaBUjeJjh_D5Q@mail.gmail.com>
2015-08-08 21:51 ` [B.A.T.M.A.N.] Fwd: [Babel-users] Fwd: Why we switched to Babel Mitar
2015-08-09 10:06 ` Moritz Warning
2015-08-10 7:52 ` Marek Lindner
[not found] ` <CAL4ejvTuHjffOhmeSyNJJ0FQHv7nD0_a9NG5LjCnbjOy+qmOcw@mail.gmail.com>
2015-08-15 12:40 ` [B.A.T.M.A.N.] " Marek Lindner
[not found] ` <CAL4ejvQDGtSx_NH3SmvmFAOwFvfWbP0ArQ-+b74PCm4dNwimFA@mail.gmail.com>
2015-08-17 8:57 ` Marek Lindner
2015-08-19 1:54 ` Mitar
[not found] ` <CAPmmg8swQNQQuEZw3Hhpvv2aj6nXdfhobnpyb8U9RnFR-ZX+Ag@mail.gmail.com>
[not found] ` <87zj229nfa.wl-jch@pps.univ-paris-diderot.fr>
[not found] ` <CAKLmikN6hrDwyC6u4Za94x0FRiyYuqKakO8-Q7zsFc6Gq=zOMw@mail.gmail.com>
[not found] ` <87fv3twccq.wl-jch@pps.univ-paris-diderot.fr>
[not found] ` <CABj6hTG8JDRFZxM77B_9mLsK-YOvYkJyFpXQzEt7q65LUVYq3A@mail.gmail.com>
2015-08-10 6:39 ` [B.A.T.M.A.N.] Fwd: [Babel-users] Fwd: " Mitar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox