26 Jan, 2017

1 commit


19 Oct, 2016

1 commit


17 Oct, 2016

1 commit


09 Aug, 2016

1 commit

  • This adds the commands BATADV_CMD_GET_TRANSTABLE_LOCAL and
    BATADV_CMD_GET_TRANSTABLE_GLOBAL, which correspond to the transtable_local
    and transtable_global debugfs files.

    The batadv_tt_client_flags enum is moved to the UAPI to expose it as part
    of the netlink API.

    Signed-off-by: Matthias Schiffer
    Signed-off-by: Andrew Lunn
    [sven.eckelmann@open-mesh.com: add policy for attributes, fix includes]
    Signed-off-by: Sven Eckelmann
    [sw@simonwunderlich.de: fix VID attributes content]
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Marek Lindner

    Matthias Schiffer
     

04 Jul, 2016

1 commit

  • The throughput meter module is a simple, kernel-space replacement for
    throughtput measurements tool like iperf and netperf. It is intended to
    approximate TCP behaviour.

    It is invoked through batctl: the protocol is connection oriented, with
    cumulative acknowledgment and a dynamic-size sliding window.

    The test *can* be interrupted by batctl. A receiver side timeout avoids
    unlimited waitings for sender packets: after one second of inactivity, the
    receiver abort the ongoing test.

    Based on a prototype from Edo Monticelli

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Marek Lindner
    Signed-off-by: Simon Wunderlich

    Antonio Quartulli
     

30 Jun, 2016

1 commit

  • Unfragmented frames which traverse a node have their skb->priority set
    by looking at the IP ToS byte, or the 802.1p header. However for
    fragments this is not possible, only one of the fragments will contain
    the headers. Instead, place the priority into the fragment header and
    on receiving a fragment, use this information to set the skb->priority
    for when the fragment is forwarded.

    Signed-off-by: Andrew Lunn
    Signed-off-by: Marek Lindner
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Simon Wunderlich

    Andrew Lunn
     

10 May, 2016

1 commit

  • There are network setups where the current bridge loop avoidance can't
    detect bridge loops. The minimal setup affected would consist of two
    LANs and two separate meshes, connected in a ring like that:

    A...(mesh1)...B
    | |
    (LAN1) (LAN2)
    | |
    C...(mesh2)...D

    Since both the meshes and backbones are separate, the bridge loop
    avoidance has not enough information to detect and avoid the loop
    in this case. Even if these scenarios can't be fixed easily,
    these kind of loops can be detected.

    This patch implements a periodic check (running every 60 seconds for
    now) which sends a broadcast frame with a random MAC address on
    each backbone VLAN. If a broadcast frame with the same MAC address
    is received shortly after on the mesh, we know that there must be a
    loop and report that incident as well as throw an uevent to let others
    handle that problem.

    Signed-off-by: Simon Wunderlich
    [sven@narfation.org: fix conflicts with current version]
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Simon Wunderlich
     

04 May, 2016

1 commit


29 Feb, 2016

2 commits

  • This is the initial implementation of the new OGM protocol
    (version 2). It has been designed to work on top of the
    newly added ELP.

    In the previous version the OGM protocol was used to both
    measure link qualities and flood the network with the metric
    information. In this version the protocol is in charge of
    the latter task only, leaving the former to ELP.

    This means being able to decouple the interval used by the
    neighbor discovery from the OGM broadcasting, which revealed
    to be costly in dense networks and needed to be relaxed so
    leading to a less responsive routing protocol.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     
  • The B.A.T.M.A.N. protocol originally only used a single
    message type (called OGM) to determine the link qualities to
    the direct neighbors and spreading these link quality
    information through the whole mesh. This procedure is
    summarized on the BATMAN concept page and explained in
    details in the RFC draft published in 2008.

    This approach was chosen for its simplicity during the
    protocol design phase and the implementation. However, it
    also bears some drawbacks:

    * Wireless interfaces usually come with some packet loss,
    therefore a higher broadcast rate is desirable to allow
    a fast reaction on flaky connections.
    Other interfaces of the same host might be connected to
    Ethernet LANs / VPNs / etc which rarely exhibit packet
    loss would benefit from a lower broadcast rate to reduce
    overhead.
    * It generally is more desirable to detect local link
    quality changes at a faster rate than propagating all
    these changes through the entire mesh (the far end of
    the mesh does not need to care about local link quality
    changes that much). Other optimizations strategies, like
    reducing overhead, might be possible if OGMs weren't
    used for all tasks in the mesh at the same time.

    As a result detecting local link qualities shall be handled
    by an independent message type, ELP, whereas the OGM message
    type remains responsible for flooding the mesh with these
    link quality information and determining the overall path
    transmit qualities.

    Developed by Linus during a 6 months trainee study period in
    Ascom (Switzerland) AG.

    Signed-off-by: Linus Luessing
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Linus Luessing
     

