All of lore.kernel.org
 help / color / mirror / Atom feed
* [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

* [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

* 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

* 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

* 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

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.