Fragen zu ifupdown2

Moin @Barbarossa ,

ich habe auf deine Empfehlung aus deinem Vortrag in Hennef mal ifupdown2 probiert und hätte da noch ein paar Fragen an dich. Da das vermutlich auch für andere interessant ist, stelle ich die einfach mal hier öffentlich.

  1. Check markiert eth0 als Fehlschlag, vermutlich wegen der Punkt-zu-Punkt-Konfiguration. Ich hab da noch was im Hinterkopf, dass es dafür einen Patch gibt?

    auto eth0
    iface eth0 inet static [fail]
    address 144.76.81.157/32 [fail]

    auto eth0
    iface eth0 inet6 static [pass]
    address 2a01:4f8:192:3c6::bb/64 [pass]

    auto eth0
    iface eth0 inet static
    address 144.76.81.157
    netmask 255.255.255.255
    gateway 144.76.81.199
    pointopoint 144.76.81.199
    pre-up /sbin/ethtool -L eth0 combined 1||:

    iface eth0 inet6 static
    address 2a01:4f8:192:3c6::bb
    gateway 2a01:4f8:192:3c6::2
    netmask 64

  2. Das Loopbackinterface mag er auch nicht:

    auto lo
    iface lo inet loopback [fail]
    address 185.197.132.33/32 [fail]

    auto lo
    iface lo inet loopback
    up ip address add 185.197.132.33/32 dev lo
    up ip rule add from 185.197.132.33/32 table ffnet
    up ip rule add iif lo table ffnet suppress_prefixlength 0
    up ip -6 rule add iif lo table ffnet suppress_prefixlength 0

    Da sehe ich aber eigentlich nichts spezielles drin. Hast du eine Idee, warum er das als Fehlschlag markiert?

  3. Gleiches gilt für den V6-Teil dieser Tunnel hier:
    auto tun-ffnw-fra1
    iface tun-ffnw-fra1 inet static [pass]
    address 100.100.32.1/31 [pass]

    auto tun-ffnw-fra1
    iface tun-ffnw-fra1 inet6 static [fail]
    address fe80::2/64 [fail]

    auto tun-ffnw-fra1
    iface tun-ffnw-fra1 inet static
    address 100.100.32.1
    netmask 255.255.255.254
    pre-up ip tunnel add $IFACE mode gre local 144.76.81.157 remote 89.46.125.8 ttl 255
    post-up ip link set $IFACE mtu 1400
    post-down ip tunnel del $IFACE
    post-up ip rule add iif $IFACE lookup ffnet
    pre-down ip rule del iif $IFACE lookup ffnet ||:
    iface tun-ffnw-fra1 inet6 static
    address fe80::2
    netmask 64
    post-up ip -6 rule add iif $IFACE lookup ffnet
    pre-down ip -6 rule del iif $IFACE lookup ffnet ||:

  4. Ich hab das bisher nur über das fertige Paket ifupdown2_1.0~git20170314-1_all.deb installiert. Ist es dir mal gelungen das aus den Quellen zu bauen? Bei mir wird da immer eine deb erstellt, die fast nichts enthält:

    ~/gits/ifupdown2/deb_dist # dpkg-query -L ifupdown2
    /etc
    /etc/default
    /etc/default/networking
    /etc/network
    /etc/network/ifupdown2
    /etc/network/interfaces.d

Die Einrückung ist leider irgendwie verloren gegangen. Die Interfaces-Dateien an sich sind von der Syntax her aber korrekt, ifupdown(1) kann die starten.

Vielleicht hast du ein paar Tipps für mich :). Wollte erstmal dich fragen, bevor ich die Macher nochmal mit einem Issue nerve. Ansonsten bin ich sehr begeistert davon! Hab ein Interface aktiviert ohne ein Packet zu verlieren (bck-fanlin):

root@corny ~ # traceroute 192.168.1.14
traceroute to 192.168.1.14 (192.168.1.14), 30 hops max, 60 byte packets
 1  192.168.0.14 (192.168.0.14)  0.465 ms  0.468 ms  0.469 ms
 2  192.168.1.14 (192.168.1.14)  9.615 ms  9.583 ms  9.607 ms
