ERROR: read: Input/output error

[mvernimmen-CG]

I was playing with openfortivpn on my raspberry pi3 (This 1.4.0 on Raspbian GNU/Linux 8 (jessie)) and noticed this error after connecting:

root@raspberrypi:~# openfortivpn xxxx:443 --username=xxxx --realm=xxxxx -v
WARN:   Bad port in config file: "0".
DEBUG:  Loaded config file "/etc/openfortivpn/config".
VPN account password:
DEBUG:  Config host = "xxxxx"
DEBUG:  Config realm = "xxxx"
DEBUG:  Config port = "443"
DEBUG:  Config username = "xxxxx"
DEBUG:  Config password = "********"
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
INFO:   Connected to gateway.
INFO:   Authenticated.
DEBUG:  Cookie: SVPNCOOKIE=xxxx
INFO:   Remote gateway has allocated a VPN.
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
DEBUG:  pppd_read_thread
DEBUG:  ssl_read_thread
DEBUG:  gateway ---> pppd (12 bytes)
DEBUG:  ssl_write_thread
DEBUG:  if_config thread
DEBUG:  pppd ---> gateway (16 bytes)
DEBUG:  pppd_write thread
DEBUG:  pppd ---> gateway (12 bytes)

DEBUG:  gateway ---> pppd (24 bytes)
INFO:   Got addresses: [172.19.64.129], ns [172.19.30.252, 172.19.30.5]
DEBUG:  pppd ---> gateway (944 bytes)
DEBUG:  pppd ---> gateway (10 bytes)
DEBUG:  pppd ---> gateway (25 bytes)
DEBUG:  pppd ---> gateway (25 bytes)
ERROR:  read: Input/output error
INFO:   Cancelling threads...
DEBUG:  Waiting for pppd to exit...
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
INFO:   Logged out.

When applying the workaround mentioned in #56 about setting a route before starting the vpn, the connection builds up fine. I do need to add routes manually after having the vpn up, to make sure I can reach the other side through the vpn.

root@raspberrypi:~# ls -la /usr/sbin/netstat
ls: cannot access /usr/sbin/netstat: No such file or directory
root@raspberrypi:~# which netstat
/bin/netstat

[DimitriPapadopoulos]

Right now openfortivpn depends on netstat : see src/ipv4.c.

Does it help if you install package net-tools which provides netstat?

[mvernimmen-CG]

netstat is available and installed, via net-tools:

root@raspberrypi:~# apt list | grep net-tools
net-tools/oldstable,now 1.60-26 armhf [installed]
root@raspberrypi:~# which netstat
/bin/netstat

[mrbaseman]

Caution: the parsing code around netstat is part of the Mac OSX code. Apple's netstat produces a different output than the Linux netstat and the command line options it understands also partly differ from what is common on Linux distributions. So the whole parsing code can not be applied 1:1 on Linux.
Is /proc/net/route available and readable on the Raspberry Pi (because that should be used to obtain the routing table there)? If not, one could implement a similar wrapper as a fallback for this case on Linux around the route command like we did for Apple's netstat

[mvernimmen-CG]

Yes /proc/net/route is available and readable for unpriviliged users:

pi@raspberrypi:~ $ cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask            MTU     Window  IRTT                                                       
eth0    00000000        01DC780A        0003    0       0       0       00000000        0       0       0                                                                               
eth0    00DC780A        00000000        0001    0       0       0       00FCFFFF        0       0       0                                                                               
pi@raspberrypi:~ $ 

[mrbaseman]

I believe this looks like the read thread runs into an error:

ERROR:  read: Input/output error
INFO:   Cancelling threads...

maybe with more verbosity (openfortivpn -v -v ) which enables packet logging can give a clue about the root cause of this error.

[mvernimmen-CG]

last section of the output of -vv:

DEBUG:  pppd ---> gateway (10 bytes)
pppd:   c0 21 09 02 00 08 95 90 ca da

DEBUG:  pppd ---> gateway (66 bytes)
pppd:   00 21 45 00 00 40 f2 06 40 00 40 06 f3 33 0a 78 dc 51 4e 98 20 1c c4 3c 01 bb e6 cf 1d 23 e8 e4 96 c2 b0 10 01 3f 06 4e 00 00 01 01 08 0a 04 0e 24 99 41 e6 30 68 01 01 05 0a e8 e4 96 87 e8 e4 96 c2

DEBUG:  pppd ---> gateway (10 bytes)
pppd:   c0 21 09 03 00 08 95 90 ca da

