- Mitglied seit
- 17. Apr 2012
- Beiträge
- 7
- Punkte für Reaktionen
- 0
- Punkte
- 1
Hallo,
nach jeder (erfolgreichen) Verbindung von einem Windows-PC (Win7 32) auf
meine Synology DS212+ einsteht ein neuer synoautoblock-Zombie, ausserdem
genau ein synovpnlog-Zombie.
root ~ $ ps | grep 'Z'
13906 root 0 Z [synoautoblock]
14368 root 0 Z [synoautoblock]
14731 root 0 Z [synoautoblock]
15399 root 0 Z [synovpnlog]
15679 root 2988 S grep Z
openvpn.log:
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 TLS: new session incoming connection from 178.XXX.XXX.XX:1194
Sun Apr 14 13:53:04 2013 RADIUS-PLUGIN: FOREGROUND THREAD: isAuthenticated()1Sun Apr 14 13:53:04 2013 RADIUS-PLUGIN: FOREGROUND THREAD: isAcct()1Sun Apr 14 13:53:04 2013 RADIUS-PLUGIN: No attributes Acct Interim Interval or bad length.
Sun Apr 14 13:53:04 2013 RADIUS-PLUGIN: FOREGROUND THREAD: Don't add the user to the map, it is a rekeying.
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 PLUGIN_CALL: POST /var/packages/VPNCenter/target/lib/radiusplugin.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 TLS: Username/Password authentication succeeded for username 'frank' [CN SET]
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 TLS: tls_multi_process: untrusted session promoted to semi-trusted
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA
Sun Apr 14 13:53:06 2013 frank/178.XXX.XXX.XX:1194 PUSH: Received control message: 'PUSH_REQUEST'
Sun Apr 14 13:53:06 2013 frank/178.XXX.XXX.XX:1194 SENT CONTROL [frank]: 'PUSH_REPLY,route 192.168.2.0 255.255.255.0,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (status=1)
Wird auf der Syslogy der openvpn-Server gestoppt und neu gestartet, sind die
Zombie-Prozesse weg.
Status aus proc:
root /proc/13906 $ cat status
Name: synoautoblock
State: Z (zombie)
Tgid: 13906
Pid: 13906
PPid: 13815
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups: 0
Threads: 1
SigQ: 1/3960
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180000000
CapInh: 0000000000000000
CapPrm: fffffffffffffeff
CapEff: fffffffffffffeff
CapBnd: fffffffffffffeff
voluntary_ctxt_switches: 1
nonvoluntary_ctxt_switches: 2
root /proc/14368 $ ps | grep 13815
13815 root 55676 S /var/packages/VPNCenter/target/sbin/vpnauthd
15554 root 2988 S grep 13815
Hat irgendwer eine Idee, woran das Problem liegt?
Bin für jeden Ansatz dankbar.
Grüße
Frank
nach jeder (erfolgreichen) Verbindung von einem Windows-PC (Win7 32) auf
meine Synology DS212+ einsteht ein neuer synoautoblock-Zombie, ausserdem
genau ein synovpnlog-Zombie.
root ~ $ ps | grep 'Z'
13906 root 0 Z [synoautoblock]
14368 root 0 Z [synoautoblock]
14731 root 0 Z [synoautoblock]
15399 root 0 Z [synovpnlog]
15679 root 2988 S grep Z
openvpn.log:
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 TLS: new session incoming connection from 178.XXX.XXX.XX:1194
Sun Apr 14 13:53:04 2013 RADIUS-PLUGIN: FOREGROUND THREAD: isAuthenticated()1Sun Apr 14 13:53:04 2013 RADIUS-PLUGIN: FOREGROUND THREAD: isAcct()1Sun Apr 14 13:53:04 2013 RADIUS-PLUGIN: No attributes Acct Interim Interval or bad length.
Sun Apr 14 13:53:04 2013 RADIUS-PLUGIN: FOREGROUND THREAD: Don't add the user to the map, it is a rekeying.
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 PLUGIN_CALL: POST /var/packages/VPNCenter/target/lib/radiusplugin.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 TLS: Username/Password authentication succeeded for username 'frank' [CN SET]
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 TLS: tls_multi_process: untrusted session promoted to semi-trusted
Sun Apr 14 13:53:04 2013 frank/178.XXX.XXX.XX:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA
Sun Apr 14 13:53:06 2013 frank/178.XXX.XXX.XX:1194 PUSH: Received control message: 'PUSH_REQUEST'
Sun Apr 14 13:53:06 2013 frank/178.XXX.XXX.XX:1194 SENT CONTROL [frank]: 'PUSH_REPLY,route 192.168.2.0 255.255.255.0,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (status=1)
Wird auf der Syslogy der openvpn-Server gestoppt und neu gestartet, sind die
Zombie-Prozesse weg.
Status aus proc:
root /proc/13906 $ cat status
Name: synoautoblock
State: Z (zombie)
Tgid: 13906
Pid: 13906
PPid: 13815
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups: 0
Threads: 1
SigQ: 1/3960
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180000000
CapInh: 0000000000000000
CapPrm: fffffffffffffeff
CapEff: fffffffffffffeff
CapBnd: fffffffffffffeff
voluntary_ctxt_switches: 1
nonvoluntary_ctxt_switches: 2
root /proc/14368 $ ps | grep 13815
13815 root 55676 S /var/packages/VPNCenter/target/sbin/vpnauthd
15554 root 2988 S grep 13815
Hat irgendwer eine Idee, woran das Problem liegt?
Bin für jeden Ansatz dankbar.
Grüße
Frank