root@corny ~ # ping 192.168.1.14
PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data.
64 bytes from 192.168.1.14: icmp_seq=1 ttl=63 time=9.61 ms
64 bytes from 192.168.1.14: icmp_seq=2 ttl=63 time=9.55 ms
64 bytes from 192.168.1.14: icmp_seq=3 ttl=63 time=9.67 ms
64 bytes from 192.168.1.14: icmp_seq=4 ttl=63 time=9.59 ms
64 bytes from 192.168.1.14: icmp_seq=5 ttl=63 time=9.54 ms
64 bytes from 192.168.1.14: icmp_seq=6 ttl=63 time=9.55 ms
64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=9.37 ms
64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=9.16 ms
64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=9.08 ms
64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=9.19 ms
64 bytes from 192.168.1.14: icmp_seq=11 ttl=64 time=9.09 ms
64 bytes from 192.168.1.14: icmp_seq=12 ttl=64 time=9.18 ms
64 bytes from 192.168.1.14: icmp_seq=13 ttl=64 time=9.22 ms
64 bytes from 192.168.1.14: icmp_seq=14 ttl=64 time=9.15 ms
64 bytes from 192.168.1.14: icmp_seq=15 ttl=64 time=9.92 ms
^C
--- 192.168.1.14 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14001ms
rtt min/avg/max/mdev = 9.089/9.394/9.922/0.260 ms
root@corny ~ # traceroute 192.168.1.14
traceroute to 192.168.1.14 (192.168.1.14), 30 hops max, 60 byte packets
 1  192.168.1.14 (192.168.1.14)  9.428 ms  9.398 ms  9.399 ms

Hatte das Interface bck-fanlin erst gelöscht, das sieht man am ersten Traceroute, die Pakete nehmen einen Umweg. Dann wieder einkommentiert und ifreload -a -X eth0 ausgeführt, während der Ping lief. Und dann sieht man am Traceroute, dass es sofort verwendet wird. Auf den anderen Schnittstellen gab es keine Unterbrechung.

Viele Grüße
Matthias

PS: Ich war gerade einfach mal mutig. Er schafft es das Interface eth0 neu zu starten. Vielleicht ist das ein Bug im experimentellen --check-Feature? Und lo scheint auch korrekt nach einem Neustart geladen zu werden. Also ist das wohl nur ein optischer Fehler in der Ausgabe. Glaub ich werde mal einen Bugreport erstellen.

2 „Gefällt mir“

Ola,

Cool, dann dass das jetzt Leute nutzen, dann hat sich der Aufwand der Patches noch mehr gelohnt :slight_smile:

  1. Ja, is’n Bug. Das war addons: address: Fix handling of 'pointopoint' attr. by BarbarossaTM · Pull Request #23 · CumulusNetworks/ifupdown2 · GitHub ist mittlerweile gefixt, dauert aber wohl noch ein bisschen, bis das in ein neues Paket wandert. Das ist mit der Schreibweise mit address + netmask nur Kosmetik. address 1.2.3.4/5 ist ganz kaputt (ohne den PR)

Das ist erwartungskonform. Du setzt die Adresse mit 'nem Up-Befehl, den er nur ausführt, aber nicht weiss, was Du da tust. Warum nicht einfach

auto lo
iface lo
     address 185.197..133.33/32
     up ip rule add from 185.197.132.33/32 table ffnet

?

Ob Policy Routing: Mal über 'ne VRF nachgedacht, in der Du dann ein dummy-interfaces packst, auf dass die IP kommt? Ist safer.

  1. Warum so kompliziert? Das geht selbst mit ifupdown1 schöner :slight_smile:

    auto tun-ffnw-fra1
    iface tun-ffnw-fra1 inet tunnel
    mode gre
    local 144.76.81.157
    endpoint 89.46.125.8
    ttll 255
    mtu 1400
    address 100.100.32.1/31
    address fe80::2/64 ← srsly? Warum kein GUA?
    ## Policy Routing oder VRF oder so…

  2. Ja, ich habe schon einige Pakete selbst gebaut. Das willst Du aus den debian-prep2 Branch machen, nicht dem Master (war zumindest bisher so). Dann tat das auch immer recht schmerzfrei.

HTH & LG
Max

Hallo Max,

danke für deine Antwort :).

zu 1: Werde ich dann hoffentlich los, wenn ich das gebaut bekomme.
zu 2 und 3: Werde ich beides mal ändern, danke für den Tipp. Glaub die Art wie wir GER-Tunnel bauen haben wir seit drei Jahren nicht angefasst oder so. :slight_smile:
zu 4: Hatte die ganzen Zweige gesehen, wollte aber auch nicht alle durchprobieren. Werde das dann mal mit den debian-prep2 probieren.

Nachgedacht ja, finde ich generell auch interessant und gut. Ich will auch dieses verbuggte suppress_prefixlength loswerden, was wir überall drin haben. Aber noch nicht dazu gekommen.

Grüße
Matthias

@Barbarossa, auch mit dem Zweig „debian-prep2“ kommt bei mir irgendwie nicht das richtige raus. Ich hab dann kein ifreload und ifquery versteht die Option --check nicht. Entweder ist das eine ältere Version oder er greift auf irgendwas aus dem Betriebssystem zurück.

Hast du da noch irgendwas konfiguriert oder wie baust du das?

python-ifupdown2.zip (121,8 KB)

