Skip to content
Snippets Groups Projects
  1. Dec 02, 2018
  2. Sep 16, 2018
  3. Sep 15, 2018
  4. Sep 05, 2018
  5. Sep 01, 2018
  6. Aug 24, 2018
  7. Aug 23, 2018
  8. Aug 19, 2018
  9. Aug 06, 2018
  10. Aug 03, 2018
  11. Aug 01, 2018
  12. Jul 29, 2018
  13. Jul 25, 2018
  14. Jul 22, 2018
    • Sven Eckelmann's avatar
      gluon-client-bridge: Revert "move IPv4 local subnet route to br-client (#1312)" · 3ef28a46
      Sven Eckelmann authored
      The commit b3762fc6 ("gluon-client-bridge: move IPv4 local subnet route
      to br-client (#1312)") moves the IPv4 prefix from the local-port interface
      to br-client. A client requesting an IPv4 connection to the IPv4 anycast
      address of the node (the device running gluon) will create following
      packets:
      
      1. ARP packet from client to get the MAC of the mac address of the anycast
         IPv4 address
      2. ARP reply from node to client with the anycast MAC address for the IPv4
         anycast address
      3. IPv4 packet from client which requires reply (for example ICMP echo
         request)
      4. ARP request for the client MAC address for its IPv4 address in prefix4
         (done with the mac address of br-client and transmitted over br-client)
      5. IPv4 packet from node (transmitted over br-client with br-client MAC
         address) as reply for the client IPv4 packet (for example ICMP echo
         reply)
      
      The step 4 and 5 are problematic here because packets use the node specific
      MAC addresses from br-client instead of the anycast MAC address. The client
      will receive the ARP packet with the node specific MAC address and change
      their own neighbor IP (translation) table. This will for example break the
      access to the status page to the connected device or the anycast DNS
      forwarder implementation when the client roams to a different node.
      
      This reverts commit b3762fc6 and adds an
      upgrade code to remove local_node_route on on existing installations.
      3ef28a46
    • Sven Eckelmann's avatar
      gluon-mesh-batman-adv: Drop IPv4 anycast related packets from/to bat0 · fc59d520
      Sven Eckelmann authored
      The commit b3762fc6 ("gluon-client-bridge: move IPv4 local subnet route
      to br-client (#1312)") moves the IPv4 prefix from the local-port interface
      to br-client. A client requesting an IPv4 connection to the IPv4 anycast
      address of the node (the device running gluon) will create following
      packets:
      
      1. ARP packet from client to get the MAC of the mac address of the anycast
         IPv4 address
      2. ARP reply from node to client with the anycast MAC address for the IPv4
         anycast address
      3. IPv4 packet from client which requires reply (for example ICMP echo
         request)
      4. ARP request for the client MAC address for its IPv4 address in prefix4
         (done with the mac address of br-client and transmitted over br-client)
      5. IPv4 packet from node (transmitted over br-client with br-client MAC
         address) as reply for the client IPv4 packet (for example ICMP echo
         reply)
      
      The step 4 is extremely problematic here. ARP replies with the anycast IPv4
      address must not be submitted or received via bat0 - expecially not when it
      contains an node specific MAC address as source. When it is still done then
      the wrong MAC address is stored in the batadv DAT cache and ARP packet is
      maybe even forwarded to clients. This latter is especially true for ARP
      requests which are broadcast and will be flooded to the complete mesh.
      
      Clients will see these ARP packets and change their own neighbor IP
      (translation) table. They will then try to submit the packets for IPv4
      anycast addresses to the complete wrong device in the mesh. This will for
      example break the access to the status page to the connected device or the
      anycast DNS forwarder implementation. Especially the latter causes extreme
      latency when clients try to connect to server using a domain name or even
      breaks the connection setup process completely. Both are caused by the
      unanswered DNS requests which at first glance look like packet loss.
      
      An node must therefore take care of:
      
      * not transmitting ARP packets related to the anycast IPv4 address over
        bat0
      * drop ARP packets related to the anycast IPv4 when they are received on
        bat0 from a still broken node
      * don't accept ARP packets related to the anycast IPv4 replies on local
        node when it comes from bat0
      
      Fixes: b3762fc6 ("gluon-client-bridge: move IPv4 local subnet route to br-client (#1312)")
      fc59d520
  15. Jul 19, 2018
  16. Jul 17, 2018
Loading