02 Feb, 2016

5 commits


09 Jan, 2016

1 commit


25 Aug, 2015

1 commit


07 Jun, 2015

1 commit

  • The header files could not be build indepdent from each other. This is
    happened because headers didn't include the files for things they've used.
    This was problematic because the success of a build depended on the
    knowledge about the right order of local includes.

    Also source files were not including everything they've used explicitly.
    Instead they required that transitive includes are always stable. This is
    problematic because some transitive includes are not obvious, depend on
    config settings and may not be stable in the future.

    The order for include blocks are:

    * primary headers (main.h and the *.h file of a *.c file)
    * global linux headers
    * required local headers
    * extra forward declarations for pointers in function/struct declarations

    The only exceptions are linux/bitops.h and linux/if_ether.h in packet.h.
    This header file is shared with userspace applications like batctl and must
    therefore build together with userspace applications. The header
    linux/bitops.h is not part of the uapi headers and linux/if_ether.h
    conflicts with the musl implementation of netinet/if_ether.h. The
    maintainers rejected the use of __KERNEL__ preprocessor checks and thus
    these two headers are only in main.h. All files using packet.h first have
    to include main.h to work correctly.

    Reported-by: Markus Pargmann
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Marek Lindner

    Sven Eckelmann
     

29 May, 2015

1 commit


08 Jan, 2015

2 commits


22 Mar, 2014

4 commits

  • Convert the current documentation for the TT flags in proper
    kerneldoc and improve it by adding an explanation for each
    of the flags.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     
  • With this patch a node sends IPv4 multicast packets to nodes which
    have a BATADV_MCAST_WANT_ALL_IPV4 flag set and IPv6 multicast packets
    to nodes which have a BATADV_MCAST_WANT_ALL_IPV6 flag set, too.

    Why is this needed? There are scenarios involving bridges where
    multicast report snooping and multicast TT announcements are not
    sufficient, which would lead to packet loss for some nodes otherwise:

    MLDv1 and IGMPv1/IGMPv2 have a suppression mechanism
    for multicast listener reports. When we have an MLDv1/IGMPv1/IGMPv2
    querier behind a bridge then our snooping bridge is potentially not
    going to see any reports even though listeners exist because according
    to RFC4541 such reports are only forwarded to multicast routers:

    -----------------------------------------------------------
    ---------------
    {Querier}---|Snoop. Switch|----{Listener}
    ---------------
    \ ^
    -------
    | br0 | < ???
    -------
    \
    _-~---~_
    _-~/ ~-_
    ~ batman-adv \-----{Sender}
    \~_ cloud ~/
    -~~__-__-~_/

    I) MLDv1 Query: {Querier} -> flooded
    II) MLDv1 Report: {Listener} -> {Querier}

    -> br0 cannot detect the {Listener}
    => Packets from {Sender} need to be forwarded to all
    detected listeners and MLDv1/IGMPv1/IGMPv2 queriers.

    -----------------------------------------------------------

    Note that we do not need to explicitly forward to MLDv2/IGMPv3 queriers,
    because these protocols have no report suppression: A bridge has no
    trouble detecting MLDv2/IGMPv3 listeners.

    Even though we do not support bridges yet we need to provide the
    according infrastructure already to not break compatibility later.

    Signed-off-by: Linus Lüssing
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Linus Lüssing
     
  • With this patch a node may additionally perform the dropping or
    unicasting behaviour for a link-local IPv4 and link-local-all-nodes
    IPv6 multicast packet, too.

    The extra counter and BATADV_MCAST_WANT_ALL_UNSNOOPABLES flag is needed
    because with a future bridge snooping support integration a node with a
    bridge on top of its soft interface is not able to reliably detect its
    multicast listeners for IPv4 link-local and the IPv6
    link-local-all-nodes addresses anymore (see RFC4541, section 2.1.2.2
    and section 3).

    Even though this new flag does make "no difference" now, it'll ensure
    a seamless integration of multicast bridge support without needing to
    break compatibility later.

    Also note, that even with multicast bridge support it won't be possible
    to optimize 224.0.0.x and ff02::1 towards nodes with bridges, they will
    always receive these ranges.

    Signed-off-by: Linus Lüssing
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Linus Lüssing
     
  • If the soft interface of a node is not part of a bridge then a node
    announces a new multicast TVLV: The existence of this TVLV
    signalizes that this node is announcing all of its multicast listeners
    via the translation table infrastructure.

    Signed-off-by: Linus Lüssing
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Linus Lüssing
     