DEBUG:  pppd ---> gateway (944 bytes)
pppd:   00 21 45 00 03 ae f2 07 40 00 40 06 ef c4 0a 78 dc 51 4e 98 20 1c c4 3c 01 bb e6 cf 01 a0 e8 e4 96 c2 80 18 01 3f 5e bb 00 00 01 01 08 0a 04 0e 38 00 41 e6 30 68 17 03 03 00 54 d6 ab 95 af f6 04 51 2c 13 d9 ed d1 fd 3f cb 1e ec c7 7c a4 30 24 5a 61 13 4a ba 1c ed 9c 6e 6c eb 60 bc 13 51 54 a2 8c 09 60 38 02 be 3b 25 86 45 af 6a fa 27 e6 f5 a9 63 94 26 b7 8b 87 92 de 87 11 3f d5 3d ac 56 0f 62 49 f0 58 9d ba 9e 73 63 3e 9e a9 17 03 03 00 ad d6 ab 95 af f6 04 51 2d 72 1e b5 75 36 fc 3c 2e 67 15 f2 2d 73 b3 d4 7c 9b 7c 35 d6 d5 31 0a fd 4e cf 42 78 0c 9b 73 7a 22 24 a9 70 0f 0c 84 89 e3 ee cf dc c3 9d b6 a2 1f 84 70 82 7d 91 53 f1 06 c6 ad cb 26 a9 f1 df 6f 40 c4 d4 bd 45 90 5e 5e 17 82 af f1 fb b4 6f 7c 7e 78 79 92 bb e7 83 02 3a 19 e2 c3 78 c4 72 32 42 cb 4a 94 13 90 ff b6 d7 3b b0 76 af 6b c8 02 88 63 7d 37 13 2c a3 be cd 3c 36 53 86 97 d0 3a cc c6 a1 ac cd 61 bf 75 fd 35 4b 92 64 5d 78 3b 18 f2 24 9a 45 0c 1d 3c 3e ce e2 5a ca be 40 e0 45 85 60 da 17 03 03 01 06 d6 ab 95 af f6 04 51 2e 2e df 23 0f 9e 4f 2d f7 4a 0f ff de a2 60 b5 41 f1 c6 31 45 12 ee 0b 41 49 5c dd 67 a6 11 2f 72 b5 e0 8f bd 5c 84 10 f4 37 23 84 8c b1 7f 47 29 91 4e 94 bf b2 0b e3 18 1b 5e 6c c3 f6 c7 9a e7 a6 f0 ed 09 57 93 a3 b9 39 d7 2f 85 19 16 3c 8f 50 18 d5 7e d3 25 a1 6a d7 ab b0 60 77 6f a6 84 14 98 ec 3f 48 52 59 85 b1 fc b6 7f 1b 5c 74 2f d4 8c bd 1e cb 2a 83 c0 33 41 e1 11 6e fd 60 e5 c8 13 7e f2 a7 cc 21 71 73 01 2a 1d 76 6a 8a 81 cf 3e 94 63 fa 2a 0c 53 ea fa 33 45 b9 ae 1a 01 85 1f 8c 66 f8 4a e5 d2 6e 7a 5f fa b2 d9 19 31 80 9a 43 12 80 a3 16 4a a2 eb 28 37 a1 d1 d3 2e 96 51 5b 8a 77 7e 60 a3 79 be 99 a9 e4 7f cf fd df b7 95 39 fc 8a cf 9e 04 49 ef 46 15 36 f4 43 6e 32 12 c1 96 86 11 8e 89 e4 c7 81 c4 27 39 89 09 25 ae 84 b0 50 26 51 c0 36 2e e7 e7 ee 17 03 03 01 5f d6 ab 95 af f6 04 51 2f 30 ce 06 6b 8d f8 63 ec 2d a7 1f fc e3 30 a8 35 00 8d c6 9a 9d 98 e2 e0 62 6c 1a 95 7a 3e 09 95 d1 27 53 ce 20 04 60 42 d2 64 84 e4 78 7b b2 20 89 ae e7 6d dc 81 d8 82 c9 f9 46 79 05 bf 11 4b 1a b8 75 f9 71 6c d5 6d 5b cb 2a 44 56 ff b5 41 ab 72 f4 bc b3 ac 7e dd f1 c5 a4 ab 18 ab 74 29 d5 c2 b5 de b6 2b 42 41 7a 92 2e ec 5e 81 90 25 3c fc 2f ee c1 c3 cf 61 b9 3a af 33 03 29 04 25 d4 59 9d 57 ac a1 e8 e5 ce be d0 e5 d8 1c 59 fb 71 34 69 46 20 9a 20 07 24 aa 1c bd e3 2d 0b 16 b3 65 d1 c5 da 23 a1 0d 01 24 40 37 b5 c7 41 5a 40 88 4e d2 68 15 c2 59 00 88 bc bb b1 26 e8 a6 97 08 25 fd 13 49 f3 42 d3 70 a0 a3 c4 27 8b bc cd 20 38 e9 12 13 41 27 f7 2c b9 15 57 8d 63 6e 49 71 92 f9 f2 22 b7 d9 eb cf ff f2 4e 22 30 b3 92 1c f9 a1 45 de b1 f4 79 3b 22 43 b6 8b 12 be 82 b0 c7 7a 3c 21 e2 7b b5 bd c9 72 3b 7e 3d d0 1c c7 b2 68 8d db 29 62 9e 2a e7 c7 35 c5 79 ca b4 d4 8d ff 1d 19 84 3b ea bb 88 de 5c e7 31 ff 7d c7 8d 1c fb ca c9 1b 14 6f 85 8b a5 37 a5 33 80 59 ca 32 05 0b 20 b1 9e 21 86 8c d9 2c 49 51 40 08 28 a5 57 93 9b