@Barbarossa, gibt es hier eine äquivalente Syntax für Gretap? Mode gretap will irgendwie nicht klappen.

gretap hat bisher auch keine implementiert. Auf den ersten Blick unterscheidet sich das im wesentlichen nicht von GRE.

Du könntest mal ausprobieren, wie laut es knallt, wenn Du in /usr/share/ifupdown2/addons/tunnel.py mal

'validvals' : ['gre' 'ipip', 'sit'],

noch gretap mit aufnimmst. ifquery wird dann natürlich nicht glücklich sein, aber es hat 'ne Chance den Tunnel aufzubauen.

LG
Max

Werde ich probieren, dafür muss ich es aber erst gebaut bekommen. Siehe oben. Schaffe es einfach nicht, das zu bauen. Kannst du mal die Befehle Schritt für Schritt einmal hier reinkopieren?

Kann ifupdown1 gretap?

git clone …
git checkout debian-prep2
dpkg-buildpackage -us -uc -rfakeroot -b

Tut hier, just mit der neusten Version (+ Patches für die 3 offenen PRs) getestet. Das Paket scheint auch zu funktionieren.

ich nehme an, dass ifupdown1 das kann. Lese er Doku oder Source zur Verifikation.

Ciao
Max

1 „Gefällt mir“

Das erklärt einiges. Muss man auch erstmal drauf kommen, dass das mitgelieferte build-Skript eine falsche Fährte ist und nicht dafür gedacht ist zu funktionieren :wink: . Klappt jetzt. Danke.

Nach dem ifupdown1-gretap habe ich schon gegoogelt, dazu findet man genau gar nichts. Ich werde mal schauen, ob ich eine nicht indizierte Doku oder mich im Quelltext zurecht finde.

PS: Mal den Quellcode von ifupdown1 durchwühlt:

