Ich denke, dass die Frage darauf abzielte, die Zahl der Fastd-Tunnel „pro Plasterouter“ von zwei auf einen zu reduzieren.
Wobei das bei den Klein-Domainen von Wupper nicht das Problem ist.
Da habe ich es doch missverstanden, da bei Batman für mich alles ein Knoten ist. Die Freifunkknoten haben alle zwei Tunnel. Wenn ich den oben erwähnten Begrenzer auf den Superknoten implementiere, gibt es nur noch einen. Die Superknoten stürzen nur ab, wenn solche Experimente durchgeführt werden, ansonsten äußerst selten (4-32 Wochen).
Hier wurde Batman 2015.1 und 2015.1-89-g425ba69 verwendet und mit diesen Einstellungen kompiliert:
CONFIG_BATMAN_ADV=m
CONFIG_BATMAN_ADV_DEBUG=n
CONFIG_BATMAN_ADV_BLA=y
CONFIG_BATMAN_ADV_DAT=y
CONFIG_BATMAN_ADV_NC=n
CONFIG_BATMAN_ADV_MCAST=y
wie gesagt, es gibt Kerneldumps für die Entwickler geben. Rechnet damit, dass ein GW spontan ausfällt. Die Wolke sollte dies abfangen können und für die Nutzer bestünde nur kurzfristig ein Ausfall. Ich sage aber Bescheid, wenn dies so weit ist.
Also wir nutzen L2TP jetzt schon seit einem Monat als Backbone, keine Probleme. Weder mehr crashes als üblich noch irgendwelche Performance Probleme.
Das L2TP Links zu den Nodes nicht als VPN dargestellt werden liegt ganz einfach da dran das die falsche MAC auf den Interfaces verwendet wird. Dies muss die gleiche MAC wie beim Fastd Interface sein.
Damit man die MAC ändern kann ist es wichtig das ein aktueller Linux Kernel verwendet wird, in Düsseldorf haben wir für Debian 8 den Backports Kernel in verwendung, basiert auf Linux 4.1. Vorher ist es nicht möglich die MAC zu ändern da das L2TP Kernel Module einen Patch dafür benötigt.
Natürlich könnte man dies auch manuell Patchen, aber das ist Bastelei. Wenn dann sollte man bis auf 1-2 Ausnahmen nur fertig Pakete verwenden.
Edit:
Wir können nicht einen L2TP-Tunnel pro Node fahren
Bei L2TP hat man generell pro Link nur einen Tunnel, dies hat einige Vorteile. Z.b. kann man Rebroadcasting in beide Richtung abschalten, das spart wieder Bandbreite auf dem VPN Link.
Was die Verwendung von Tunneldigger angeht: Bis jetzt haben wir dadurch nicht mehr oder weniger Crashes.
Hallo Linus, danke für die Rückmeldung
Mit dieser Aussage kann ich nichts anfangen und es ergeben sich weitere Fragen: welche Batman-Kompatibilitätsversion? (14? 15?) Wird batman an mehrere Schnittstellen angebunden oder nur über ein Bridge-Interface? Wird in eurem Setup L2TP und fastd gleichzeitig verwendet? Wie viele batman-Instanzen gibt es in eurem Setup gleichzeitig? Bei Wupper sind es derzeit 11, bzw 9 im Livebetrieb. Wie viele Server werden verwendet? Bei was für einer Load werden sie gefahren? Wie viele Nutzer, Originators, Pakete/s … Wie Du siehst kann man das so nicht einfach vergleichen … Ich habe bereits die Grenzen des Zumutbaren bei Wupper gepostet. Warum das bei uns crasht und bei Euch nicht, wird ein Kerneldump zeigen.
Es war in diesem Versuchsaufbau Absicht die L2TP-Links nicht als VPN darzustellen. Darüber hinaus kann man via Alfred dem Meshviewer die richtigen MACs bekanntgeben oder die Richtigen MACs direkt dort eintragen …
Das ist mir noch nicht aufgefallen, da ich noch keinen Grund hatte die MAC in diesem Versuch ändern zu müssen. Ich werde mich beim nächsten Mal davon überzeugen. Danke für die Information. Abgesehen davon wird eh die MAC der batman-Hauptschnittstelle als Knotenidentifizierer verwendet. Weitere MACs des Knotens werden dem Knoten und dieser Haupt-MAC zugerechnet. Diese MAC wird bereits durch die richtig konfigurierte fastd-Schnittstelle vorgegeben, derer Verbindungen bereits richtig als VPN-Verbindungen im Meshviewer angezeigt werden.
Mir ist Debian ehrlich gesagt ein Dorn im Auge. Ich verwende es aber, weil es so vom Verein bereitgestellt wird um einen Superknoten zu Fahren. Wenn ich am Basissystem noch heftige Abweichungen vom Basissystem vornehmen muss, damit es „State of the Art“ wird, dann nehme ich wohl doch lieber Arch oder Gentoo.
Wie gesagt, dies war ein Versuch den Intersuperknotendatenverkehr unverschlüsselt durch L2TP zu jagen statt verschlüsselt durch fastd, um die Server zu entlasten. An der bisherigen Anbindung der Knoten hat sich nichts geändert. Es wurde zwischen w0 und w3 ein L2TP-Tunnel mit 11 Sessions aufgebaut (je eine für eine Broadcastdomäne). Jede Session hatte die MTU, wie der für diese Broadcastdomäne verwendete fastd-Tunnel. Das ging schief. Genau so schief, wie unverschlüsselte fastd-Tunnel zwischen den Superknoten. Die Antwort, warum es schief ging, werden Kerneldumps beantworten, wenn ich wieder Zeit für diesen und weitere Versuche habe.
1 „Gefällt mir“
Also wir verwenden Bat15 und haben momentan ein bat Interface. Mehrere werden wir wohl erst bekommen wenn wir Ddorf noch mal Splitten.
Momentan hängen in bat0 die folgenden Schnittstellen:
l2tp20001: active
l2tp1221: active
l2tp1211: active
l2tp1201: active
tap-fluxent: active
tap0: active
bb-map: active
bb-ddorf2: active
supernode: active
Bei dem Interface „supernode“ handelt es sich um ein Dummy Interface welches wir verwenden damit wir alle Interfaces und Dienste ohne race condition starten können.
Die l2tp* Interfaces sind von Tunneldigger und bb-map sowie bb-ddorf2 sind die L2TP Links zum Map Server sowie zweiten Supernode.
Der Load beträgt momentan 0.6 - 1.0 , am meisten schlägt dabei SoftIRQ aufs Gewicht, Fastd wird aber nach und nach entfernt bis auf eine Instanz mit bis zu 30 Clients. Wir wollen nur noch L2TP verwenden da der Verlust von Leistung in dem Maße wie er mit Fastd stattfindet nicht tragbar ist.
Was die Werte aus dem anderen Thread angeht den du verlinkt hast:
- Server: Insgesammt 3 (inkl. Map)
- Gateways: 2
- Nodes: Etwa 180
- Nutzer / Clients: Etwa 1000
- Summe aus echo $[$(batctl transglobal | wc -l)-2] pro Broadcastdomäne
→ 806 - vnstat -tr -i eth0
→ Sollte im monitoring unter https://grafana.lambdacore.de/dashboard/db/supernodes-dusseldorf ersichtlich sein. (Aber auf jedenfall unter 10kpps)
Es war in diesem Versuchsaufbau Absicht die L2TP-Links nicht als VPN darzustellen. Darüber hinaus kann man via Alfred dem Meshviewer die richtigen MACs bekanntgeben oder die Richtigen MACs direkt dort eintragen …
Naja nicht ganz, die Macs sind nicht fest. Die Ändern sich bei jedem Reboot 
Das Problem hatten wir auch, daher ist der Patch notwendig, es sei denn du möchtest jedes mal die Liste der Macs mit dem Map Server synchronisieren.
Mir ist Debian ehrlich gesagt ein Dorn im Auge. Ich verwende es aber, weil es so vom Verein bereitgestellt wird um einen Superknoten zu Fahren. Wenn ich am Basissystem noch heftige Abweichungen vom Basissystem vornehmen muss, damit es „State of the Art“ wird, dann nehme ich wohl doch lieber Arch oder Gentoo.
Also Gentoo sowie Arch sind für Freifunk eher ungeeignet. Gentoo sowie Arch sind nicht als Stable zu bezeichnen da sich jeder Build unterschiedlich verhalten kann. Bei Setups die man ordentlich skalieren können möchte sollte man niemals ein Rolling Release basiertes System nutzen 
Software die heute noch funktioniert kann bei einem neuem Setup schlecht bis gar nicht funktioneren. Aber das schweift etwas vom Thema ab.
Alternativ könnt ihr auch GRE verwenden, allerdings habe ich damit nicht so gute Erfahrungen auf der Vereinshardware gemacht, teilweise hatten wir nur eine Link Quality von 5-10 (von max. 255)
Ansonsten würde ich empfehlen den Kernel mal zu updaten, der Backports Kernel funktioniert recht gut.
Ich kann auch gerne Config Beispiele posten.
Danke Linus für die Tipps. Es scheint ein wenig stabiler zu laufen, dennoch ist Batman der domäne Wupper nicht gewachsen: w0 mit w3 verbunden ergab einen Crash, denn ich noch nie gesehen habe: nicht ein mal ein Crash-Report erschien in der Konsole, nur ein Anmeldebildschirm mit einem nicht blinkenden Cursor verblieb …
Heutiger Test::
w0
^
|
w2 -> w5 <- w3
w5 ist ein mit 100 MBit/s ans Internet angeschlossener vServer bei einem bekannten Hoster. Dieser wurde zum Sternpunkt gewählt, um zu testen, ob es an der Irren Geschwindigkeit liegt, so dass Batman sich verschluckt.
dmesg liefert zwischendurch Schreckensmeldungen:
# wupper0
[ 1116.146157] BUG: unable to handle kernel paging request at 0000000002003512
[ 1116.146474] IP: [<0000000002003512>] 0x2003512
[ 1116.146567] PGD 1d2067 PUD 1dd067 PMD 0
[ 1116.146646] Oops: 0010 [#1] SMP
[ 1116.146711] Modules linked in: l2tp_eth l2tp_netlink l2tp_core xt_TCPMSS xt_tcpudp xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 batman_adv(O) nf_nat_ipv4 nf_nat libcrc32c nf_conntrack tun xt_multiport iptable_filter ip_tables x_tables mptctl nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc ip_gre ip_tunnel gre crc32_pclmul ghash_clmulni_intel evdev ppdev aesni_intel psmouse serio_raw pcspkr aes_x86_64 lrw vmw_balloon gf128mul glue_helper ablk_helper cryptd vmwgfx ttm drm_kms_helper shpchp vmw_vmci drm i2c_piix4 i2c_core battery processor thermal_sys parport_pc parport ac button loop autofs4 ext4 crc16 mbcache jbd2 sg sd_mod crc_t10dif crct10dif_generic sr_mod cdrom ata_generic crct10dif_pclmul crct10dif_common crc32c_intel e1000 mptspi scsi_transport_spi mptscsih mptbase floppy
[ 1116.148139] ata_piix libata scsi_mod
[ 1116.148201] CPU: 1 PID: 1674 Comm: alfred Tainted: G O 3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u6
[ 1116.148388] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/14/2014
[ 1116.148572] task: ffff88003bd863d0 ti: ffff88003bf7c000 task.ti: ffff88003bf7c000
[ 1116.148887] RIP: 0010:[<0000000002003512>] [<0000000002003512>] 0x2003512
[ 1116.149116] RSP: 0018:ffff88003bf7feb8 EFLAGS: 00010286
[ 1116.149358] RAX: ffff8800315effc0 RBX: 0000000000000000 RCX: 0000000000000000
[ 1116.149585] RDX: ffff88003bf7ffd8 RSI: ffff88003bf7fed8 RDI: ffff88003ba20a00
[ 1116.149812] RBP: ffff88003b2ccc00 R08: ffff88003bf7c000 R09: 000000000000b8ae
[ 1116.150042] R10: 0000000000004230 R11: 0000000000000104 R12: 0000000000001000
[ 1116.150270] R13: ffff88003bf7ff58 R14: 0000000000000001 R15: ffff88003ba20a00
[ 1116.150500] FS: 00007fb84c044700(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000
[ 1116.150823] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1116.151013] CR2: 0000000002003512 CR3: 000000003b29e000 CR4: 00000000000407e0
[ 1116.151283] Stack:
[ 1116.151417] ffffffff811c98e0 ffff88003ba20a40 00007fb84c041000 ffff88003b2ccc00
[ 1116.151729] 0000000000000000 0000000000001000 ffff88003b2ccc00 00007fb84c041000
[ 1116.152042] ffff88003bf7ff58 0000000000001000 0000000000000000 00000000fbad2488
[ 1116.152356] Call Trace:
[ 1116.152539] [<ffffffff811c98e0>] ? seq_read+0x160/0x360
[ 1116.152717] [<ffffffff811a8083>] ? vfs_read+0x93/0x170
[ 1116.152890] [<ffffffff811a8cb2>] ? SyS_read+0x42/0xa0
[ 1116.153103] [<ffffffff815116cd>] ? system_call_fast_compare_end+0x10/0x15
[ 1116.153319] Code: Bad RIP value.
[ 1116.153468] RIP [<0000000002003512>] 0x2003512
[ 1116.153629] RSP <ffff88003bf7feb8>
[ 1116.153780] CR2: 0000000002003512
[ 1116.154468] ---[ end trace e4139d4f0e44b3ca ]---
# wupper5
[Sun Nov 15 00:06:09 2015] ------------[ cut here ]------------
[Sun Nov 15 00:06:09 2015] WARNING: CPU: 0 PID: 6 at /home/zumbi/linux-4.2.5/net/core/skbuff.c:4174 skb_try_coalesce+0x40b/0x440()
[Sun Nov 15 00:06:09 2015] Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink l2tp_eth l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel batman_adv libcrc32c tun nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc iosf_mbi crct10dif_pclmul crc32_pclmul jitterentropy_rng sha256_ssse3 sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 lrw gf128mul ppdev glue_helper ablk_helper cryptd ttm joydev drm_kms_helper drm psmouse pcspkr evdev serio_raw acpi_cpufreq virtio_balloon processor parport_pc thermal_sys i2c_piix4 parport 8250_fintek button loop autofs4 hid_generic usbhid hid ext4 crc16 mbcache jbd2 sg sr_mod cdrom ata_generic virtio_blk virtio_net crc32c_intel ata_piix floppy uhci_hcd ehci_hcd libata scsi_mod virtio_pci virtio_ring virtio usbcore usb_common
[Sun Nov 15 00:06:09 2015] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 4.2.0-0.bpo.1-amd64 #1 Debian 4.2.5-1~bpo8+1
[Sun Nov 15 00:06:09 2015] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[Sun Nov 15 00:06:09 2015] Workqueue: bat_events batadv_purge_orig [batman_adv]
[Sun Nov 15 00:06:09 2015] 0000000000000000 ffffffff81851d58 ffffffff81552eb1 0000000000000000
[Sun Nov 15 00:06:09 2015] ffffffff8106fa01 ffff88011a725d00 ffff8800da921b00 000000000000043a
[Sun Nov 15 00:06:09 2015] ffff88011fc03ca8 0000000000000400 ffffffff814551eb 0000000000000020
[Sun Nov 15 00:06:09 2015] Call Trace:
[Sun Nov 15 00:06:09 2015] <IRQ> [<ffffffff81552eb1>] ? dump_stack+0x40/0x50
[Sun Nov 15 00:06:09 2015] [<ffffffff8106fa01>] ? warn_slowpath_common+0x81/0xb0
[Sun Nov 15 00:06:09 2015] [<ffffffff814551eb>] ? skb_try_coalesce+0x40b/0x440
[Sun Nov 15 00:06:09 2015] [<ffffffff815282c5>] ? ipv6_frag_rcv+0x665/0xd60
[Sun Nov 15 00:06:09 2015] [<ffffffff81480206>] ? fib_rules_lookup+0xf6/0x150
[Sun Nov 15 00:06:09 2015] [<ffffffff815046f5>] ? ip6_input_finish+0x65/0x410
[Sun Nov 15 00:06:09 2015] [<ffffffff81504f80>] ? ip6_input+0x20/0x80
[Sun Nov 15 00:06:09 2015] [<ffffffff8150466c>] ? ip6_rcv_finish+0x8c/0xb0
[Sun Nov 15 00:06:09 2015] [<ffffffff81504d8c>] ? ipv6_rcv+0x2ec/0x4c0
[Sun Nov 15 00:06:09 2015] [<ffffffff814634c1>] ? __netif_receive_skb_core+0x841/0x9a0
[Sun Nov 15 00:06:09 2015] [<ffffffff814e0001>] ? fib_table_insert+0x251/0x490
[Sun Nov 15 00:06:09 2015] [<ffffffff814642b1>] ? process_backlog+0xa1/0x140
[Sun Nov 15 00:06:09 2015] [<ffffffff81463b4a>] ? net_rx_action+0x20a/0x320
[Sun Nov 15 00:06:09 2015] [<ffffffff81073aa7>] ? __do_softirq+0x107/0x270
[Sun Nov 15 00:06:09 2015] [<ffffffff8155a21c>] ? do_softirq_own_stack+0x1c/0x30
[Sun Nov 15 00:06:09 2015] <EOI> [<ffffffff810733d3>] ? do_softirq.part.20+0x33/0x40
[Sun Nov 15 00:06:09 2015] [<ffffffff81073466>] ? __local_bh_enable_ip+0x86/0x90
[Sun Nov 15 00:06:09 2015] [<ffffffffa055337f>] ? _batadv_purge_orig+0x41f/0x4b0 [batman_adv]
[Sun Nov 15 00:06:09 2015] [<ffffffff810cfdc5>] ? add_timer_on+0x75/0xe0
[Sun Nov 15 00:06:09 2015] [<ffffffffa0553425>] ? batadv_purge_orig+0x15/0x30 [batman_adv]
[Sun Nov 15 00:06:09 2015] [<ffffffff8108672a>] ? process_one_work+0x14a/0x3d0
[Sun Nov 15 00:06:09 2015] [<ffffffff81087115>] ? worker_thread+0x65/0x470
[Sun Nov 15 00:06:09 2015] [<ffffffff810870b0>] ? rescuer_thread+0x2f0/0x2f0
[Sun Nov 15 00:06:09 2015] [<ffffffff8108c593>] ? kthread+0xd3/0xf0
[Sun Nov 15 00:06:09 2015] [<ffffffff8108c4c0>] ? kthread_create_on_node+0x170/0x170
[Sun Nov 15 00:06:09 2015] [<ffffffff81558b1f>] ? ret_from_fork+0x3f/0x70
[Sun Nov 15 00:06:09 2015] [<ffffffff8108c4c0>] ? kthread_create_on_node+0x170/0x170
[Sun Nov 15 00:06:09 2015] ---[ end trace 149dd0fd139b6134 ]---
normalerweise stürzt Batman bei so etwas ab und liefert Kernel Panic auf der Konsole. Jetzt friert alles einfach ein.
4.2.0-0.bpo.1-amd64
mitgelieferter batman-adv: 2015.1
edit, sehe gerade w0 hat sich doch noch den alten Kernel geschnappt
Nurmalso am Rande: Du/Ihr setzt auf VMWare, wir z. B. auf langweiliges KVM. Eine Überlegung wert?
Ich verstehe nicht, worauf Du hinaus willst. Kannst Du mir bitte einen Gedankenschubs liefern? Bei der Auswahl der Virtualisierung habe ich im Übrigen nichts zu sagen und nehme dankbar was ich bekomme und mache das Beste daraus.
Es ist zum Mäusemelken …
# w3
[So Nov 15 03:52:42 2015] general protection fault: 0000 [#1] SMP
[So Nov 15 03:52:42 2015] Modules linked in: l2tp_eth l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel xt_TCPMSS xt_tcpudp xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack tun batman_adv(O) libcrc32c xt_multiport iptable_filter ip_tables x_tables mptctl nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc ip_gre ip_tunnel gre crct10dif_pclmul crc32_pclmul sha256_ssse3 sha256_generic hmac drbg ansi_cprng ppdev aesni_intel aes_x86_64 lrw gf128mul evdev psmouse glue_helper serio_raw ablk_helper vmw_balloon cryptd pcspkr vmwgfx ttm drm_kms_helper drm parport_pc i2c_piix4 8250_fintek acpi_cpufreq parport vmw_vmci processor battery shpchp thermal_sys ac button loop autofs4 ext4 crc16 mbcache jbd2 sd_mod sg sr_mod cdrom ata_generic crc32c_intel ata_piix mptspi scsi_transport_spi
[So Nov 15 03:52:42 2015] mptscsih libata mptbase e1000 scsi_mod floppy
[So Nov 15 03:52:42 2015] CPU: 0 PID: 1775 Comm: alfred Tainted: G O 4.2.0-0.bpo.1-amd64 #1 Debian 4.2.5-1~bpo8+1
[So Nov 15 03:52:42 2015] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/14/2014
[So Nov 15 03:52:42 2015] task: ffff88003c818140 ti: ffff88003c750000 task.ti: ffff88003c750000
[So Nov 15 03:52:42 2015] RIP: 0010:[<ffffffff811e1c7a>] [<ffffffff811e1c7a>] seq_read+0xfa/0x380
[So Nov 15 03:52:42 2015] RSP: 0018:ffff88003c753e68 EFLAGS: 00010246
[So Nov 15 03:52:42 2015] RAX: ffff8800001fe280 RBX: 0000000000000000 RCX: ffff88003c699260
[So Nov 15 03:52:42 2015] RDX: ffff88003c753d60 RSI: 0000000000000001 RDI: ffff88003cba64c0
[So Nov 15 03:52:42 2015] RBP: ffff88003c753f20 R08: 0000000000002000 R09: 000000000000000e
[So Nov 15 03:52:42 2015] R10: 00000000ffffffff R11: ffff88003c9bd400 R12: ffff8800315cbf00
[So Nov 15 03:52:42 2015] R13: ffff88003cba6500 R14: 0000000000000001 R15: ffff88003cba64c0
[So Nov 15 03:52:42 2015] FS: 00007f627cba6700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[So Nov 15 03:52:42 2015] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[So Nov 15 03:52:42 2015] CR2: 00007fd45eb60008 CR3: 000000003c4c5000 CR4: 00000000000406f0
[So Nov 15 03:52:42 2015] Stack:
[So Nov 15 03:52:42 2015] 0000000000000000 0000000000001000 00007f627cbac000 0000000000001000
[So Nov 15 03:52:42 2015] 0000000000000000 ffff88003c753f20 0000000000001000 00007f627cbac000
[So Nov 15 03:52:42 2015] ffff8800315cbf00 ffff88003c753f20 0000000000001000 0000000000000000
[So Nov 15 03:52:42 2015] Call Trace:
[So Nov 15 03:52:42 2015] [<ffffffff811bfac1>] ? vfs_read+0x81/0x120
[So Nov 15 03:52:42 2015] [<ffffffff811c0822>] ? SyS_read+0x42/0xa0
[So Nov 15 03:52:42 2015] [<ffffffff815586f2>] ? system_call_fast_compare_end+0xc/0x6b
[So Nov 15 03:52:42 2015] Code: 8e 00 00 00 0f 85 02 01 00 00 49 8b 47 18 48 85 c0 0f 84 fd 00 00 00 49 3b 47 08 0f 82 84 01 00 00 49 8b 47 68 4c 89 f6 4c 89 ff <ff> 50 08 49 8b 3f e8 7b e7 f8 ff 49 8b 47 08 49 c7 47 18 00 00
[So Nov 15 03:52:42 2015] RIP [<ffffffff811e1c7a>] seq_read+0xfa/0x380
[So Nov 15 03:52:42 2015] RSP <ffff88003c753e68>
[So Nov 15 03:52:42 2015] ---[ end trace 0f00bcffdf09bec7 ]---
die Tunnel werden im Übrigen so initialisiert:
ip l2tp add tunnel \
remote ${remoteip} local ${IP4} \
tunnel_id 100${i} peer_tunnel_id 100${NR} \
encap udp \
udp_sport 3000${i} udp_dport 3000${NR}
ip l2tp add session \
name l2-${LOC}-${i} \
tunnel_id 100${i} session_id 1${i}${LOCn} \
peer_session_id 1${NR}${LOCn}
ip link set l2-${LOC}-${i} up mtu ${MTU}
sysctl -w net.ipv6.conf.l2-${LOC}-${i}.disable_ipv6=1Nach einer Nacht voller Fehlschläge meine ich das Problem identifiziert zu haben: es handelt sich sehr wahrscheinlich um SMP. Ich kann den Fehler nach einer Stunde auf zwei Maschinen mit nur einem CPU-Kern nicht reproduzieren. Um sicher zu sein fehlen mir aber noch weitere Maschinen, die zuvor im Versuch dabei waren und die ich heute Nacht abgeschossen habe und nun drauf warte, dass sie von anderen Freifunkern eingeschaltet werden.
Der Hintergrund ist: Kerneldumps von Multiprozessormaschinen sind wertlos, da man sie meines Wissens nicht Debuggen kann. Es hat laaaaaaange gedauert, bis mir das wieder eingefallen ist.
Wir nutzen aus dem Grunde zur Zeit auch nur ein Core jeweils. Einen Bugreport gibts auch dazu:
danke für den Link … ich werde dort auch was eintragen. Fragt sich nur, ob man was damit anfangen kann, denn aus dmesg-Ausgaben kann man nicht wirklich viel erfahren und SMP-Kernel-Dumps bekomme ich nicht analysiert.
1 „Gefällt mir“
Danke Phip für Dein Engagement!!!
Seit gestern kommt auch der Alfred wieder durch! Deine Optimierungen scheinen geholfen zu haben.
Mit L2TP würden doch auch weiter Supernodes (ohne Gateway) die Wupper Supernodes entlasten, oder? D.h.:
Router
|
viel Rechenarbeit, fastd
↓
GL Supernode
|
wenig Rechenarbeit, L2TP
↓
Wupper Gateway
Der nächste Schritt wäre dann, das Batman nur bis zu den GL Supernodes zu fahren und danach per Layer 3
Welch Implementation kommt eigentlich zum Einsatz? Es gibt ja irgendwie verschiedene. Wird IPSEC benutzt (soweit ich das verstanden habe ist das ein Krypto-Layer oben drauf)?
L2TP wurde nicht umgesetzt, da sonst die Superknoten abstürzen würden! Es ist alles beim Alten. Jedoch habe ich viel Zeit zum Ausprobieren gebraucht, um festzustellen, dass kein einziger Ansatz funktioniert, der mir eingefallen ist. Sogar die feste Zuweisung eines fastd, Alfred, bat-vis Prozesses zu einem bestimmten CPU-Kern haben nur kurzfristig Abhilfe geschaffen und mit mehr als einem L2TP Tunnel fliegen die Superknoten um die Ohren.
Es gibt noch andere Ansätze, jedoch habe ich erst Mal keine Zeit. Ich schreibe ein paar Bugreports und das war ’s vorerst. Viel später teste ich reine L2TP Knoten.
Alle in Wupper sollten im Übrigen ihre Kartenserver bekanntgeben, damit sie statisch angebunden werden und nicht beim Neustarten der Superknoten die Verbindung verlieren. Niemand außer Troisdorf hat das bis heute getan … ich brauche die Adresse oder IP plus öffentlichen fastd-Schlüssel ins Wiki. Dies ist der Grund für die falsche Statistik bzw. Meshviewer-Anzeige der letzten 5 Tage.
Wo, in welches Wiki?
gl1:
Public: 3408535ec67f042a4d384db510e1c018bd752e15b60cf5114963b1c1f4629fd3
46.38.241.142 oder gl.wupper.ffrl.de
dus0:
Public: 77c576371c6321dabc6aacbaee01382943fadca8fee05ea31d511ec0b484f589
46.38.234.225 oder map.ffdus.de
gek0:
Public: bb60aaecac94da608d2e41dd09635bb839fa998227884e24eaf85d43782a2b11
46.38.238.147 oder map.ffgek.de
1 „Gefällt mir“
Gilt das nur für die Upstreamanbindung oder auch, wenn man Knoten per L2TP anbindet?
https://wiki.freifunk-rheinland.net/Wupper#Weitere_Server
Das würde demnach auch für die Anbindung normaler Freifunkknoten an den Superknoten gelten. Irgendwo im Code ist ein Fehler, der durch bestimmtes Verhalten provoziert wird. Die Wahrscheinlichkeit, dass es im Datenstrom zwischen den Superknoten auftritt ist höher, da dort mehr Daten geleitet werden. Es ist also durchaus möglich, dass dies während der Kommunikation mit einem Freifunkknoten oder Offloader nicht auftritt, da sie nicht schnell genug ist, man kann aber nicht ausschließen, dass es da nicht auftreten wird. So wie ich das bisher sehe, sind nur Maschinen mit mehr als einem CPU-Kern betroffen.
Ist im Wiki. Ich habe auch mal ffdus / Düsseldorf-Flingern dort eingepflegt und alle weiteren mir bekannten Karten eingetragen.
2 „Gefällt mir“
