Project

General

Profile

Actions

Bug #409

open

DAT: received packet on bat0.20/eth0 with own address as source address

Added by Matteo Fortini almost 4 years ago. Updated almost 4 years ago.

Status:
In Progress
Priority:
Normal
Target version:
-
Start date:
04/22/2020
Due date:
% Done:

0%

Estimated time:

Description

I have a batman-adv network with four (openwrt 19.07.2) nodes on an 802.11s mesh, two of which are connected by ethernet, too:

  • batman is active on the mesh interface for all nodes, has two VLANs defined (bat0.20 and bat0.107).
    • bat0.20 is the "private" VLAN and is bridged to the ethernet network and a wifi SSID*
  • bat0.107 is bridged to a secondary wifi SSID
  • All the bridges have STP off, while batman has bl active
    • batman-adv is correctly finding the backbone and the two wired nodes see each other as neighbors in the bbt.
  • I changed the MAC address of all wifi interfaces and of the wired ones so that I have no duplicate MAC addresses on the network. See mac address...

In the logs I have every 30s or so the "received packet on bat0.20 with own address..." message.

I can reproduce the problem with DAT enabled, if I disable DAT just on the offending nodes, the problem goes away

Moreover, sometimes the message is repeated much more frequently, as you can see here (the MAC address is unique in all the network):

See log...


Related issues 1 (0 open1 closed)

Related to batman-adv - Bug #170: br-lan: received packet on bat0 with own address as source addressClosedAntonio Quartulli05/06/2013

Actions
Actions #1

Updated by Sven Eckelmann almost 4 years ago

  • Assignee changed from batman-adv developers to Simon Wunderlich
Actions #2

Updated by Sven Eckelmann almost 4 years ago

What packet is reported here? Did you check for uevent BATADV_UEV_LOOPDETECT? Is the mac address of the br-pvtlan the same as bat0?

Actions #3

Updated by Sven Eckelmann almost 4 years ago

  • Status changed from New to Feedback
  • Assignee changed from Simon Wunderlich to Matteo Fortini
Actions #4

Updated by Matteo Fortini almost 4 years ago

I add that the two nodes connected to the wired network are the only ones seeing the issue, the wireless ones are not saying anything.

Actions #5

Updated by Matteo Fortini almost 4 years ago

Sven Eckelmann wrote:

What packet is reported here? Did you check for uevent BATADV_UEV_LOOPDETECT? Is the mac address of the br-pvtlan the same as bat0?

The mac address of the bridge used to be the same, then I changed it. Problem is still there. I haven't checked the uevent, I will look into it

bat0      Link encap:Ethernet  HWaddr BA:03:29:67:EF:22  
bat0.107  Link encap:Ethernet  HWaddr BA:03:29:67:EF:22  
bat0.20   Link encap:Ethernet  HWaddr BA:03:29:67:EF:22  
br-IOT    Link encap:Ethernet  HWaddr 92:83:C4:00:C3:A4  
br-pvtlan Link encap:Ethernet  HWaddr 96:83:C4:00:C3:98  
eth0      Link encap:Ethernet  HWaddr 94:83:C4:00:C3:97  
eth0.1    Link encap:Ethernet  HWaddr 96:83:C4:00:C3:9A  
eth0.2    Link encap:Ethernet  HWaddr 96:83:C4:00:C3:AA  
ifb4pppoe-wan Link encap:Ethernet  HWaddr 3E:AB:72:AC:68:E9  
mesh0     Link encap:Ethernet  HWaddr 92:83:C4:00:C3:A2  
wlan0-1   Link encap:Ethernet  HWaddr 92:83:C4:00:C3:A0  
wlan0-2   Link encap:Ethernet  HWaddr 92:83:C4:00:C3:A4  
Actions #6

Updated by Matteo Fortini almost 4 years ago

Sven Eckelmann wrote:

What packet is reported here? Did you check for uevent BATADV_UEV_LOOPDETECT? Is the mac address of the br-pvtlan the same as bat0?

Sorry, how do I dump the uevents in openwrt? I tried procd but it seems I haven't found the right command line yet. Thank you

Actions #7

Updated by Matteo Fortini almost 4 years ago

The packets seem to be ARP requests.

(I have DAT enabled)

logread...

tcpdump...

Actions #8

Updated by Matteo Fortini almost 4 years ago

I can reproduce the problem with DAT enabled, if I disable DAT just on the offending nodes, the problem goes away

Actions #9

Updated by Sven Eckelmann almost 4 years ago

  • Related to Bug #170: br-lan: received packet on bat0 with own address as source address added
Actions #10

Updated by Sven Eckelmann almost 4 years ago

  • Subject changed from received packet on bat0.20/eth0 with own address as source address storming the network to DAT: received packet on bat0.20/eth0 with own address as source address
  • Description updated (diff)
  • Status changed from Feedback to In Progress
  • Assignee changed from Matteo Fortini to Antonio Quartulli

I can reproduce the problem with DAT enabled, if I disable DAT just on the offending nodes, the problem goes away

Ok, so it sounds like a bug for the DAT author.

Regarding loopdetect. I think you can manually install udevadmin (in a really manual way) to get the monitor command. Maybe Linus can add some note about this (in case it is easy enough to explain).

The other way would be to install an hotplug script which logs the things. Just create a file called /etc/hotplug.d/net/99-batman-adv-ev. Inside this file you can react to various events from batman-adv. Just from my memory, it should work somewhat like this:

#!/bin/sh

batadv_uev_gw()
{
    case "$BATACTION" in
    add)
        echo "uev gw add $BATDATA"|logger -t batadv
        ;;
    change)
        echo "uev gw change $BATDATA"|logger -t batadv
        ;;
    del)
        echo "uev gw del"|logger -t batadv
        ;;
    esac
}

batadv_uev_bla()
{
    case "$BATACTION" in
    loopdetect)
        echo "uev loopdetect on vid $BATDATA"|logger -t batadv
        ;;
    esac
}

case "$BATTYPE" in
gw)
    batadv_uev_gw
    ;;
bla)
    batadv_uev_bla
    ;;
esac
Actions #11

Updated by Sven Eckelmann almost 4 years ago

  • Description updated (diff)
Actions #12

Updated by Marek Lindner almost 4 years ago

  • Assignee changed from Antonio Quartulli to Matteo Fortini

Hi Matteo,

I am one of the thinkers behind DAT - it sounds a bit odd that DAT would cause loops. DAT only reacts to ARP packets created by non-mesh clients.

To better understand, can you take a packet capture with tcpdump of the looping packets and attach the pcap to this ticket ? This will allow us to understand what packet is looping.

Also, can you explain the simplest possible setup to reproduce this loop ? Meaning: which interfaces can you eliminate and still get the loop ? What type of non-mesh client needs to be connected where ? Or does the loop even begin without any client ?

Thanks,
Marek

Actions

Also available in: Atom PDF