$~/Downloads/ifupdown-e45cc73e740e$ grep -ri 'gretap' *
$~/Downloads/ifupdown-e45cc73e740e$ grep -ri 'gre' *
BUGS:     * #158089: GRE and IPIP tunnel support
BUGS:     * #229503: Please add Greek debconf translation (attached)
BUGS:     * #229527: Please add Greek debconf translation (attached)
contrib/ifstate:if ifconfig "$iface" | grep -Fw UP >/dev/null
COPYING:In addition, mere aggregation of another work not based on the Program
COPYING:conditions are imposed on you (whether by court order, agreement or
COPYING:  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
COPYING:  If you develop a new program, and you want it to be of the greatest
debian/preinst:if [ -f /etc/network/interfaces ] && ! grep -q '^[^#]' /etc/network/interfaces
debian/rules:export VERSION := $(shell dpkg-parsechangelog|grep Version|cut -d' ' -f2|sed s/.*really//g)
debian/changelog:  * Add GRE and IPIP tunnels support (Closes: #158089).
debian/changelog:      + Added Greek debconf translation provided by Konstantinos Margaritis.
debian/changelog:    + minor phrasing changes aiming at greater clarity  
debian/changelog:    + Priority: important to agree with override file
debian/postinst:      if sed -e '/^[[:space:]]*#/b;:g /\\$/{N;s/\\\n//;bg;}' /etc/network/interfaces | grep -qe "^[[:space:]]*iface[[:space:]]*\\b${iface}\\b[[:space:]]*.*\\bdhcp\\b.*" &&
defn2c.pl:                                die "Duplicate option use: $newoption (from $method/$option)" if (grep $_ eq $newoption, @variables);
examples/network-interfaces:# with a great deal of care.)
inet.defn:    This method is used to create GRE or IPIP tunnels. You need to have
inet.defn:    the *ip* binary from the *iproute* package. For GRE tunnels, you
inet.defn:    will need to load the ip_gre module and the ipip module for
inet.defn:    mode type             -- Tunnel type (either GRE or IPIP) *required*

Außerdem steht in der inet.defn auch irgendwo im Quelltext folgendes:

method tunnel
  description
    This method is used to create GRE or IPIP tunnels. You need to have
    the *ip* binary from the *iproute* package. For GRE tunnels, you
    will need to load the ip_gre module and the ipip module for
    IPIP tunnels.
  options
    address address       -- Local address (dotted quad) *required*
    mode type             -- Tunnel type (either GRE or IPIP) *required*
    endpoint address      -- Address of other tunnel endpoint *required*
    dstaddr address       -- Remote address (remote address inside tunnel)
    local address         -- Address of the local endpoint
    gateway address       -- Default gateway
    ttl time              -- TTL setting
    mtu size              -- MTU size

Gre scheint also nur für V4 in ifupdown drin zu sein. Und Gretap gar nicht, denn address ist ein erforderliches Feld. Ein L2-Tunnel hat aber keine Adresse. Das ganze ruft dann aber auch einfach ip tunnel auf.

Ich werde die Tage mal probieren, ob ifupdown2 es schöner hinbekommt.

Ich hab mal eine Ansible-Rolle geschrieben, die ifupdown2 installiert: https://github.com/FreiFunkMuenster/Ansible-Freifunk-Gateway/blob/master/ifupdown2/tasks/main.yml

Moin!

Wo mir das hier gerade nochmal unter die Nase kam:

GRETAP-Support gibt’s seit dem #Hacktoberfest übrigens auch :wink:

https://github.com/CumulusNetworks/ifupdown2/pull/34

LG
Max

3 „Gefällt mir“

Moin,

habe das gerade mal probiert. Ifupdown2 ist neu vom Git aus gebaut und dort ist dein Commit auch im Verlauf.

Allerdings kriegt ifupdown2 den Tunnel nicht gestartet:

root@corny2 ~/gits/ifupdown2 # ifup -v t01-karte
info: loading builtin modules from /usr/share/ifupdown2/addons
info: executing /bin/pidof mstpd
info: executing /sbin/ip rule show
info: executing /sbin/ip -6 rule show
info: looking for user scripts under /etc/network
info: loading scripts under /etc/network/if-pre-up.d ...
info: loading scripts under /etc/network/if-up.d ...
info: loading scripts under /etc/network/if-post-up.d ...
info: loading scripts under /etc/network/if-pre-down.d ...
info: loading scripts under /etc/network/if-down.d ...
info: loading scripts under /etc/network/if-post-down.d ...
info: processing interfaces file /etc/network/interfaces
info: processing interfaces file /etc/network/interfaces.d/40_gre_upstream.cfg
info: processing interfaces file /etc/network/interfaces.d/10_batman.cfg
info: processing interfaces file /etc/network/interfaces.d/00_lo.cfg
info: processing interfaces file /etc/network/interfaces.d/42_gre_interbackbone.cfg
info: processing interfaces file /etc/network/interfaces.d/20_l2tp_bridge.cfg
info: processing interfaces file /etc/network/interfaces.d/30_gretap.cfg
info: t01-karte: running ops ...
info: executing ip -o -d link show dev t01-karte
info: executing ip tunnel add t01-karte mode gretap local 144.76.81.139 remote 46.4.80.190
warning: cmd 'ip tunnel add t01-karte mode gretap local 144.76.81.139 remote 46.4.80.190' failed: returned 255 (Unknown tunnel mode "gretap"
)
info: executing ip -o -d link show dev t01-karte
info: executing /etc/network/if-up.d/openssh-server
info: executing /etc/network/if-up.d/upstart
info: executing /etc/network/if-up.d/bind9
info: executing /etc/network/if-up.d/mountnfs
info: executing batctl -m bat01 if add t01-karte ||:
info: running upperifaces (parent interfaces) if available ..
root@corny2 ~/gits/ifupdown2 # ip a s t01-karte
Device "t01-karte" does not exist.

Die Konfiguration sieht so aus:

auto t01-karte
iface t01-karte inet tunnel
	mode gretap
	local 144.76.81.139
	endpoint 46.4.80.190
	hwaddress ether de:ad:be:ef:1:14
	key 1
        post-up batctl -m bat01 if add $IFACE ||:
        pre-down batctl -m bat01 if del $IFACE ||:

Hast du 'nen Tipp für mich, @Barbarossa?

Viele Grüße
Matthias

PS: Braucht das einen bestimmten Kernel? Wir haben derzeit 4.9.0.0.bpo.3 drauf (wegen des Tunneldiggerproblems)

PPS: Ich sehe gerade auch, dass er probiert, das Interface mit ip tunnel zu starten. Gretap geht aber über ip link. Demnach dürfte das nie funktioniert haben, es sei denn du hast irgendwie einen Alias bei dir im System?

PPPS: Der Befehl müsste lauten:

ip link add t01-karte type gretap local 144.76.81.139 remote 46.4.80.190

Aber komisch ist auch, dass ifquery direkt failed, also er sich schon an der Syntax in der Konfigurationsdatei stört.

Hi @MPW

ich hatte die Tage auch angefangen ifupdown2 mehr zu verwenden und es scheint in Bug in ifupdown2 zu sein weshalb der gretap Tunnel nicht erstellt wird. Ich habe dafür bereits einen Issue aufgemacht gretap tunnel cann’t be created

1 „Gefällt mir“

Hi Jungs,

ja, da hat wohl jemand mein Addon kaputtgepatched. Ich habe schon herausgefunden wo es bricht, die Frage ist jetzt, wie man das am geschicktesten heile macht.

LG
Max

1 „Gefällt mir“

Das ist jetzt gefixt:

LG
Max

3 „Gefällt mir“

Cool danke.

Viele Grüße
Matthias