Closed e-t-l closed 1 year ago
What is the reason in the internal log of the app why it disconnects?
VPN for different user accounts are to my knowlege always separated on Android phone and I am not aware of any API or workarounds around that and it should also not be possible.
Ok, it just happened again so I was able to copy some of the internal logs. It looks like it's these two entries, alternating one after the other. I assume it has something to do with the VPN retrying to connect? Since there's hundreds of them. It doesn't let me scroll far enough back in time to see the log at the actual time of disconnect.
10:33 PM Unhandled exception: Invalid packet data!
java.io.IOException: Invalid packet data!
at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.readInt(StreamCapture.java:125)
at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.readPacket(StreamCapture.java:132)
at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.run(StreamCapture.java:222)
at java.lang.Thread.run(Thread.java:1012)
10:33 PM Unhandled exception: write failed: EPIPE (Broken pipe)
java.io.IOException: write failed: EPIPE (Broken pipe)
at libcore.io.IoBridge.write(IoBridge.java:651)
at java.io.FileOutputStream.write(FileOutputStream.java:401)
at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.writeThrough(StreamCapture.java:185)
at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.run(StreamCapture.java:275)
at java.lang.Thread.run(Thread.java:1012)
Caused by: android.system.ErrnoException: write failed: EPIPE (Broken pipe)
at libcore.io.Linux.writeBytes(Native Method)
at libcore.io.Linux.write(Linux.java:296)
at libcore.io.ForwardingOs.write(ForwardingOs.java:943)
at libcore.io.BlockGuardOs.write(BlockGuardOs.java:448)
at libcore.io.ForwardingOs.write(ForwardingOs.java:943)
at libcore.io.IoBridge.write(IoBridge.java:646)
... 4 more
Also, regarding
VPN for different user accounts are to my knowlege always separated on Android phone and I am not aware of any API or workarounds around that and it should also not be possible.
I did link you to the source code of a VPN that does exactly that. The good news is that it definitely is possible, and we can even look at how they did it!
Are you sure that you are using my app? That stacktrace including a class (StreamCapture.java) that is not part of my source code.
It's the pDNSf fork (https://github.com/IngoZenz/ics-openvpn/), where the only difference is that DNS queries are sent to port 5300 by default, which uses that streamcapture library.
From that fork's readme: If the DNS option is not used,
OpenVPN for personalDNSfilter will behave exactly as the original OpenVPN for Android application.
If you think the issue specifically arises from streamcapture integration, that's good to know. But it seems unlikely, given how we've been discussing that it's specifically a conflict that occurs when running a VPN on multiple profiles
@e-t-l yes but your stacktrace includes those streamcapture things. So something might break that. And the streamcapture integration messes quite a bit with the VPNservice. So all I see is that streamcapture stuff somehow breaks but I have real idea what is actually going on. From a quick glance at the trace you posted it seems that streamcapture throws an exception and after that your connection breaks. Which points at streamcapture as the culprit.
I see what you mean. I can uninstall and replace it with the unmodified version to see if the logs change. So have you not been able to replicate these unexpected disconnects when you run OpenVPN in Personal and Work profiles simultaneously?
(Edit: I thought I finally captured a log that's different from the other two. Turns out it's just the same. It's hard to copy the stack traces because they go by so fast. Not sure why, since it doesn't even look like the VPN is trying to reconnect. Do you recognize any of these exceptions, like EPIPE or Invalid Packet Data?)
I know EPIPE and Invalid Packet Data are and they are very likely to be caused by streamcapture as well. So for me it is still very likely to assume that this is a problem of those modifications and not of my app.
Closing this issue for now until we know that it is really my app and not the modification
rdns dev here
Suggestion: The RethinkDNS app evidently has some way of routing ALL users' traffic (aka from both personal and work profiles) through one VPN app installed for only user 0.
Don't think that's possible and rdns most certainly doesn't do anything special (even if it did, it won't have worked without root
).
To make issues more manageable, I would appreciate it if you fill out the following details as applicable:
General information
Description of the issue
When two user profiles (in this case the personal and work profiles) are both running the OpenVPN for Android app, there seems to be some sort of interaction/conflict that causes one or both of them to disconnect.
I'm not sure if it's related to #1293 and/or #1299 since it seems to happen more frequently (but not exclusively or consistently) overnight or when switching networks. I do get the "OpenVPN3 thread finished" message, but switching back to OpenVPN v2 didn't seem to make a difference, nor did having one profile on v3 and one on v2. Per #1299 I'm currently trying having "Bypass VPN for local networks" disabled but I haven't had that changed for long enough to determine if it has completely solved the issue.
Suggestion: The RethinkDNS app evidently has some way of routing ALL users' traffic (aka from both personal and work profiles) through one VPN app installed for only user 0. If we can identify how RethinkDNS accomplishes this, then this issue would be moot, because OpenVPN would not have to be running on multiple user profiles simultaneously. It would also have obvious improvements for battery/system performance. Do you think that's an option worth exploring?
Log (if applicable)
(Haven't been able to catch a log, as I'm not 100% sure when it happens. I think it might be when switching networks.)
Configuration files (same for both user profiles)