Entware / Entware

Ultimate repo for embedded devices
https://entware.net
Other
2.21k stars 154 forks source link

Bug: shadowsocks-libev-ss-local-aarch64 can't work with simple-obfs-client-aarch64 #300

Closed JACK-THINK closed 5 years ago

JACK-THINK commented 5 years ago

Bug: shadowsocks-libev-ss-local-aarch64 3.2.5-3 can't work with simple-obfs-client-aarch64

How can I download the previous version of shadowsocks-libev-ss-local-aarch64(3.2.3-9)?

Thanks

zyxmon commented 5 years ago

All previous package versions are in archive subfolder. It may be a pain to install packages from archive because of dependencies! It is much better to fix the curent version. But you need to give more info.

JACK-THINK commented 5 years ago

@zyxmon

The image below shows the problem. (shadowsocks-libev-ss-local-aarch64 3.2.5-3)

Snipaste_2019-06-03_18-41-25

With the shadowsocks-libev-ss-local-aarch64 3.2.3-9, everything works well as below

Snipaste_2019-06-03_19-02-11

zyxmon commented 5 years ago

Please contact the author of (shadowsocks-libev on this bug. We just compile (shadowsocks-libev in Entware.

JACK-THINK commented 5 years ago

@zyxmon

Although it's still unclear how to solve this problem, I tried to install shadowsocks-libev-server_3.2.5-1_x86_64.ipk from here and simple-obfs_0.0.5-1_x86_64.ipk from here on OpenWRT-18.06.2-x86-64(with only one LAN and no WAN) and everything works well.

zyxmon commented 5 years ago

Probably port on your asus router was already used We cannot solve the problem with the information you give.

JACK-THINK commented 5 years ago

@zyxmon

First of all, I'm sure the port is not being used at the moment I run ss-local -c config_local.json, since obfs-local will choose port to use randomly when it is invoked. If the port was being occupied accidently at the first time, at the second time I invoke obfs-local, the port would be unlikely occupied again.

Perhaps I can help you reproduce this issue.

If you have an ASUS router, no matter ASUSWRT or ASUS MERLIN runs on the router, just plug a blank USB flash drive in it and install SCRIPTS-BOOTLOADER-FOR-ASUS-ROUTER by invoking the code below, then you can reproduce this issue 100%. I've confronted this issue on both RT-AC68U and RT-AC86U.

cd /tmp && wget -O /tmp/install_online --no-check-certificate "https://raw.githubusercontent.com/JACK-THINK/SCRIPTS-BOOTLOADER-FOR-ASUS-ROUTER/master/script_bootloader/bin/install_online" && chmod 777 /tmp/install_online && /tmp/install_online
zyxmon commented 5 years ago

I do not have asus router. I guess there is something wrong with network configuration from Entware point of view. Probably "SCRIPT-...." modifies something essential.

JACK-THINK commented 5 years ago

@zyxmon

Actually, I'm the author of SCRIPTS-BOOTLOADER-FOR-ASUS-ROUTER. With previous version of shadowsocks-libev, everything works well. But with shadowsocks-libev 3.2.5 comes this issue. I just tried to replace it with shadowsocks-libev-ss-local-aarch64 3.2.3-9 again. Without any surprise, everything just goes well. As a consequence, I'm sure that something is wrong with shadowsocks-libev 3.2.5.

zyxmon commented 5 years ago

No changes were made to shadowsocks-libev. We have just updated the sources. May be some dependency update causes it. You can try this to force updated dependencies with - https://github.com/Entware/Entware/wiki#note-about-packages-upgrade You can also try to update dependencies manually.

JACK-THINK commented 5 years ago

@zyxmon

I also compile shadowsocks-libev 3.2.5 and simple-obfs 0.5 from source on CentOS-7(Linux CENTOS-7 3.10.0-957.12.2.el7.x86_64). And everything works well. Snipaste_2019-06-04_15-34-31

It seems that the source code of shadowsocks-libev 3.2.5 is OK. The problem may exist in the package you issue. Please check it.

I think you can refer to the source from openwrt-shadowsocks.

Thanks, I'll give it a try.

zyxmon commented 5 years ago

We use the sources from shadowsocks-libev developer with no patches or modifications. The dependencies (a dozen of them) may cause the issue. Please update the dependencies manually to check it. opkg system is not clever enough to update dependences correctly in all cases.

JACK-THINK commented 5 years ago

@zyxmon

I executed the code below.

opkg --force-depends remove shadowsocks-libev-ss-local
opkg --force-removal-of-dependent-packages remove shadowsocks-libev-*
opkg --force-removal-of-dependent-packages remove simple-obfs*
opkg update
opkg upgrade
opkg install simple-obfs
opkg install shadowsocks-libev-ss-local

After doing that, unfortunately, the problem still exists.

Since if I just replace shadowsocks-libev-ss-local 3.2.5 with shadowsocks-libev-ss-local 3.2.3-9, everything works well. If the problem existed in dependencies, shadowsocks-libev-ss-local 3.2.3-9 should have the same problem. Unless shadowsocks-libev-ss-local 3.2.5 has some new dependencies which aren't in Entware repo right now.

zyxmon commented 5 years ago

No dependency reinstallation from your log. You need further investigations and debuging with strace, ldd etc to localize the issue.

I have installed shadowsocks-libev on aarch hardware and have no issuу with similar config. I have not setup a server:

# ss-local -c /opt/etc/shadowsocks.json
 2019-06-04 12:24:52 INFO: plugin "obfs-local" enabled
 2019-06-04 12:24:52 INFO: initializing ciphers... aes-256-gcm
 2019-06-04 12:24:52 INFO: listening at 127.0.0.1:1080
No such file or directory
 2019-06-04 12:24:52 INFO: running from root user
 2019-06-04 12:24:52 ERROR: plugin service exit unexpectedly

You are to find ther reason of issue if you want it to be fixed in Entware.

JACK-THINK commented 5 years ago

@zyxmon

Actually, you're likely to have the same issue with mine.

Here's the config.json for test. All the parameters in the file are fake but in correct format, which is justified by the maintainer of shadowsocks-libev and me. You can just save the content below without any modification as test.json and invoke ss-local -c test.json.

{
    "server":"test.test.com",
    "server_port":"34343",
    "local_address":"0.0.0.0",
    "local_port":"3434",
    "password":"CCCCCCCC",
    "method":"aes-256-gcm",
    "timeout":60,
    "mode":"tcp_and_udp",
    "plugin":"obfs-local",
    "plugin_opts":"obfs=http;obfs-host=www.xxxxxxxx.com"
}

With shadowsocks-libev-ss-local 3.2.3-9, which runs well, you should get the information as below. Snipaste_2019-06-04_17-53-01

There should be no Error at all, unlike yours which contains the line below.

 2019-06-04 12:24:52 ERROR: plugin service exit unexpectedly

All above including your test prove that something is wrong with shadowsocks-libev-ss-local 3.2.5-3.

zyxmon commented 5 years ago

Please do more debuggung and investigations. It is useless just to state that something does not work.

zyxmon commented 5 years ago

IMHO This issue comes from shadowsocks-libev source code. Adding -v flag (verbose) to command line does not add any output but the binary continues to run.

JACK-THINK commented 5 years ago

@zyxmon

I don't know how to read the output of strace. Below is the output of strace.

odkrys commented 5 years ago

Change server to IP address instead of domain. https://github.com/shadowsocks/shadowsocks-libev/issues/2314

JACK-THINK commented 5 years ago

@zyxmon With parameter -v, shadowsocks-libev-ss-local_3.2.3-9 can add only 1 line as below

Snipaste_2019-06-04_19-01-16

As stated by @odkrys , this issue is a bug in the source of shadowsocks-libev_3.2.5-3. Because of it, I think it's better to replace shadowsocks-libev_3.2.5-3 with shadowsocks-libev_3.2.3-9 in Entware repo until the bug is solved.

@odkrys With your method, after changing domain to IP, everything goes well with shadowsocks-libev-ss-local__3.2.5-3_aarch64.

But I still don't understand why shadowsocks-libev-ss-local_3.2.5-3_x86-64(PC, CentOS-7) can work well with domain in config.json, but shadowsocks-libev-ss-local_3.2.5-3_aarch64-k3.10(arm64 router) or shadowsocks-libev-ss-local_3.2.5-3_armv7sf-k2.6(arm router) can't.

@zyxmon @odkrys Thanks a lot for your time on this issue.