Modul tun.ko fehlt

[cyorps]

Hallo,

ich versuche gerade openvpn via IPKG zu installieren. Wenn ich das Modul tun.ko einbinden möchte, erhalte mit dem Befehl

/sbin/insmod /lib/modules/tun.ko

die Meldung

insmod: can't insert '/lib/modules/tun.ko': No such file or directory

Was richtig ist, denn in diesem Pfad ist keine tun.ko enthalten. Die Pakteinstallation laut Wiki-Anleitung ist sauber durchgelaufen. Wie kann ich dieses Problem beheben?

lsmod gibt folgendes aus:

Module                  Size  Used by
usbhid                 24803  0
hid                    43126  1 usbhid
usblp                   9866  0
usb_storage            41342  0
uhci_hcd               20603  0
xhci_hcd               59932  0
ehci_hcd               34640  0
cifs                  210230  0
udf                    76158  0
isofs                  30379  0
loop                   12734  0
bonding                85983  0
pineview_synobios      28674  0
ipv6                  251130  52 bonding
synoacl_ext4           13079  1
synoacl_vfs             5052  1
hfsplus                73008  0
fuse                   56176  0
vfat                    9598  0
fat                    47252  1 vfat
ecryptfs               87023  0
sha512_generic          4537  0
sha256_generic          8604  0
sha1_generic            1927  0
ecb                     1833  0
aes_x86_64              7268  0
chainiv                 3047  0
des_generic            15547  0
crc32c                  2590  0
eseqiv                  2384  0
krng                    1017  0
ansi_cprng              3525  0
rng                     1619  4 chainiv,eseqiv,krng,ansi_cprng
aes_generic            25610  1 aes_x86_64
md5                     3545  0
cbc                     2547  0
cryptomgr               2312  0
pcompress               1161  0
aead                    4651  1 cryptomgr
crypto_hash            10847  5 sha512_generic,sha256_generic,sha1_generic,crc32c,md5
crypto_blkcipher        9067  5 ecryptfs,ecb,chainiv,eseqiv,cbc
crypto_wq                663  1 chainiv
crypto_algapi          10887  14 ecb,aes_x86_64,chainiv,des_generic,eseqiv,krng,ansi_cprng,aes_generic,cbc,cryptomgr,pcompress,aead,crypto_hash,crypto_blkcipher
cpufreq_stats           2965  0
freq_table              2147  1 cpufreq_stats
dm_snapshot            19579  0
crc_itu_t               1153  1 udf
crc_ccitt               1187  0
quota_v2                2629  2
quota_tree              6710  1 quota_v2
usbcore               135056  7 usbhid,usblp,usb_storage,uhci_hcd,xhci_hcd,ehci_hcd
sg                     23110  0
psnap                   1733  0
llc                     3456  1 psnap

 

[jahlives]

find / -name tun.ko und gucken obs gefunden wird

 

[janus]

Moin,
da ich gerade die Kernel Module für meine 1010+ gebaut habe, findet ein:
bash-3.2# find . -name "tun.ko"
./drivers/net/tun.ko
das entsprechende Kernel Modul.

Bleibt nur noch das Problem: Wohin mit dem Modul, damit du das bekommst?

Gruß

Janus

 

[cyorps]

Also gefunden hat das System nichts.
@janus Schreibe dir eine PN.

 

[jahlives]

Dann tippe ichdarauf, dass tun.ko mit dem OpenVPN Paket von Synology installiert wird

 

[cyorps]

Das hatte ich ausprobiert, bevor ich dieses Thema gestartet hatte. Nach der Installation von Synology's VPN-Paket bekam ich die selbe Fehlermeldung.

 

[janus]

Moin,
ich legs mal temporär auf meinem NAS ab:
http://someone.homelinux.net/tun.ko.gz

Gruß

Janus
p.s.: Wobei es mich gerade stark wundert, dass du kein tun.ko findest. Bei mir ist tun.ko unter /lib/modules vorhanden!

 

[jahlives]

@janus
hat denn die 1010+ einen 64bit Intel Prozi drin? Dachte die hätte noch einen 32bitter drin

 

[cyorps]

