search

AuspeXeu / openvpn-status

A web-based application to monitor OpenVPN server client connections
MIT License
161 stars 48 forks source link

Props tuncated issue #460

Open rajesh8614 opened 4 years ago

rajesh8614 commented 4 years ago

Using docker latest image

> openvpn-status@4.2.32 start /usr/src/app
> node server.js

Connected to management console @ 10.x.1.253:7505
Connected to management console @ 10.x.1.61:7506
props truncated ROUTING_TABLE   192.168
props truncated ROUTING_TABLE   192.168
props truncated ROUTING_TABLE   192.168
props truncated ROUTING_TABLE   192.168
props truncated ROUTING_TABLE   192.168
props truncated ROUTING_TABLE   192.168
AuspeXeu commented 4 years ago

Maybe @KarlStraussberger can help with this.

KarlStraussberger commented 4 years ago

Works as disigned. I don't know why the socket read returns before the end of the message but otherwise the application aborts in an exception.

It may be caused by openvpn itself because I observe similar issues in syslog as well. It can be a multithreading issue inside openvpn.

eJc2 commented 4 years ago

Hi, i have the same issue

Attaching to openvpn-status openvpn-status | openvpn-status | > openvpn-status@4.2.32 start /usr/src/app openvpn-status | > node server.js openvpn-status | openvpn-status | Connected to management console @ xxx.xxx.xxx.xxx:9994 openvpn-status | props truncated ROUTING_TABLE 172.16.1.5 openvpn-status | props truncated ROUTING_TABLE 172.16.1.5

This is the log on openvpn side:

Apr 29 16:48:58 rc02 openvpn[16028]: MANAGEMENT: CMD 'status 3' Apr 29 16:48:58 rc02 openvpn[16028]: SCHEDULE: schedule_find_least NULL Apr 29 16:48:58 rc02 openvpn[16028]: EP_CTL fd=10 rwflags=0x0002 ev=0x00000004 arg=0x00000004 Apr 29 16:48:58 rc02 openvpn[16028]: EP_WAIT[0] rwflags=0x0002 ev=0x00000004 arg=0x00000004 Apr 29 16:48:58 rc02 openvpn[16028]: SCHEDULE: schedule_find_least NULL Apr 29 16:48:58 rc02 openvpn[16028]: EP_CTL fd=10 rwflags=0x0001 ev=0x00000001 arg=0x00000004 Apr 29 16:49:03 rc02 openvpn[16028]: EP_WAIT[0] rwflags=0x0001 ev=0x00000001 arg=0x00000004 Apr 29 16:49:03 rc02 openvpn[16028]: MULTI: REAP range 96 -> 112 Apr 29 16:49:03 rc02 openvpn[16028]: MANAGEMENT: CMD 'status 3' Apr 29 16:49:03 rc02 openvpn[16028]: SCHEDULE: schedule_find_least NULL Apr 29 16:49:03 rc02 openvpn[16028]: EP_CTL fd=10 rwflags=0x0002 ev=0x00000004 arg=0x00000004 Apr 29 16:49:03 rc02 openvpn[16028]: EP_WAIT[0] rwflags=0x0002 ev=0x00000004 arg=0x00000004 Apr 29 16:49:03 rc02 openvpn[16028]: SCHEDULE: schedule_find_least NULL Apr 29 16:49:03 rc02 openvpn[16028]: EP_CTL fd=10 rwflags=0x0001 ev=0x00000001 arg=0x00000004 Apr 29 16:49:08 rc02 openvpn[16028]: EP_WAIT[0] rwflags=0x0001 ev=0x00000001 arg=0x00000004 Apr 29 16:49:08 rc02 openvpn[16028]: MULTI: REAP range 112 -> 128

Any hint?

KarlStraussberger commented 4 years ago

On our side socket.read returns too early so the remaining details are added to the next call. I do not know why this happens and when it startet. I just managed to stabilize the script. Maybe somebody can see the error already.

eJc2 commented 4 years ago

thanks for reply, so openvpn responds too slow?

KarlStraussberger commented 4 years ago

Maybe, as soon as we know the reason, we can think about a solution.

eJc2 commented 4 years ago

ok, thanks for your help