Gateway-Debugging

Aus Freifunk München
Wechseln zu: Navigation, Suche

Dieser Artikel richtet sich an Spezialisten, die Zugang zu den Gateways haben.


Sollten die Gateways ereichbar sein, jedoch kein Traffic mehr fließen:[Bearbeiten]

Dies passiert vor allem, wenn die Gateways neu gestartet haben (manuell oder crash).

1. Bridge Interfaces prüfen:

---> brctl show

bridge name	bridge id		STP enabled	interfaces

br-ffmuc		8000.fa8000032342	no		bat-ffmuc
br-umland		8000.fa8001022342	no		bat-umland
br-welcome		8000.fa80ff022342	no		bat-welcome


Dort sollten die Bat-Interfaces der Segemente aufgelistet werden. Fehlen diese, müssen diese hinzugefügt werden:

brctl addif br-ffmuc bat-ffmuc
brctl addif br-welcome bat-welcome
brctl addif br-umland bat-umland


2. Bat-Interfaces prüfen:

isartor:

[root@isartor:~]# batctl -m bat-welcome if
welcome-mesh2: active
welcome-mesh1: active
welcome-mesh0: active
welcome-mesh3: active
welcome-mesh: active
[root@isartor:~]# batctl -m bat-ffmuc if
ffmuc-backbone: active
ffmuc-mesh3: active
ffmuc-mesh2: active
ffmuc-mesh1: active
ffmuc-mesh0: active
ffmuc-mesh: active
[root@isartor:~]# batctl -m bat-welcome if
welcome-mesh2: active
welcome-mesh1: active
welcome-mesh0: active
welcome-mesh3: active
welcome-mesh: active
[root@isartor:~]# batctl -m bat-umland if
umland-mesh0: active
umland-mesh3: active
umland-mesh1: active
umland-mesh4: active
umland-mesh: active


siegestor:

[root@siegestor:~]# batctl -m bat-ffmuc if
ffmuc-mesh12: active
ffmuc-mesh13: active
ffmuc-mesh01: active
ffmuc-mesh03: active
ffmuc-mesh10: active
ffmuc-mesh02: active
ffmuc-mesh: active
[root@siegestor:~]# batctl -m bat-welcome if
welcome-mesh01: active
welcome-mesh11: active
welcome-mesh13: active
welcome-mesh10: active
welcome-mesh12: active
welcome-mesh03: active
welcome-mesh00: active
welcome-mesh: active
[root@siegestor:~]# batctl -m bat-umland if
umland-mesh13: active
umland-mesh01: active
umland-mesh12: active
umland-mesh03: active
umland-mesh02: active
umland-mesh11: active
umland-mesh00: active
umland-mesh10: active
umland-mesh: active


Sollten hier Interfaces fehlen, müssen diese hinzugefügt werden.

ACHTUNG: Hier fehlen oft die Mesh-Interfaces "ffmuc-mesh", "umland-mesh" und "welcome-mesh". Diese sind die richtigen VLAN-Interfaces auf den Gateways, die auf den Switches terminieren und somit die Kommunikation der Gateways untereinander gewährleisten.

batctl -m bat-welcome if add welcome-mesh
batctl -m bat-umland if add umland-mesh
batctl -m bat-ffmuc if add ffmuc-mesh


3. Prüfen der "failed" Services

---> systemctl --failed

Ein Logfile Output bekommt man mit "journalctl -f" bzw "journalctl -xb" . Versuche die Dienste zu starten und prüfe die Logfile.


4. Logfile prüfen auf isartor.ffmuc.net (welches das Routing nach draussen macht)

Die Gateways sind nicht redundant, siegestor leitet Pakete nicht selbst aus, sondern schickt diese an das Isartor. Isartor macht dann das NAT und Routing.


Tauchen im Logfile Meldungen auf wie


Sep 25 14:59:29 isartor kernel: IPv4: martian source 10.80.96.12 from 10.80.98.178, on dev bat-welcome

Sep 25 14:59:29 isartor kernel: ll header: 00000000: ff ff ff ff ff ff b0 e1 7e e4 c6 f7 08 06        ........~.....

Sep 25 14:59:30 isartor kernel: IPv4: martian source 10.80.96.12 from 10.80.104.117, on dev bat-umland

