Closed rdmitry0911 closed 1 year ago
I noticed a strange records in system log:
Tue Nov 8 14:36:39 2022 daemon.debug dnsmasq-script[1]: /usr/lib/dnsmasq/dhcp-script.sh: .: line 5: can't open '/usr/share/libubox/jshn.sh': No such file or directory
Tue Nov 8 14:36:39 2022 daemon.warn dnsmasq[1]: script process exited with status 2
However, /usr/share/libubox/jshn.sh is there with correct access rights:
root@OpenMPTCProuter:~# ls -l /usr/share/libubox/jshn.sh
-rwxr-xr-x 1 root root 5457 May 18 01:11 /usr/share/libubox/jshn.sh
root@OpenMPTCProuter:~#
I have no idea if it is related to weak glorytun throughput issue, but it is abnormal too
Your configuration is strange with some macvlan, some direct,... You should start a fresh configuration. In the tracepath you have "192.168.40.1" multiple times. The IP shown in status pages for wan is the result of a request to the VPN so this is the IP of the router shown, should not be a big problem.
Your configuration is strange with some macvlan, some direct,...
It is because I have 2 lines on my roof with a direct connection and mobile from iphone I have indoors connected to a lan host.
In the tracepath you have "192.168.40.1" multiple times.
It's only with glorytun tcp vpn. With glorytun udp it is totally different:
root@OpenMPTCProuter:~# tracepath -n 9.9.9.9
1?: [LOCALHOST] pmtu 1442
1: 10.255.254.1 105.676ms
1: 10.255.254.1 84.861ms
2: 192.168.40.1 102.696ms
3: 172.16.44.1 83.862ms
4: 65.21.19.241 87.072ms
5: 213.239.224.125 112.591ms
6: 213.239.203.210 80.378ms
7: 185.1.160.109 137.729ms
8: 109.200.218.46 129.955ms
9: 188.122.80.228 122.205ms
10: 9.9.9.9 122.031ms !H
Resume: pmtu 1442
root@OpenMPTCProuter:~#
It looks good and pmtu is different.
Maybe mtu with glorytun tcp is calculated wrong way and this wrong mtu is a reason for the problem?
And a question about /usr/share/libubox/jshn.sh May it be tied to this problem, or it is a different bug and I have to open another issue?
You can try to set a lowest MTU on tun0 and check: ip link set mtu 1440 dev tun0
via SSH on the router.
You can try to set a lowest MTU on tun0 and check:
ip link set mtu 1440 dev tun0
I did a try. No help.
You should start a fresh configuration.
Is there a way to start over without a factory reset as I have some packages installed and I don't want to reinstall them all?
No but you can save installed package list when you do a backup.
No but you can save installed package list when you do a backup.
That's strange. Everything is written in config files. The packages itself are the regular ones. Why don't remove the config files related to the omr configuration leaving all the rest files in places? I'm going to reinitialize omr remotely without having direct access to the system and make a factory reset might leave me without an access to the system. Clearing config files would be much more safe procedure in this case.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days
Expected Behavior
Throughput via glorytun (default vpn for all protocols other than tcp) is about the same as with a regular tcp networking
Current Behavior
Throughput via glorytun is about 10 times less than a regular tcp networking->
Specifications
I have 3 internet lines: mobile, Starlink and fixed. All 3 are working good. I'm using the default configuration for everything. All the specifics is located only in /etc/config/network and in OMR bypass (both are attached). Nothing special in log files. However tracepath to 8.8.8.8 from OMR looks like this:
while from VPS it looks like this:
Tracepath via individual internet lines also looks fine:
Strange things on this picture are:
/etc/config/network:
/etc/config/omr-bypas