Nein, es war nicht vorhanden. Ich hatte vorher direkt im Pfad nachgeschaut und auch systemweit mit den angebotenen Befehl gesucht. Jedenfalls habe ich die Datei heruntergeladen und das Einbinden dieses Moduls hat funktioniert. Vielen Dank an alle.

Lt. Wikitabelle sind es die gleichen CPUs mit unterschiedlichen Taktfrequenzen auf x64-Basis.

 

[janus]

@jahlives: Nun, die Binaries sind komplett in 32 Bit, aber sobald es an Kernel Module geht, sind es 64 Bit Module.

bash-3.2# file /lib/modules/tun.ko
/lib/modules/tun.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

bash-3.2# file /bin/busybox
/bin/busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.4.3, stripped
bash-3.2#

Wenn ich ehrlich bin, muss ich allerdings zugeben, dass ich schlicht vermutet habe, dass die Hardware nicht gross unterschliedlich ist. Nachgesehen habe ich nicht. Ob das Modul funktioniert, muss er schon noch selbst ausprobieren, da ich ja nur die 1010+ habe ;-)

Gruß

Janus

 

[janus]

Dann tippe ich darauf, dass tun.ko mit dem OpenVPN Paket von Synology installiert wird

Habe gerade noch mal nach dem Filedatum des tun.ko gesehen. Bei mir hat es das selbe Datum, wie alle anderen von DSM gelieferten Module. Daher gehe ich davon aus, dass das Modul mit der Installation der DSM 3.2 reingekommen ist.

Gruß

Janus

 

[janus]

@janus
hat denn die 1010+ einen 64bit Intel Prozi drin? Dachte die hätte noch einen 32bitter drin

Ach ja,
dann noch mal zum Schluss, da ich die Build Umgebung eh schon eingerichtet habe, könnte ich mit relativ wenig Aufwand auch noch weitere Kernel Module bauen.

Das Wunschkonzert ist eröffnet.

Dabei bitte beachten, dass es sich um x86_64 handelt! Derzeit kein ARM und Co!

Es müsste sich nur ein endgültiger Ort für die Binary Module finden, da ich mein NAS da für ungeeignet halte.

In dem Thread zum SMA Solar Logger hatte ich ja schon geschrieben, dass ich bereits die Bluetooth Module gebaut und getestet habe.

Gruß

Janus
p.s. Etwas mehr Aufwand, aber ich habe ja auch noch eine DS210j. Ggf. lasse ich mich dazu überreden, für das gute Stück den Compiler anzuwerfen, auch wenns wohl länger dauert.

 

[cyorps]

Der VPN-Tunnel funktioniert mit der von janus bereitgestellten Version tun.ko. Vielen Dank noch einmal.

Jetzt muss ich nur noch herausbekommen, wie die DS mit ovpn einen sauberen Neustart hinlegt. Denn weder das in der Anleitung gezeigte Script, noch das alternative Script funktioniert bei mir.

 

[janus]

Der VPN-Tunnel funktioniert mit der von janus bereitgestellten Version tun.ko. Vielen Dank noch einmal.

Jetzt muss ich nur noch herausbekommen, wie die DS mit ovpn einen sauberen Neustart hinlegt. Denn weder das in der Anleitung gezeigte Script, noch das alternative Script funktioniert bei mir.

Das tun.ko hatte ich, wie gesagt, sowieso da, war also kaum Aufwand. Also Null Problemo!

Btw. Was heisst Neustart?

Bei mir wird auf ein paar Rechnern einfach der Tunnel alle 15 Minuten mittels ping geprüft und wenn ping nicht durchkommt, wird der Tunnel einfach neu gestartet. Der Router ist sozusagen nur das passive Ende und wartet auf Verbindungen. Auf alles andere hat man eh kaum einen Einfluss.
Nur so ein paar Gedanken dazu:
NAS Defekt -> Keine Chance
Router defekt -> Neustart des NAS nützt nichts.
Kabel ab -> Neustart des NAS nützt nichts.

Etwas OT:
Ich bin übrigens immer noch der Meinung, dass openvpn auf einem NAS nichts verloren hat. Das macht man im einfachsten Fall auf einem Router z.B. Siehe meine Signature, hat mich gerade mal 50 Euro gekostet und man hat keine Probleme mit dem Routing.
Die Konfiguration war nicht ganz so trivial, aber läuft bei mir seit knapp einem Jahr sehr stabil und bei meiner sporadischen Nutzung auch ausreichend schnell.

