FF3L-AP hinter Fiber7 und Turris Omnia: Wahrscheinlich falsche MTU in /etc/config/fastd - aber warum?

So Aug 27 22:39:36 CEST 2017

Hi,

danke nochmals für den sehr informativen Tag am Freifunk-Camp.

Viele der Hinweise, die ich dort bekam, haben mich ein ganzes Stück
weitergebracht und werde auch noch meinen einen FF3L-AP in Lauchringen
demnächst noch entsprechend "optimieren".

Aber trotz alledem habe ich meinen FF3L-AP in Zürich erst nach
Editieren von /etc/config/fastd zum Laufen gebraucht.

Um überhaupt soweit zu kommen, war ich aber sehr froh über die
Hinweise zur Existenz der erweiterten Konfiguration (den Link hatte
ich einfach bisher übersehen) und, dass ich mir darüber Public-Keys
für SSH-Zugriff eintragen kann. Ab da war Debuggen dann markant
einfacher. :-)

Anyway, ich hatte die folgende Symptome im syslog (via "logread"). In
einer Endlosschleife kamen immer wieder diese Meldungen:

Mon Jul 10 20:02:27 2017 daemon.info fastd[1940]: sending handshake to <mesh_vpn_backbone_peer_vpn6>[178.162.193.197:10000]...
Mon Jul 10 20:02:27 2017 daemon.info fastd[1940]: resolving host `gw6.freifunk-3laendereck.net' for peer <mesh_vpn_backbone_peer_vpn6>...
Mon Jul 10 20:02:27 2017 daemon.info fastd[1940]: resolved host `gw6.freifunk-3laendereck.net' successfully
Mon Jul 10 20:02:32 2017 daemon.info fastd[1940]: sending handshake to <mesh_vpn_backbone_peer_vpn7>[5.9.143.55:10000]...
Mon Jul 10 20:02:32 2017 daemon.info fastd[1940]: resolving host `gw7.freifunk-3laendereck.net' for peer <mesh_vpn_backbone_peer_vpn7>...
Mon Jul 10 20:02:32 2017 daemon.info fastd[1940]: resolved host `gw7.freifunk-3laendereck.net' successfully
Mon Jul 10 20:02:35 2017 daemon.info fastd[1940]: sending handshake to <mesh_vpn_backbone_peer_vpn3>[185.89.196.109:10000]...
Mon Jul 10 20:02:35 2017 daemon.info fastd[1940]: resolving host `gw3.ff3l.net' for peer <mesh_vpn_backbone_peer_vpn3>...
Mon Jul 10 20:02:35 2017 daemon.info fastd[1940]: resolved host `gw3.ff3l.net' successfully
Mon Jul 10 20:02:35 2017 daemon.warn fastd[1940]: Handshake with 185.89.196.109:10000 failed: sending error: MTU configuration differs with peer (local MTU is 1398)
Mon Jul 10 20:02:42 2017 daemon.info fastd[1940]: sending handshake to <mesh_vpn_backbone_peer_vpn9>[144.76.31.247:10000]...
Mon Jul 10 20:02:42 2017 daemon.info fastd[1940]: resolving host `gw9.freifunk-3laendereck.net' for peer <mesh_vpn_backbone_peer_vpn9>...
Mon Jul 10 20:02:42 2017 daemon.info fastd[1940]: resolved host `gw9.freifunk-3laendereck.net' successfully
Mon Jul 10 20:02:45 2017 daemon.info fastd[1940]: sending handshake to <mesh_vpn_backbone_peer_vpn5>[82.197.166.212:10000]...
Mon Jul 10 20:02:45 2017 daemon.info fastd[1940]: resolving host `gw5.freifunk-3laendereck.net' for peer <mesh_vpn_backbone_peer_vpn5>...
Mon Jul 10 20:02:45 2017 daemon.info fastd[1940]: resolved host `gw5.freifunk-3laendereck.net' successfully
Mon Jul 10 20:02:47 2017 daemon.info fastd[1940]: sending handshake to <mesh_vpn_backbone_peer_vpn4>[213.202.233.219:10000]...
Mon Jul 10 20:02:47 2017 daemon.info fastd[1940]: resolving host `gw4.ff3l.net' for peer <mesh_vpn_backbone_peer_vpn4>...
Mon Jul 10 20:02:47 2017 daemon.info fastd[1940]: resolved host `gw4.ff3l.net' successfully
Mon Jul 10 20:02:47 2017 daemon.warn fastd[1940]: Handshake with 213.202.233.219:10000 failed: sending error: MTU configuration differs with peer (local MTU is 1398)

Insbesonders "sending error: MTU configuration differs with peer"
klang schwer nach einer unterschiedlichen Konfiguration zwischen
VPN-Client und -Server.

Und nachdem ich dann in /etc/config/fastd

| config fastd 'mesh_vpn'
|         option mtu '1398'

durch

| config fastd 'mesh_vpn'
|         option mtu '1426'

ersetzt und mit "/etc/init.d/fastd restart" den fastd neugestartet
hatte, fing plötzlich alles an zu funktionieren:

http://map.freifunk-3laendereck.net/#!v:m;n:d46e0ef5c5ac

(Den neuen Wert fand ich sowohl unter "config fastd 'sample_config'"
in der selben Datei als auch auf
https://wiki.freifunk-3laendereck.net/Gateways.)

Hat irgendjemand eine Idee, woran diese Diskrepanz liegen kann? Kann
man diese Situation für zukünftige Ap-Betreiber irgendwie verhindern?

Könnte das ein genereller Fehler in der Firmware sein? Aber dann wäre
ich sicher nicht der erste, der da reinläuft, oder?

Oder könnte es an genau der Kombination liegen, die ich verwende? Ich
habe hier die Kombination diaspora + tl-wr1043n-nd + stable. (Mein
anderer und auf Anhieb funktioniert habender FF3L-AP hat die
Kombination wtk + tl-wr1043n-nd + ipv6 wegen DS-Lite.)

Dass es an Fiber7 liegt, kann ich mir jetzt nicht so richtig
vorstellen.

Und an meinem Turris Omnia habe ich zwar sicher viel verschraubt, aber
sehr sicher nie etwas an der MTU gedreht (und auch bisher keinen Grund
dazu gehabt).

		Gruss, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe at deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe at noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)