DEBUG:  pppd ---> gateway (10 bytes)
pppd:   c0 21 09 04 00 08 95 90 ca da

DEBUG:  pppd ---> gateway (66 bytes)
pppd:   00 21 45 00 00 40 f2 08 40 00 40 06 f3 31 0a 78 dc 51 4e 98 20 1c c4 3c 01 bb e6 cf 1d 23 e8 e4 96 c2 b0 10 01 3f d2 1d 00 00 01 01 08 0a 04 0e 3e b1 41 e6 4a 80 01 01 05 0a e8 e4 96 87 e8 e4 96 c2

DEBUG:  pppd ---> gateway (25 bytes)
pppd:   c0 21 05 02 00 17 50 65 65 72 20 6e 6f 74 20 72 65 73 70 6f 6e 64 69 6e 67

DEBUG:  pppd ---> gateway (25 bytes)
pppd:   c0 21 05 03 00 17 50 65 65 72 20 6e 6f 74 20 72 65 73 70 6f 6e 64 69 6e 67

ERROR:  read: Input/output error
INFO:   Cancelling threads...
DEBUG:  Waiting for pppd to exit...
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
INFO:   Logged out.
pi@raspberrypi:~ $

[mrbaseman]

interesting is that the last two packets (25 bytes each) are exactly the same - and if we decode the hex sequence it results in the string "�!Peer not responding"

[wuiler]

In my case the solution was :
sudo apt-get install ppp
and start over the compilation.

[robmukai]

I am having the same behavior, however it only happens when I try to rsync over ssh through the forticlient. It works fine if I just ssh over the vpn. When I run rsync, I get the same

ERROR: read: Input/output error
INFO: Cancelling threads...

and the

"�!Peer not responding"
when using -vv

I am running ubuntu 16.04.3 64 bit. openfortivpn is compiled from source. As a note, I tried the openforticlientgui for ubuntu 64 bit and it has the same behavior.

Please let me know if I should open a new ticket or if you believe this is the same issue.
@

[DimitriPapadopoulos]

@robmukai Running rsync probably generates heavy traffic. I guess FTP transfers would end up in the same error.

About your last question, it's hard to tell whether the error is caused by the client, the server, or perhaps related to broken networks in between. As a mere example I have been unable to use not only openfortivpn but also the official FortiClient these last days, from a location were the Wi-Fi network and/or the subscriber line behind it clearly suffered some issues: non-SSL TCP connections were slow or would occasionally fail. The SSL connection to port 443 did open, data were exchanged between the client and the gateway, and at some point pppd exited with status code 16 (meaning the gateway didn't respond to echo requests). It works just fine from another location. Didn't have time to investigate more. I really don't know... Errors may hide anywhere.

[robmukai]

@DimitriPapadopoulos Thanks for the response. I do have a bit of a slow connection (microwave based). However, I can run rsync over forticlient in windows 10. I would love to put the windows box down, and just use linux, however, if I can't get rsync running over openfortivpn, I might not be able to. I know it is a little like finding a needle in a haystack, but I am happy to do some testing if you can point me to things to try.

[DimitriPapadopoulos]

@robmukai I suspect the cause of the problems you're experiencing is different from the initial poster's. Therefore I would suggest opening a new ticket. Then maybe a maintainer might have a look at it - probably not me because I'm not acquainted enough with openfortivpn internals or networking.

[robmukai]

@DimitriPapadopoulos Thanks for the response. I have opened #184 Hopefully we can get this figured out.

[LightAutumnMelancholy]

This synopsis was in error.

[adrienverge]

Hi,

I'm not sure what are the security and portability implication of calling which, but it doesn't feel right to me to call a UNIX command from C.

Maybe it would be better to check $PATH in the "classical" way, like there?
https://www.linuxquestions.org/questions/programming-9/get-full-path-of-a-command-in-c-117965/#post611028

Finally, if you're able to call which without a full path:

wnst = popen("which netstat");

why not calling netstat directly like this?

[LightAutumnMelancholy]

Well, thats totally valid, but if you call netstat directly, you should make sure it is installed. Or an installer script could simply symlink. Thanks, Jonathan

…

On Feb 7, 2018 4:19 AM, "Adrien Vergé" ***@***.***> wrote: Hi, I'm not sure what are the security and portability implication of calling which, but it doesn't feel right to me to call a UNIX command from C. Maybe it would be better to check $PATH in the "classical" way, like there? https://www.linuxquestions.org/questions/programming-9/ get-full-path-of-a-command-in-c-117965/#post611028 Finally, if you're able to call which without a full path: wnst = popen("which netstat"); why not calling netstat directly like this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#154 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXieCbRyo278TwR_N5pQeqvRaYhteWXwks5tSWqDgaJpZM4OiTOK> .

[DimitriPapadopoulos]

@jon2kx

1. Is netstat ever installed in a different location than /usr/sbin/netstat? Remember this part of the code runs on Mac OS X only.
2. Even if /usr/sbin/netstat were missing, the call to popen() should fail gracefully. Have you seen cases where it doesn't fail gracefully?

I'm not certain these patches are helpful.