Sep 25 14:59:30 isartor kernel: ll header: 00000000: ff ff ff ff ff ff 60 01 94 2d 88 b1 08 06        ......`..-....

Sep 25 14:59:30 isartor kernel: IPv4: martian source 10.80.32.13 from 10.80.47.168, on dev bat-ffmuc

Sep 25 14:59:30 isartor kernel: ll header: 00000000: fa 80 00 03 23 42 dc 86 d8 20 42 31 08 06        ....#B... B1..


dann gibt es noch ein Problem mit dem Reverse Path Filtering. Dieser muss deaktiviert werden:

echo 0 > /proc/sys/net/ipv4/conf/eno2/rp_filter


5. Bisher konnte das bei den Problemen helfen.


Die Zahl der fastd Verbindungen auf jedem Server pro Mesh-Interface anzeigen lassen:[Bearbeiten]

[root@siegestor:~]# ./list-connections.sh
ffmuc-mesh00.sock
1
ffmuc-mesh01.sock
2
ffmuc-mesh02.sock
5
ffmuc-mesh03.sock
1
ffmuc-mesh10.sock
175
ffmuc-mesh11.sock
95
ffmuc-mesh12.sock
10
ffmuc-mesh13.sock
97
umland-mesh00.sock
0
umland-mesh01.sock
0
umland-mesh02.sock
0
umland-mesh03.sock
0
umland-mesh10.sock
173
umland-mesh11.sock
17
umland-mesh12.sock
161
umland-mesh13.sock
8
welcome-mesh00.sock
1
welcome-mesh01.sock
0
welcome-mesh02.sock
0
welcome-mesh03.sock
0
welcome-mesh10.sock
1
welcome-mesh11.sock
1
welcome-mesh12.sock
0
welcome-mesh13.sock
0
[root@siegestor:~]# 


Auf Grund eines Layer2 Loops steht das Netzwerk:[Bearbeiten]

1. Auf den Gateaways das Logging ansehen:

journalctl -f

Aug 31 12:25:31 isartor kernel: br-ffmuc: received packet on bat-ffmuc with own address as source address (addr:f6:80:00:03:23:42, vlan:0)

Aug 31 12:25:31 isartor kernel: br-ffmuc: received packet on bat-ffmuc with own address as source address (addr:f6:80:00:03:23:42, vlan:0)

Aug 31 12:25:31 isartor kernel: br-ffmuc: received packet on bat-ffmuc with own address as source address (addr:f6:80:00:03:23:42, vlan:0)


2. batctl traceroute machen

root@isartor:~]# batctl -m bat-ffmuc tr f6:80:00:03:23:43
traceroute to f6:80:00:03:23:43 (f6:f3:6d:3f:d8:d6), 50 hops max, 20 byte packets

 1: ba:03:d0:98:b5:c1  0.073 ms  0.179 ms  0.113 ms

2: 02:1d:99:9a:e6:0c  66.189 ms  142.195 ms  135.567 ms
3: f6:f3:6d:3f:e5:a4  153.704 ms  130.385 ms  66.801 ms
4: f6:f3:6d:3f:d8:d6  81.256 ms  81.778 ms   *
[root@isartor:~]#


--> ba:03:d0:98:b5:c1 = siegestor

--> 02:1d:99:9a:e6:0c scheint die stoerende Node zu sein


3. Auf dem Gateway (hier im Beispiel Siegestor-Server) nach schauen: (je nach dem welches segement probleme macht)


cat /sys/kernel/debug/batman_adv/bat-ffmuc/neighbors | grep -i 02:1d:99:9a:e6:0c

ffmuc-mesh10   02:1d:99:9a:e6:0c    7.313s


--> Die MAC ist also via dem Mesh-Interface ffmuc-mesh10 gelernt worden


4. folgendes auf der Shell:

[root@siegestor:~]#  export FASTD_SOCKET=/run/fastd/ffmuc-mesh10.sock

dann

[root@siegestor:~]# /root/fastd-query.sh peers | less

--> https://raw.githubusercontent.com/ffnord/ffnord-puppet-gateway/master/files/usr/local/bin/fastd-query

dort ledglich den Shell/Bash-Pfad anpassen


5. Jetzt im less die MAC suchen. Dort findet man nun die richtige IPv4- oder IPv6-Adresse mit der die fastd Verbindung aufgebaut worden ist.


6. iptables IP sperren, auf beiden Gateways:

[root@siegestor:~]# iptables -I INPUT 1 -s 80.147.225.220 -j DROP