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“
Ja. Zweite Zeile: SMP-Kernel. Entweder singlecore mit maxcpu=1 oder mit nosmp in den Kernelparametern starten. Ist ein Bug, den man so nicht wirklich debuggen kann, da es ja SMP ist.
Noch ein mal in die Runde: Wer weiß, wie man einen SMP-Kernel debuggen kann? In der Literatur lese ich immer nur vom Debugging von nicht SMP-Kerneln …
Stellt doch besser durchsuchbare Ausgaben hier rein. Dann können vielleicht andere mit einer ähnlichen Fehlermeldung das hier bei Google finden.
Das ist einigermaßen schwierig wenn man die Console erst Post-mortem öffnet und das ein Web-VNC ist, also „APA“. Oder gibt es dafür irgendwo eine fixe OCR-Lösung im Web.
Dieser wird in den Bootloader eingetragen, welcher die Parameter beim Booten an den Kernel bei dessen Start übergibt.
https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Bei debian 4.2 Backports funktioniert nosmp nicht wirklich … ich glaube man fährt da am besten mit einem selbst kompilierten Kernel. maxcpus=0 habe ich noch nicht getestet, klingt aber vielversprechend … scheint aber identisch zu nosmp zu sein. maxcpus=1 bootet immer noch einen SMP-Kernel.
Da Wupper batman v15 und Systeme/VMs mit >1 CPU einsetzt, gilt das wohl generell.
v14 läuft auf Single-CPU-VMs mit 3+ L2TP-Tunneln geschmeidig. Sprich: Wupper-Probleme sind auf batman-v14-Communities nicht zwingend übertragbar.