b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed
* [B.A.T.M.A.N.] batman-adv 2014.0.0 released
@ 2014-01-07 12:53 Marek Lindner
  2014-01-14 22:04 ` cmsv
  2014-02-10 19:45 ` cmsv
  0 siblings, 2 replies; 17+ messages in thread
From: Marek Lindner @ 2014-01-07 12:53 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

[-- Attachment #1: Type: text/plain, Size: 6916 bytes --]


The B.A.T.M.A.N. team is pleased to announce the immediate availability of 
batman-adv 2014.0.0 - a release coming with a rewritten packet handling engine 
and many new features almost uniquely tailored to preserve backward 
compatibility in the future. As the kernel module always depends on the Linux 
kernel it was compiled against, it does not make sense to provide binaries on 
our website. As usual, you will find the signed tarballs in our download 
section:

http://downloads.open-mesh.org/batman/releases/batman-adv-2014.0.0/

as well as prepackaged binaries in your distribution.


Important changes
-----------------

*Compatibility break*: In 2011, batman-adv broke backward compatibility with 
the introduction of the translation table mechanism. Since then, interests 
have been divided between those who wish a stable network with as little 
changes as possible and those who wish to experiment with new features to 
bring meshing to the next level. To accommodate both groups the batman-adv 
developers dedicated a lot of effort on building code infrastructure allowing 
to mix stable nodes with new features without breaking compatibility. This new 
system is incompatible to the pre-2014.0.0 versions, but it has been designed 
to stay compatible with future versions for the next decade or so.

At the same time, the legacy visualization support was removed from the kernel 
module. The alfred user space module provides an adequate replacement.


Thanks
------

Thanks to all people sending in patches:

 * Antonio Quartulli <antonio@meshcoding.com>
 * Joe Perches <joe@perches.com>
 * Linus Lüssing <linus.luessing@web.de>
 * Marco Dalla Torre <marco.dallato@gmail.com>
 * Marek Lindner <mareklindner@neomailbox.ch>
 * Martin Hundebøll <martin@hundeboll.net>
 * Simon Wunderlich <sw@simonwunderlich.de>
 * Spyros Gasteratos <morfeas3000@gmail.com>
 * Sven Eckelmann <sven@narfation.org>
 * Tan Xiaojun <tanxiaojun@huawei.com>


batman-adv
----------

Transforming a rather static design to a module architecture in the interest 
of preserving backward compatibility requires modifications on a multitude of 
levels. The principal idea behind the TVLV (type-version-length-value) 
infrastructure is to break up mesh management data into logic chunks 
(containers) which can be extended in the future while preserving backward 
compatibility. If a mesh participant receives an unknown TVLV type or version 
of a certain container it can simply skip the current container and proceed 
with the next. Therefore, all non-routing data sent with OGMs (e.g. gateway 
advertisement, translation table data, etc) were transformed to TVLV 
containers that are still attached to OGMs. In addition, translation table 
request & response packets as well as roaming advertisement packets were 
transformed to TVLV containers too.
While designing the containers a couple of feature requests were also 
addressed: The compressed download & upload gateway bandwidth (known as 
'gateway class') was replaced by uncompressed bandwidth information permitting 
granular gateway bandwidth announcement. DAT and network coding feature 
support is communicated into the mesh through TVLV containers as both 
subsystems optimize their performance based on the knowledge which mesh 
participant has the feature enabled.
In the interest of backward compatibility on the packet forwarding level 
batman-adv received a general unicast packet forwarding mechanism. This 
mechanism forwards or drops unknown packet types based on the packet type 
numbering.

The batman-adv built-in packet fragmentation has been redesigned and rewritten 
as part of the 'fragmentation 2' Google Summer of Code project. Major design 
goals include: Variable number of fragments (up to 16), generic fragmentation 
framework capable of handling all types of traffic (the 'old' fragmentation code 
was limited to payload unicast packets) and 'upper layer' transparency through 
early re-assembly. The maximum of local clients the translation table is able 
to handle went up by a factor of 16 (the maximum number of fragmented packets) 
as full translation table exchanges are able to take advantage of the newly 
introduced generic fragmentation. If the fragmentation is disabled or the MTU 
altered the local translation table is automatically reduced to fit the new 
maximum translation table size. Part of the increased maximum table size is 
the transition from CRC16 consistency checksumming to CRC32 to reduce 
collision probability and take advantage of hardware acceleration support. The 
translation table also gained full VLAN awareness making it the final component 
receiving full VLAN support. Non-mesh clients are now entirely separated on a 
per-VLAN basis. As a consequence, the bridge loop avoidance is capable of 
resolving bridge loops more elegantly (one VLAN might be bridged into the LAN 
while another one is not), the Distributed ARP Table (DAT) builds its 
distributed IP-MAC address hash on a per-VLAN basis and the AP isolation 
allows fine-grained control over which VLAN should be isolated and which should 
not.

The kernel module sets a dummy rx mode handler on batman-adv' virtual 
interface creation to be able to accepts static multicast listener 
configurations on top of the batX interface. In order to help wireless drivers 
to select the suitable traffic queue (e.g. WMM queues), batman-adv peeks into 
the encapsulated payload IP or VLAN header and sets the skb priority field 
accordingly. This priority field is used whenever the lower layer drivers (like 
wireless or ethernet drivers) are unable to retrieve the prioritization 
themselves due to the batman-adv traffic encapsulation.


batctl
------

As part of our ongoing effort for better IPv6 support quite a few missing 
pieces have been tackled: The IP-address-to-MAC-address resolver was extended 
to also support IPv6 addresses. This was achieved by porting the internal 
resolver from the '/proc/net/arp' based approach to the RTNL API. As a result 
the translate, ping and traceroute commands accept IPv6 addresses as 
destination argument which batctl tries to convert back to MAC addresses in 
similar to the IPv4 conversion. Furthermore, the tcpdump component was 
enriched with an IPv6 parser being able to decapsulate TCP, UDP and common 
ICMPv6 packet types.
The vis export feature has been removed as the kernel module no longer 
supports the visualization protocol. A number of cleanups and smaller fixes 
such as marking local functions as static, adding header include guards and 
more found their way into this release as well.


alfred
------

The missing libmath linker flag of the alfred-gpsd component was fixed and its 
manpage installation arranged.



Happy routing,
The B.A.T.M.A.N. team

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-07 12:53 [B.A.T.M.A.N.] batman-adv 2014.0.0 released Marek Lindner
@ 2014-01-14 22:04 ` cmsv
  2014-01-15  7:00   ` Martin Hundebøll
  2014-02-10 19:45 ` cmsv
  1 sibling, 1 reply; 17+ messages in thread
From: cmsv @ 2014-01-14 22:04 UTC (permalink / raw)
  To: b.a.t.m.a.n

[-- Attachment #1: Type: text/plain, Size: 8167 bytes --]

Hello

Withing the next month or 2 i will be deploying new firmware in my mesh
overseas. I am now testing 2014 and if everything seems ok; the new
builds will have and i can report results. (my current build that was to
be deployed has 2013.4.0-1 v14.

Has anyone started any tests ? If so any results or conclusions in
comparison to previous versions ?


Regarding the docs @
http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config
are they to be updated or to stay as they are ?

The reason i ask is because there seems to be necessary changes such as:

batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to
handle the transport of batman-adv packets. Packets going over this
interface will be fragmented on layer2 which could impact the
performance. Setting the MTU to 1546 would solve the problem.

Are there any other changes  hat may need to be done for 2014 ?

On 01/07/2014 07:53 AM, Marek Lindner wrote:
> 
> The B.A.T.M.A.N. team is pleased to announce the immediate availability of 
> batman-adv 2014.0.0 - a release coming with a rewritten packet handling engine 
> and many new features almost uniquely tailored to preserve backward 
> compatibility in the future. As the kernel module always depends on the Linux 
> kernel it was compiled against, it does not make sense to provide binaries on 
> our website. As usual, you will find the signed tarballs in our download 
> section:
> 
> http://downloads.open-mesh.org/batman/releases/batman-adv-2014.0.0/
> 
> as well as prepackaged binaries in your distribution.
> 
> 
> Important changes
> -----------------
> 
> *Compatibility break*: In 2011, batman-adv broke backward compatibility with 
> the introduction of the translation table mechanism. Since then, interests 
> have been divided between those who wish a stable network with as little 
> changes as possible and those who wish to experiment with new features to 
> bring meshing to the next level. To accommodate both groups the batman-adv 
> developers dedicated a lot of effort on building code infrastructure allowing 
> to mix stable nodes with new features without breaking compatibility. This new 
> system is incompatible to the pre-2014.0.0 versions, but it has been designed 
> to stay compatible with future versions for the next decade or so.
> 
> At the same time, the legacy visualization support was removed from the kernel 
> module. The alfred user space module provides an adequate replacement.
> 
> 
> Thanks
> ------
> 
> Thanks to all people sending in patches:
> 
>  * Antonio Quartulli <antonio@meshcoding.com>
>  * Joe Perches <joe@perches.com>
>  * Linus Lüssing <linus.luessing@web.de>
>  * Marco Dalla Torre <marco.dallato@gmail.com>
>  * Marek Lindner <mareklindner@neomailbox.ch>
>  * Martin Hundebøll <martin@hundeboll.net>
>  * Simon Wunderlich <sw@simonwunderlich.de>
>  * Spyros Gasteratos <morfeas3000@gmail.com>
>  * Sven Eckelmann <sven@narfation.org>
>  * Tan Xiaojun <tanxiaojun@huawei.com>
> 
> 
> batman-adv
> ----------
> 
> Transforming a rather static design to a module architecture in the interest 
> of preserving backward compatibility requires modifications on a multitude of 
> levels. The principal idea behind the TVLV (type-version-length-value) 
> infrastructure is to break up mesh management data into logic chunks 
> (containers) which can be extended in the future while preserving backward 
> compatibility. If a mesh participant receives an unknown TVLV type or version 
> of a certain container it can simply skip the current container and proceed 
> with the next. Therefore, all non-routing data sent with OGMs (e.g. gateway 
> advertisement, translation table data, etc) were transformed to TVLV 
> containers that are still attached to OGMs. In addition, translation table 
> request & response packets as well as roaming advertisement packets were 
> transformed to TVLV containers too.
> While designing the containers a couple of feature requests were also 
> addressed: The compressed download & upload gateway bandwidth (known as 
> 'gateway class') was replaced by uncompressed bandwidth information permitting 
> granular gateway bandwidth announcement. DAT and network coding feature 
> support is communicated into the mesh through TVLV containers as both 
> subsystems optimize their performance based on the knowledge which mesh 
> participant has the feature enabled.
> In the interest of backward compatibility on the packet forwarding level 
> batman-adv received a general unicast packet forwarding mechanism. This 
> mechanism forwards or drops unknown packet types based on the packet type 
> numbering.
> 
> The batman-adv built-in packet fragmentation has been redesigned and rewritten 
> as part of the 'fragmentation 2' Google Summer of Code project. Major design 
> goals include: Variable number of fragments (up to 16), generic fragmentation 
> framework capable of handling all types of traffic (the 'old' fragmentation code 
> was limited to payload unicast packets) and 'upper layer' transparency through 
> early re-assembly. The maximum of local clients the translation table is able 
> to handle went up by a factor of 16 (the maximum number of fragmented packets) 
> as full translation table exchanges are able to take advantage of the newly 
> introduced generic fragmentation. If the fragmentation is disabled or the MTU 
> altered the local translation table is automatically reduced to fit the new 
> maximum translation table size. Part of the increased maximum table size is 
> the transition from CRC16 consistency checksumming to CRC32 to reduce 
> collision probability and take advantage of hardware acceleration support. The 
> translation table also gained full VLAN awareness making it the final component 
> receiving full VLAN support. Non-mesh clients are now entirely separated on a 
> per-VLAN basis. As a consequence, the bridge loop avoidance is capable of 
> resolving bridge loops more elegantly (one VLAN might be bridged into the LAN 
> while another one is not), the Distributed ARP Table (DAT) builds its 
> distributed IP-MAC address hash on a per-VLAN basis and the AP isolation 
> allows fine-grained control over which VLAN should be isolated and which should 
> not.
> 
> The kernel module sets a dummy rx mode handler on batman-adv' virtual 
> interface creation to be able to accepts static multicast listener 
> configurations on top of the batX interface. In order to help wireless drivers 
> to select the suitable traffic queue (e.g. WMM queues), batman-adv peeks into 
> the encapsulated payload IP or VLAN header and sets the skb priority field 
> accordingly. This priority field is used whenever the lower layer drivers (like 
> wireless or ethernet drivers) are unable to retrieve the prioritization 
> themselves due to the batman-adv traffic encapsulation.
> 
> 
> batctl
> ------
> 
> As part of our ongoing effort for better IPv6 support quite a few missing 
> pieces have been tackled: The IP-address-to-MAC-address resolver was extended 
> to also support IPv6 addresses. This was achieved by porting the internal 
> resolver from the '/proc/net/arp' based approach to the RTNL API. As a result 
> the translate, ping and traceroute commands accept IPv6 addresses as 
> destination argument which batctl tries to convert back to MAC addresses in 
> similar to the IPv4 conversion. Furthermore, the tcpdump component was 
> enriched with an IPv6 parser being able to decapsulate TCP, UDP and common 
> ICMPv6 packet types.
> The vis export feature has been removed as the kernel module no longer 
> supports the visualization protocol. A number of cleanups and smaller fixes 
> such as marking local functions as static, adding header include guards and 
> more found their way into this release as well.
> 
> 
> alfred
> ------
> 
> The missing libmath linker flag of the alfred-gpsd component was fixed and its 
> manpage installation arranged.
> 
> 
> 
> Happy routing,
> The B.A.T.M.A.N. team
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-14 22:04 ` cmsv
@ 2014-01-15  7:00   ` Martin Hundebøll
  2014-01-15 11:13     ` cmsv
  0 siblings, 1 reply; 17+ messages in thread
From: Martin Hundebøll @ 2014-01-15  7:00 UTC (permalink / raw)
  To: cmsv, The list for a Better Approach To Mobile Ad-hoc Networking

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

Hi,

On 2014-01-14 23:04, cmsv wrote:
> batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to
> handle the transport of batman-adv packets. Packets going over this
> interface will be fragmented on layer2 which could impact the
> performance. Setting the MTU to 1546 would solve the problem.

Did you enable network coding? That would explain the message, as NC
uses a larger header to make decoding possible at the receiver side.

As far as I can tell from a quick look in packet.h, the required MTU
should be 1532 now. (10 bytes unicast + 8 bytes extra for unicast_4addr
+ 14 ethernet = 32 bytes). Or am I bad at counting bytes?

// Martin

-- 
Kind Regards
Martin Hundebøll
Frederiks Allé 99, 1.th
8000 Aarhus C
Denmark

+45 61 65 54 61
martin@hundeboll.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-15  7:00   ` Martin Hundebøll
@ 2014-01-15 11:13     ` cmsv
  2014-01-15 11:15       ` Antonio Quartulli
  0 siblings, 1 reply; 17+ messages in thread
From: cmsv @ 2014-01-15 11:13 UTC (permalink / raw)
  To: Martin Hundebøll,
	The list for a Better Approach To Mobile Ad-hoc Networking

inline:

On 01/15/2014 02:00 AM, Martin Hundebøll wrote:
> Hi,
> 
> On 2014-01-14 23:04, cmsv wrote:
>> batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to
>> handle the transport of batman-adv packets. Packets going over this
>> interface will be fragmented on layer2 which could impact the
>> performance. Setting the MTU to 1546 would solve the problem.
> 
> Did you enable network coding? That would explain the message, as NC
> uses a larger header to make decoding possible at the receiver side.
Yes it is enabled by default as it was with batavd 2013.4.0 with 1528 mtu
> 
> As far as I can tell from a quick look in packet.h, the required MTU
> should be 1532 now. (10 bytes unicast + 8 bytes extra for unicast_4addr
> + 14 ethernet = 32 bytes). Or am I bad at counting bytes?

Regardless of being properly counted or not; dmesg outputs the message
complaining about the need to make mtu 1546.


> // Martin
> 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-15 11:13     ` cmsv
@ 2014-01-15 11:15       ` Antonio Quartulli
  2014-01-21 20:01         ` cmsv
  0 siblings, 1 reply; 17+ messages in thread
From: Antonio Quartulli @ 2014-01-15 11:15 UTC (permalink / raw)
  To: cmsv, The list for a Better Approach To Mobile Ad-hoc Networking,
	Martin Hundebøll

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On 15/01/14 12:13, cmsv wrote:
> inline:
> 
> On 01/15/2014 02:00 AM, Martin Hundebøll wrote:
>> Hi,
>>
>> On 2014-01-14 23:04, cmsv wrote:
>>> batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to
>>> handle the transport of batman-adv packets. Packets going over this
>>> interface will be fragmented on layer2 which could impact the
>>> performance. Setting the MTU to 1546 would solve the problem.
>>
>> Did you enable network coding? That would explain the message, as NC
>> uses a larger header to make decoding possible at the receiver side.
> Yes it is enabled by default as it was with batavd 2013.4.0 with 1528 mtu
>>
>> As far as I can tell from a quick look in packet.h, the required MTU
>> should be 1532 now. (10 bytes unicast + 8 bytes extra for unicast_4addr
>> + 14 ethernet = 32 bytes). Or am I bad at counting bytes?
> 
> Regardless of being properly counted or not; dmesg outputs the message
> complaining about the need to make mtu 1546.

If you disable network coding the message will change.

The overhead is dynamic depending on NC being enabled or not and now the
message in dmesg tells you exactly what MTU you need.

Cheers,


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-15 11:15       ` Antonio Quartulli
@ 2014-01-21 20:01         ` cmsv
  2014-01-22  0:00           ` Antonio Quartulli
  0 siblings, 1 reply; 17+ messages in thread
From: cmsv @ 2014-01-21 20:01 UTC (permalink / raw)
  To: Antonio Quartulli,
	The list for a Better Approach To Mobile Ad-hoc Networking,
	Martin Hundebøll

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]



On 01/15/2014 06:15 AM, Antonio Quartulli wrote:
> On 15/01/14 12:13, cmsv wrote:
>> inline:
>>
>> On 01/15/2014 02:00 AM, Martin Hundebøll wrote:
>>> Hi,
>>>
>>> On 2014-01-14 23:04, cmsv wrote:
>>>> batman_adv: bat0: The MTU of interface adhoc0 is too small (1528) to
>>>> handle the transport of batman-adv packets. Packets going over this
>>>> interface will be fragmented on layer2 which could impact the
>>>> performance. Setting the MTU to 1546 would solve the problem.
>>>
>>> Did you enable network coding? That would explain the message, as NC
>>> uses a larger header to make decoding possible at the receiver side.
>> Yes it is enabled by default as it was with batavd 2013.4.0 with 1528 mtu
>>>
>>> As far as I can tell from a quick look in packet.h, the required MTU
>>> should be 1532 now. (10 bytes unicast + 8 bytes extra for unicast_4addr
>>> + 14 ethernet = 32 bytes). Or am I bad at counting bytes?
>>
>> Regardless of being properly counted or not; dmesg outputs the message
>> complaining about the need to make mtu 1546.
> 
> If you disable network coding the message will change.
> 
> The overhead is dynamic depending on NC being enabled or not and now the
> message in dmesg tells you exactly what MTU you need.


Yes i understand that but it keeps on increasing.
[   28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too
small (1546) to handle the transport of batman-adv packets. Packets
going over this interface will be fragmented on layer2 which could
impact the performance. Setting the MTU to 1560 would solve the problem.

> 
> Cheers,
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-21 20:01         ` cmsv
@ 2014-01-22  0:00           ` Antonio Quartulli
  2014-01-22  0:06             ` Antonio Quartulli
  0 siblings, 1 reply; 17+ messages in thread
From: Antonio Quartulli @ 2014-01-22  0:00 UTC (permalink / raw)
  To: cmsv, The list for a Better Approach To Mobile Ad-hoc Networking,
	Martin Hundebøll

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On 21/01/14 21:01, cmsv wrote:
> Yes i understand that but it keeps on increasing.
> [   28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too
> small (1546) to handle the transport of batman-adv packets. Packets
> going over this interface will be fragmented on layer2 which could
> impact the performance. Setting the MTU to 1560 would solve the problem.

Have you tried applying this patch before testing it once again?

http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af0614510368bb7


Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-22  0:00           ` Antonio Quartulli
@ 2014-01-22  0:06             ` Antonio Quartulli
       [not found]               ` <52DF0D4E.5070207@wirelesspt.net>
  0 siblings, 1 reply; 17+ messages in thread
From: Antonio Quartulli @ 2014-01-22  0:06 UTC (permalink / raw)
  To: cmsv, The list for a Better Approach To Mobile Ad-hoc Networking,
	Martin Hundebøll

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

On 22/01/14 01:00, Antonio Quartulli wrote:
> On 21/01/14 21:01, cmsv wrote:
>> Yes i understand that but it keeps on increasing.
>> [   28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too
>> small (1546) to handle the transport of batman-adv packets. Packets
>> going over this interface will be fragmented on layer2 which could
>> impact the performance. Setting the MTU to 1560 would solve the problem.
> 
> Have you tried applying this patch before testing it once again?
> 
> http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af0614510368bb7
> 

Actually this patch is already part of the batman-adv package in openwrt.
Therefore the question turns in: did you update the batman-adv package
before performing your second test?


Cheers,


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
       [not found]               ` <52DF0D4E.5070207@wirelesspt.net>
@ 2014-01-22  0:20                 ` Antonio Quartulli
       [not found]                   ` <52DF10D1.4080207@wirelesspt.net>
  0 siblings, 1 reply; 17+ messages in thread
From: Antonio Quartulli @ 2014-01-22  0:20 UTC (permalink / raw)
  To: cmsv; +Cc: The list for a Better Approach To Mobile Ad-hoc Networking

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On 22/01/14 01:14, cmsv wrote:
> 
> 
> On 01/21/2014 07:06 PM, Antonio Quartulli wrote:
>> On 22/01/14 01:00, Antonio Quartulli wrote:
>>> On 21/01/14 21:01, cmsv wrote:
>>>> Yes i understand that but it keeps on increasing.
>>>> [   28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too
>>>> small (1546) to handle the transport of batman-adv packets. Packets
>>>> going over this interface will be fragmented on layer2 which could
>>>> impact the performance. Setting the MTU to 1560 would solve the problem.
>>>
>>> Have you tried applying this patch before testing it once again?
>>>
>>> http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af0614510368bb7
>>>
>>
>> Actually this patch is already part of the batman-adv package in openwrt.
>> Therefore the question turns in: did you update the batman-adv package
>> before performing your second test?
> 
> the second test was done today and  yesterday's i updated bataman-adv.

Yes but we are creating confusion.

In the second test you *enabled* network coding, therefore it is normal
that the overhead grew up. This happens because NC uses more bytes for
its header.

If you disable NC the suggested value should go back to 1532.


Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
       [not found]                   ` <52DF10D1.4080207@wirelesspt.net>
@ 2014-01-22  0:31                     ` Antonio Quartulli
  2014-01-22  0:52                       ` cmsv
  0 siblings, 1 reply; 17+ messages in thread
From: Antonio Quartulli @ 2014-01-22  0:31 UTC (permalink / raw)
  To: cmsv; +Cc: The list for a Better Approach To Mobile Ad-hoc Networking

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

On 22/01/14 01:29, cmsv wrote:
> 
> 
> On 01/21/2014 07:20 PM, Antonio Quartulli wrote:
>> On 22/01/14 01:14, cmsv wrote:
>>>
>>>
>>> On 01/21/2014 07:06 PM, Antonio Quartulli wrote:
>>>> On 22/01/14 01:00, Antonio Quartulli wrote:
>>>>> On 21/01/14 21:01, cmsv wrote:
>>>>>> Yes i understand that but it keeps on increasing.
>>>>>> [   28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too
>>>>>> small (1546) to handle the transport of batman-adv packets. Packets
>>>>>> going over this interface will be fragmented on layer2 which could
>>>>>> impact the performance. Setting the MTU to 1560 would solve the problem.
>>>>>
>>>>> Have you tried applying this patch before testing it once again?
>>>>>
>>>>> http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af0614510368bb7
>>>>>
>>>>
>>>> Actually this patch is already part of the batman-adv package in openwrt.
>>>> Therefore the question turns in: did you update the batman-adv package
>>>> before performing your second test?
>>>
>>> the second test was done today and  yesterday's i updated bataman-adv.
>>
>> Yes but we are creating confusion.
> Maybe. Lets see.
>>
>> In the second test you *enabled* network coding, therefore it is normal
>> that the overhead grew up. This happens because NC uses more bytes for
>> its header.
> 
> 
> In both tests NC was enabled. I have NC enabled by default before and
> after the update.
> In fact is all tests NC is enabled by default and i undestand the
> increase to 1546 but to 1560 it surprised me.
> Should i still see the increase to 1560  or should it stayed at 1546
> which would be 1532 ?
> 
> 

[Please don't remove the batman-adv mailing list from the CC field.]


The first test you have performed was without the patch that fixes the
value reported in that message.



Now that the patch is applied you have to see 1560 when NC is enabled
and 1532 when it is disabled.


Can you confirm?


cheers,


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-22  0:31                     ` Antonio Quartulli
@ 2014-01-22  0:52                       ` cmsv
  2014-01-22  6:46                         ` Antonio Quartulli
  2014-01-22  6:50                         ` Martin Hundebøll
  0 siblings, 2 replies; 17+ messages in thread
From: cmsv @ 2014-01-22  0:52 UTC (permalink / raw)
  To: Antonio Quartulli
  Cc: The list for a Better Approach To Mobile Ad-hoc Networking

inline:

On 01/21/2014 07:31 PM, Antonio Quartulli wrote:
> On 22/01/14 01:29, cmsv wrote:
>>
>>
>> On 01/21/2014 07:20 PM, Antonio Quartulli wrote:
>>> On 22/01/14 01:14, cmsv wrote:
>>>>
>>>>
>>>> On 01/21/2014 07:06 PM, Antonio Quartulli wrote:
>>>>> On 22/01/14 01:00, Antonio Quartulli wrote:
>>>>>> On 21/01/14 21:01, cmsv wrote:
>>>>>>> Yes i understand that but it keeps on increasing.
>>>>>>> [   28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too
>>>>>>> small (1546) to handle the transport of batman-adv packets. Packets
>>>>>>> going over this interface will be fragmented on layer2 which could
>>>>>>> impact the performance. Setting the MTU to 1560 would solve the problem.
>>>>>>
>>>>>> Have you tried applying this patch before testing it once again?
>>>>>>
>>>>>> http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af0614510368bb7
>>>>>>
>>>>>
>>>>> Actually this patch is already part of the batman-adv package in openwrt.
>>>>> Therefore the question turns in: did you update the batman-adv package
>>>>> before performing your second test?
>>>>
>>>> the second test was done today and  yesterday's i updated bataman-adv.
>>>
>>> Yes but we are creating confusion.
>> Maybe. Lets see.
>>>
>>> In the second test you *enabled* network coding, therefore it is normal
>>> that the overhead grew up. This happens because NC uses more bytes for
>>> its header.
>>
>>
>> In both tests NC was enabled. I have NC enabled by default before and
>> after the update.
>> In fact is all tests NC is enabled by default and i undestand the
>> increase to 1546 but to 1560 it surprised me.
>> Should i still see the increase to 1560  or should it stayed at 1546
>> which would be 1532 ?
>>
>>
> 
> [Please don't remove the batman-adv mailing list from the CC field.]
> 
unintentional mistake of too many buttons around :P

> 
> The first test you have performed was without the patch that fixes the
> value reported in that message.
> 
> 
> 
> Now that the patch is applied you have to see 1560 when NC is enabled
> and 1532 when it is disabled.

Doing some tests and with NC disabled:

 uci show batman-adv | grep network_coding
batman-adv.bat0.network_coding=0

after reboot:

# dmesg | grep MTU
[   28.030000] batman_adv: bat0: The MTU of interface adhoc0 is too
small (1546) to handle the transport of batman-adv packets. Packets
going over this interface will be fragmented on layer2 which could
impact the performance. Setting the MTU to 1560 would solve the problem.

 uci show network | grep mtu
network.mesh0.mtu=1546

changing the mtu to 1560 when NC is disabled:

# uci show batman-adv | grep network_coding
batman-adv.bat0.network_coding=0

# dmesg | grep MTU
no output/result

# ifconfig | grep MTU
          UP BROADCAST RUNNING MULTICAST  MTU:1560  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Frist result if the adhoc interface with 1560

correct me if i am mistaken but according to you it should be 1532 ?

Changing it to 1532 still keeping network coding disabled.

uci set network.mesh0.mtu=1532
uci commit network
reboot

 uci show network| grep mtu
network.mesh0.mtu=1532

 uci show batman-adv | grep network_coding
batman-adv.bat0.network_coding=0

# dmesg | grep MTU
[   28.020000] batman_adv: bat0: The MTU of interface adhoc0 is too
small (1532) to handle the transport of batman-adv packets. Packets
going over this interface will be fragmented on layer2 which could
impact the performance. Setting the MTU to 1560 would solve the problem.

# dmesg | grep MTU
[   28.020000] batman_adv: bat0: The MTU of interface adhoc0 is too
small (1532) to handle the transport of batman-adv packets. Packets
going over this interface will be fragmented on layer2 which could
impact the performance. Setting the MTU to 1560 would solve the problem.

# ifconfig | grep MTU
          UP BROADCAST RUNNING MULTICAST  MTU:1532  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1


Changing now the MTU to 1560

uci set network.mesh0.mtu=1560
uci commit network
reboot

Keeping batman-adv.bat0.network_coding=0

# uci show network| grep mtu
network.mesh0.mtu=1560

# ifconfig | grep MTU
          UP BROADCAST RUNNING MULTICAST  MTU:1560  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

# dmesg | grep MTU
no complaints.


if i enable network coding and the mtu to 1560 no complaints either.

> Can you confirm?

confirmed ?
>
> 
> cheers,



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-22  0:52                       ` cmsv
@ 2014-01-22  6:46                         ` Antonio Quartulli
  2014-01-22  6:50                         ` Martin Hundebøll
  1 sibling, 0 replies; 17+ messages in thread
From: Antonio Quartulli @ 2014-01-22  6:46 UTC (permalink / raw)
  To: cmsv; +Cc: The list for a Better Approach To Mobile Ad-hoc Networking

[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]

On 22/01/14 01:52, cmsv wrote:
> inline:
> 
> On 01/21/2014 07:31 PM, Antonio Quartulli wrote:
>> On 22/01/14 01:29, cmsv wrote:
>>>
>>>
>>> On 01/21/2014 07:20 PM, Antonio Quartulli wrote:
>>>> On 22/01/14 01:14, cmsv wrote:
>>>>>
>>>>>
>>>>> On 01/21/2014 07:06 PM, Antonio Quartulli wrote:
>>>>>> On 22/01/14 01:00, Antonio Quartulli wrote:
>>>>>>> On 21/01/14 21:01, cmsv wrote:
>>>>>>>> Yes i understand that but it keeps on increasing.
>>>>>>>> [   28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too
>>>>>>>> small (1546) to handle the transport of batman-adv packets. Packets
>>>>>>>> going over this interface will be fragmented on layer2 which could
>>>>>>>> impact the performance. Setting the MTU to 1560 would solve the problem.
>>>>>>>
>>>>>>> Have you tried applying this patch before testing it once again?
>>>>>>>
>>>>>>> http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af0614510368bb7
>>>>>>>
>>>>>>
>>>>>> Actually this patch is already part of the batman-adv package in openwrt.
>>>>>> Therefore the question turns in: did you update the batman-adv package
>>>>>> before performing your second test?
>>>>>
>>>>> the second test was done today and  yesterday's i updated bataman-adv.
>>>>
>>>> Yes but we are creating confusion.
>>> Maybe. Lets see.
>>>>
>>>> In the second test you *enabled* network coding, therefore it is normal
>>>> that the overhead grew up. This happens because NC uses more bytes for
>>>> its header.
>>>
>>>
>>> In both tests NC was enabled. I have NC enabled by default before and
>>> after the update.
>>> In fact is all tests NC is enabled by default and i undestand the
>>> increase to 1546 but to 1560 it surprised me.
>>> Should i still see the increase to 1560  or should it stayed at 1546
>>> which would be 1532 ?
>>>
>>>
>>
>> [Please don't remove the batman-adv mailing list from the CC field.]
>>
> unintentional mistake of too many buttons around :P
> 
>>
>> The first test you have performed was without the patch that fixes the
>> value reported in that message.
>>
>>
>>
>> Now that the patch is applied you have to see 1560 when NC is enabled
>> and 1532 when it is disabled.
> 
> Doing some tests and with NC disabled:
> 
>  uci show batman-adv | grep network_coding
> batman-adv.bat0.network_coding=0
> 
> after reboot:
> 
> # dmesg | grep MTU
> [   28.030000] batman_adv: bat0: The MTU of interface adhoc0 is too
> small (1546) to handle the transport of batman-adv packets. Packets
> going over this interface will be fragmented on layer2 which could
> impact the performance. Setting the MTU to 1560 would solve the problem.
> 
>  uci show network | grep mtu
> network.mesh0.mtu=1546
> 
> changing the mtu to 1560 when NC is disabled:
> 
> # uci show batman-adv | grep network_coding
> batman-adv.bat0.network_coding=0
> 
> # dmesg | grep MTU
> no output/result
> 
> # ifconfig | grep MTU
>           UP BROADCAST RUNNING MULTICAST  MTU:1560  Metric:1
>           UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
>           UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
> Frist result if the adhoc interface with 1560
> 
> correct me if i am mistaken but according to you it should be 1532 ?
> 
> Changing it to 1532 still keeping network coding disabled.
> 
> uci set network.mesh0.mtu=1532
> uci commit network
> reboot
> 
>  uci show network| grep mtu
> network.mesh0.mtu=1532
> 
>  uci show batman-adv | grep network_coding
> batman-adv.bat0.network_coding=0

No, the MTU value changes only when NC is disabled at compile time.


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-22  0:52                       ` cmsv
  2014-01-22  6:46                         ` Antonio Quartulli
@ 2014-01-22  6:50                         ` Martin Hundebøll
  1 sibling, 0 replies; 17+ messages in thread
From: Martin Hundebøll @ 2014-01-22  6:50 UTC (permalink / raw)
  To: cmsv, The list for a Better Approach To Mobile Ad-hoc Networking,
	Antonio Quartulli

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

Hi cmsv,

On 2014-01-22 01:52, cmsv wrote:
>  uci show batman-adv | grep network_coding
> batman-adv.bat0.network_coding=0
> 
> after reboot:
> 
> # dmesg | grep MTU
> [   28.030000] batman_adv: bat0: The MTU of interface adhoc0 is too
> small (1546) to handle the transport of batman-adv packets. Packets
> going over this interface will be fragmented on layer2 which could
> impact the performance. Setting the MTU to 1560 would solve the problem.
> 
>  uci show network | grep mtu
> network.mesh0.mtu=1546
> 
> changing the mtu to 1560 when NC is disabled:
> 
> # uci show batman-adv | grep network_coding
> batman-adv.bat0.network_coding=0
> 
> # dmesg | grep MTU
> no output/result

It might not have been clear, but when we tell to disable NC, we are
referring to the compile time options. batman-adv is not considering if
NC is enabled/disabled at runtime when checking for MTU, but only
checking if NC is compiled in or not.

It might make sense to check for runtime options when complaining about
MTU in batman-adv, but I don't think so, as it complicates the checks
whenever MTU is changed or NC is toggled.

// Martin

-- 
Kind Regards
Martin Hundebøll
Frederiks Allé 99, 1.th
8000 Aarhus C
Denmark

+45 61 65 54 61
martin@hundeboll.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-01-07 12:53 [B.A.T.M.A.N.] batman-adv 2014.0.0 released Marek Lindner
  2014-01-14 22:04 ` cmsv
@ 2014-02-10 19:45 ` cmsv
  2014-02-10 19:57   ` Antonio Quartulli
  2014-02-10 21:49   ` Linus Lüssing
  1 sibling, 2 replies; 17+ messages in thread
From: cmsv @ 2014-02-10 19:45 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking


[-- Attachment #1.1: Type: text/plain, Size: 1188 bytes --]

In regards to incompatibility with pre-2014.0.0 versions; will 2013.4.0
branch have any continued support with patches or even updated version
or any support pre-2014.0.0 is not expected or planed ?


On 01/07/2014 07:53 AM, Marek Lindner wrote:
> Important changes
> -----------------
> 
> *Compatibility break*: In 2011, batman-adv broke backward compatibility with 
> the introduction of the translation table mechanism. Since then, interests 
> have been divided between those who wish a stable network with as little 
> changes as possible and those who wish to experiment with new features to 
> bring meshing to the next level. To accommodate both groups the batman-adv 
> developers dedicated a lot of effort on building code infrastructure allowing 
> to mix stable nodes with new features without breaking compatibility. This new 
> system is incompatible to the pre-2014.0.0 versions, but it has been designed 
> to stay compatible with future versions for the next decade or so.
> 
> At the same time, the legacy visualization support was removed from the kernel 
> module. The alfred user space module provides an adequate replacement.
> 
> 
> Thanks

[-- Attachment #1.2: 0x15C4B382.asc --]
[-- Type: application/pgp-keys, Size: 36799 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-02-10 19:45 ` cmsv
@ 2014-02-10 19:57   ` Antonio Quartulli
  2014-02-10 21:49   ` Linus Lüssing
  1 sibling, 0 replies; 17+ messages in thread
From: Antonio Quartulli @ 2014-02-10 19:57 UTC (permalink / raw)
  To: b.a.t.m.a.n

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On 10/02/14 20:45, cmsv wrote:
> In regards to incompatibility with pre-2014.0.0 versions; will 2013.4.0
> branch have any continued support with patches or even updated version
> or any support pre-2014.0.0 is not expected or planed ?
> 

The core group (read: the most active developers) are not going to
maintain any pre-2014.0.0 branch. The code base in 2014.0.0 is rather
different wrt older versions therefore any "backport" will be really
expensive in terms of time and effort.

Only crucial bugfixes are going to be ported to older versions (by means
of our maint branch - for a limited time - and the stable kernel releases).

However nobody prevents anyone from the community to take over this task.


Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-02-10 19:45 ` cmsv
  2014-02-10 19:57   ` Antonio Quartulli
@ 2014-02-10 21:49   ` Linus Lüssing
  2014-02-11  3:22     ` Marek Lindner
  1 sibling, 1 reply; 17+ messages in thread
From: Linus Lüssing @ 2014-02-10 21:49 UTC (permalink / raw)
  To: cmsv; +Cc: b.a.t.m.a.n

On Mon, Feb 10, 2014 at 02:45:11PM -0500, cmsv wrote:
> In regards to incompatibility with pre-2014.0.0 versions; will 2013.4.0
> branch have any continued support with patches or even updated version
> or any support pre-2014.0.0 is not expected or planed ?
> 

We are planning to mantain a compat-14 branch for a couple of
months here:

https://github.com/freifunk-gluon/batman-adv-legacy

Contributions welcome :).

Cheers, Linus

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
  2014-02-10 21:49   ` Linus Lüssing
@ 2014-02-11  3:22     ` Marek Lindner
  0 siblings, 0 replies; 17+ messages in thread
From: Marek Lindner @ 2014-02-11  3:22 UTC (permalink / raw)
  To: b.a.t.m.a.n

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

On Monday 10 February 2014 22:49:09 Linus Lüssing wrote:
> On Mon, Feb 10, 2014 at 02:45:11PM -0500, cmsv wrote:
> > In regards to incompatibility with pre-2014.0.0 versions; will 2013.4.0
> > branch have any continued support with patches or even updated version
> > or any support pre-2014.0.0 is not expected or planed ?
> 
> We are planning to mantain a compat-14 branch for a couple of
> months here:
> 
> https://github.com/freifunk-gluon/batman-adv-legacy
> 
> Contributions welcome :).

As already mentioned on IRC: We can easily host your batman-adv-legacy code on 
open-mesh.org next to the other repositories. That'll make it easier for other 
people to find it and may appear to be more 'official'.

Cheers,
Marek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2014-02-11  3:22 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-07 12:53 [B.A.T.M.A.N.] batman-adv 2014.0.0 released Marek Lindner
2014-01-14 22:04 ` cmsv
2014-01-15  7:00   ` Martin Hundebøll
2014-01-15 11:13     ` cmsv
2014-01-15 11:15       ` Antonio Quartulli
2014-01-21 20:01         ` cmsv
2014-01-22  0:00           ` Antonio Quartulli
2014-01-22  0:06             ` Antonio Quartulli
     [not found]               ` <52DF0D4E.5070207@wirelesspt.net>
2014-01-22  0:20                 ` Antonio Quartulli
     [not found]                   ` <52DF10D1.4080207@wirelesspt.net>
2014-01-22  0:31                     ` Antonio Quartulli
2014-01-22  0:52                       ` cmsv
2014-01-22  6:46                         ` Antonio Quartulli
2014-01-22  6:50                         ` Martin Hundebøll
2014-02-10 19:45 ` cmsv
2014-02-10 19:57   ` Antonio Quartulli
2014-02-10 21:49   ` Linus Lüssing
2014-02-11  3:22     ` Marek Lindner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).