Project

General

Profile

Actions
Copy link

Bug #409

open

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

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

Status:
In Progress
Priority:
Normal
Assignee:
Matteo Fortini
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 open — 1 closed)

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

Actions
Actions
Copy link
 #1

Updated by Sven Eckelmann over 4 years ago

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

Updated by Sven Eckelmann over 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
Copy link
 #3

Updated by Sven Eckelmann over 4 years ago

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

Updated by Matteo Fortini over 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
Copy link
 #5

Updated by Matteo Fortini over 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
Copy link
 #6

Updated by Matteo Fortini over 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
Copy link
 #7

Updated by Matteo Fortini over 4 years ago

The packets seem to be ARP requests.

(I have DAT enabled)

logread...

tcpdump...

Actions
Copy link
 #8

Updated by Matteo Fortini over 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
Copy link
 #9

Updated by Sven Eckelmann over 4 years ago

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

Updated by Sven Eckelmann over 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
Copy link
 #11

Updated by Sven Eckelmann over 4 years ago

  • Description updated (diff)
Actions
Copy link
 #12

Updated by Marek Lindner over 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
Copy link

Also available in: Atom PDF