12 Jan, 2014

1 commit


09 Jan, 2014

2 commits

  • A client sending packets which mark matches the value
    configured via sysfs has to be identified as isolated using
    the TT_CLIENT_ISOLA flag.

    The match is mask based, meaning that only bits set in the
    mask are compared with those in the mark value.

    If the configured mask is equal to 0 no operation is
    performed.

    Such flag is then advertised within the classic client
    announcement mechanism.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     
  • As suggested by checkpatch, remove all the references to the
    FSF address since the kernel already has one reference in
    its documentation.

    In this way it is easier to update it in case of future
    changes.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     

28 Dec, 2013

5 commits


23 Oct, 2013

2 commits

  • Instead of handling icmp packets only up to length of icmp_packet_rr,
    the code should handle any icmp length size. Therefore the length
    truncating is moved to when the packet is actually sent to userspace
    (this does not support lengths longer than icmp_packet_rr yet). Longer
    packets are forwarded without truncating.

    This patch also cleans up some parts where the icmp header struct could
    be used instead of other icmp_packet(_rr) structs to make the code more
    readable.

    Signed-off-by: Simon Wunderlich
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Simon Wunderlich
     
  • Flags covered by TT_SYNC_MASK are kept in sync among the
    nodes in the network and therefore they have to be
    considered while computing the global/local table CRC.

    In this way a generic originator is able to understand if
    its table contains the correct flags or not.

    Bits from 4 to 7 in the TT flags fields are now reserved for
    "synchronized" flags only.

    This allows future developers to add more flags of this type
    without breaking compatibility.

    It's important to note that not all the remote TT flags are
    synchronised. This comes from the fact that some flags are
    used to inject an information once only.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     

20 Oct, 2013

1 commit

  • This change allows nodes to handle the TT table on a
    per-VLAN basis. This is needed because nodes may have to
    store only some of the global entries advertised by another
    node.

    In this scenario such nodes would re-create only a partial
    global table and would not be able to compute a correct CRC
    anymore.

    This patch splits the logic and introduces one CRC per VLAN.
    In this way a node fetching only some entries belonging to
    some VLANs is still able to compute the needed CRCs and
    still check the table correctness.

    With this patch the shape of the TVLV-TT is changed too
    because now a node needs to advertise all the CRCs of all
    the VLANs that it is wired to.

    The debug output of the local Translation Table now shows
    the CRC along with each entry since there is not a common
    value for the entire table anymore.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     

19 Oct, 2013

1 commit


12 Oct, 2013

3 commits

  • the icmp and the icmp_rr packets share the same initial
    fields since they use the same code to be processed and
    forwarded.

    Extract the common fields and put them into a separate
    struct so that future ICMP packets can be easily added
    without bloating the packet definition.

    However, keep the seqno field outside of the newly created
    common header because future ICMP types may require a
    bigger sequence number space.

    This change breaks compatibility due to fields reordering
    in the ICMP headers.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     
  • Fragments arriving at their destination are buffered for later merge.
    Merged packets are passed to the main receive function as had they never
    been fragmented.

    Fragments are forwarded without merging if the MTU of the outgoing
    interface is smaller than the size of the merged packet.

    Signed-off-by: Martin Hundebøll
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Martin Hundebøll
     
  • Remove the existing fragmentation code before adding the new version
    and delete unicast.{h,c}.

    batadv_unicast_send_skb() is moved to send.c and renamed to
    batadv_send_skb_unicast().

    fragmentation entry in sysfs (bat_priv->fragmentation) is kept for use in
    the new fragmentation code.

    BATADV_UNICAST_FRAG packet type is renamed to BATADV_FRAG for use in the
    new fragmentation code.

    Signed-off-by: Martin Hundebøll
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Martin Hundebøll