Gruß

Janus
p.s.: (Da mir beim neustart des VPN mal SSH abhanden gekommen ist, habe ich das zusätzlich geprüft.)
#!/bin/sh

VPNSERVER=192.168.1.1

check() {
if( ping -c 2 ${VPNSERVER} )
then
/bin/false
else
/etc/init.d/openvpn restart
fi
}

checksshd() {
/etc/init.d/sshd status >/dev/null 2>&1
RC=$?
if [ ${RC} -ne 0 ]; then
echo not startet
/etc/init.d/sshd start
fi
}

check 2>&1 > /dev/null

checksshd 2>&1 > /dev/null

# vpnrestart.sh end

 

[ubuntulinux]

Die tun.ko ist ab Firmware 2.3 dabei.

Warum willst du neu starten? Bei mir versuchen sich die Clients selber neu zu verbinden.

 

[cyorps]

Entschuldige, da hatte ich mich unklar ausgedrückt. Mit deiner tun.ko lief der Tunnel selbst ohne Probleme. Zusätzlich testete ich das Start-/Stop-Skript (das erweiterte Skript und nicht die Kurzfassung in der Wiki-Anleitung) für ovpn manuell. Es lief durch und ich sah mittels "ps", dass ovpn nicht mehr lief. Danach testete ich mit laufenden ovpn einen Neustart der DS. Das Ergebnis war, dass die DS hängen blieb. Bei der erweiterten Lösungssuche kam mir im englischsprachigen Synology-Forum beim Lesen eines Threads die Idee, dass ich im DSM-Update nach der tun.ko suchen könnte. Und siehe da, es war vorhanden. Also kopierte ich diese Datei auf die DS. Jetzt funktioniert sowohl ovpn selbst als auch der Neustart der DS problemlos. Ich weiß, das ein Herunterfahren oder Neustart der DS so gut wie nie vorkommt. Trotzdem will ich wissen, dass dies für den Fall der Fälle sauber funktioniert.

Bezüglich deiner Anmerkung ovpn: Da hast du sicherlich recht. Ich nutze eine FB 7390 und hatte mich belesen, wie man dort ovpn installiert bekommt. Die Quintessenz war, dass mir die Installation auf der DS mittels IPKG a) komfortabler erschien und b) mir die Community dieses Forums extrem zusagt. Was hier im Forum sowie auch im Wiki an Hilfestellungen und Anleitungen bereitgestellt werden, ist eine Bank die ich zu schätzen weiß. Da fühle ich mich euch zu großen Lob und Dank verpflichtet! Insgesamt ist die EierLegendeWollmichSau FB 7390 ausreichend für die restliche Verwaltung meines LAN's. Klar sie kann keine MTU-Packages >1500 verarbeiten, aber hier hatte ich ein noch unverbautes Cisco-Switch von der Arbeit mitgenommen und den Unterschied getestet. Naja, im Optimalfall erhöhte sich die Transferrate meines LANs um 2,7 MB/s. Diese Steigerung ist bei meinen Anwendungszwecken vernachlässigbar. Zumal der Stream von der DS zu den beiden TV's (ebenfalls Samsung) via 802.11n so oder so zuverlässig läuft.

 

[janus]

@ubuntulinux:
Openvpn überwachung war leider für den 24h disconnect der Telekom notwendig. Leider schaffte es openvpn nicht immer, die Verbindung wieder herzustellen. Ggf. war ich auch zu blöde die richtigen Config Optionen zu finden, aber nach 2 Tagen Suche, war das Script die einfachste Lösung.

edit:
@cyorps: Lobenswert! Da achtet doch tatsächlich mal jemand darauf, dass es rundum funktioniert! Sonst muss man sich da den Mund fusselig reden! ;-)

Gruß

Janus

 

[ubuntulinux]

OK, das kann ein Grund sein. Hab bei meinem Provider dieselbe IP, solange ich dieselbe MAC-Adresse am WAN Interface des routers hab. Zwangstrennung hab ich auch keine.