Próbowałem już na różnorakie sposoby, z przedłużkami (to takie króciutkie 30cm bo router stoi portami do ściany), bez, do pierwszego lub drugiego portu, w parze z innym urządzeniem na drugim USB i bez. Wg moich obserwacji niczego to nie zmienia. Teraz wrzuciłem OpenWRT 18.06.0 i w ogóle jest masakra, za każdym razem po podpięciu modemu jest reboot, a jak się nie wyjmie to router się zachowuje jakby złapał bootloopa. Myślałem żeby jeszcze spróbować downgrade na 17.01.6 ale tu trzeba serial lub mtd i dzisiaj już mi się nie chce.

Zuzia a masz może jeszcze te źródła?

r8082 pobrałem w piątek, ale zdecydowałem nie grzebać przed weekendem (nie wiedziałem wtedy jeszcze, że tak wygląda sprawa że snapshotem), zainstalowałem w poniedziałek no i wspomniany problem z zależnościami. On był na kernelu 4.14.70 coś

Później wrzuciłem r8121, który kernel miał też niedużo wyższy (też jakoś 4.14.70coś) i nie działało.

Wnioskuję po tym, że r8082 pewnie też by nie działał i chyba jedyną szansą jest wersja o której mówisz, że u Ciebie działa czyli r8064 tylko bez źródeł systemu i pakietów mogę pomarzyć o przetestowaniu czy to by u mnie też zadziałało.

Ew. jeszcze mogę spróbować downgrade do lede.

Już miałem Cię prosić o pomoc, jednak z tą komendą wszystko pykło elegancko i sobie sam skompilowałem, dzięki Czyli jednak ze źródeł wszystko sobie można w razie czego skompilować, źródła nawet te z których powstają snapshoty zostają na gicie.
Tu niestety jest koniec dobrych informacji, bo ostatecznie nic to nie dało. Jest tak jak na najnowszym 18.06.1, nie przydziela adresu i nie idzie nawet zpingować modemu, interfejs eth1 bez IP, jak się ustawi statycznie to i tak modemu nie zpingujesz, sporadycznie restarty routera.
Log:

Wed Sep 26 22:52:44 2018 kern.info kernel: [  341.596157] usb 1-1: new high-speed USB device number 2 using dwc2
Wed Sep 26 22:52:45 2018 kern.info kernel: [  341.811726] usb-storage 1-1:1.0: USB Mass Storage device detected
Wed Sep 26 22:52:45 2018 kern.info kernel: [  341.818399] scsi host0: usb-storage 1-1:1.0
Wed Sep 26 22:52:45 2018 kern.info kernel: [  342.256728] usb 1-1: USB disconnect, device number 2
Wed Sep 26 22:52:46 2018 kern.info kernel: [  342.836235] usb 1-1: new high-speed USB device number 3 using dwc2
Wed Sep 26 22:52:46 2018 kern.info kernel: [  343.057740] cdc_ether 1-1:1.0 eth1: register 'cdc_ether' at usb-1e101000.usb-1, CDC Ethernet Device, 0c:5b:8f:27:9a:64
Wed Sep 26 22:52:46 2018 kern.err kernel: [  343.080409] cdc_ether 1-1:1.0 eth1: kevent 12 may have been dropped
Wed Sep 26 22:52:46 2018 kern.err kernel: [  343.086688] cdc_ether 1-1:1.0 eth1: kevent 11 may have been dropped
Wed Sep 26 22:52:46 2018 kern.err kernel: [  343.102700] cdc_ether 1-1:1.0 eth1: kevent 11 may have been dropped
Wed Sep 26 22:52:46 2018 daemon.notice netifd: Interface 'wan3g' is enabled
Wed Sep 26 22:52:46 2018 kern.info kernel: [  343.110431] usb-storage 1-1:1.2: USB Mass Storage device detected
Wed Sep 26 22:52:46 2018 kern.info kernel: [  343.144389] scsi host0: usb-storage 1-1:1.2
Wed Sep 26 22:52:46 2018 daemon.notice netifd: Network device 'eth1' link is up
Wed Sep 26 22:52:46 2018 daemon.notice netifd: Interface 'wan3g' has link connectivity
Wed Sep 26 22:52:46 2018 daemon.notice netifd: Interface 'wan3g' is setting up now
Wed Sep 26 22:52:47 2018 daemon.notice netifd: wan3g (3892): udhcpc: started, v1.29.3
Wed Sep 26 22:52:47 2018 kern.notice kernel: [  344.158823] scsi 0:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
Wed Sep 26 22:52:47 2018 kern.notice kernel: [  344.177934] sd 0:0:0:0: [sda] Attached SCSI removable disk
Wed Sep 26 22:52:47 2018 daemon.notice netifd: wan3g (3892): udhcpc: sending discover
Wed Sep 26 22:52:47 2018 daemon.info avahi-daemon[2849]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::e5b:8fff:fe27:9a64.
Wed Sep 26 22:52:47 2018 daemon.info avahi-daemon[2849]: New relevant interface eth1.IPv6 for mDNS.
Wed Sep 26 22:52:47 2018 daemon.info avahi-daemon[2849]: Registering new address record for fe80::e5b:8fff:fe27:9a64 on eth1.*.
Wed Sep 26 22:52:50 2018 daemon.notice netifd: wan3g (3892): udhcpc: sending discover
Wed Sep 26 22:52:52 2018 daemon.err block: Unkown action change
Wed Sep 26 22:52:52 2018 daemon.err block: Unkown action change
Wed Sep 26 22:52:53 2018 daemon.notice netifd: wan3g (3892): udhcpc: sending discover
Wed Sep 26 22:53:44 2018 authpriv.info dropbear[4241]: Child connection from 192.168.1.2:61835
Wed Sep 26 22:53:50 2018 authpriv.notice dropbear[4241]: Password auth succeeded for 'root' from 192.168.1.2:61835

Po tym doświadczeniu wnioskuję, że jakby wszystko było ok z routerem i modemem to i na najnowszym by działało. Możesz sobie zrobić backup mtd i zobaczyć czy na najnowszym będzie Ci wszystko działać, w razie czego sobie przywrócisz, no chyba że nie potrzebujesz.
Wychodzi na to, że jednak coś hardwareowo z routerem, albo jednak mimo wszystko te firmware w modemie się jakoś z tym gryzie, chyba jeszcze spróbuję zflashować modem. Downgrade do lede raczej nie ma sensu. Na 18.6.0 faktycznie jest tragedia, ale wygląda na to że od commita z tą wersją którą opisujesz jest to naprawione a u mnie jeszcze coś innego powoduje problem.

Jeśli to niewydajność prądowa to hub aktywny powinien załatwić sprawę?

Też na początku myślałam, że mój router nie pociągnie e3372 jednak pod LEDE wszystko funkcjonowało stabilnie więc uznałam, że powinno również działać z OpenWRT 18.06, to tylko kwestia wersji i sprawdzałam do skutku. W wolnej chwili rzucę okiem na nowsze snapshot-y i jeśli będzie OK to dam znać.

Mam najnowszą wersję e3372h z Play, jest to hilink, działa jak karta sieciowa, zgłasza się pod 192.168.8.1. Na tej wersji przerabiałam opisywane problemy - restarty, niemożność pobrania adresu przez DHCP więc chyba bug dotyczył ogólnie e3372 pracujących w tym trybie.

Dowiedziałam się, że po przełączeniu modemu pracuje normalnie pod 18.06, ale nie próbowałam, bo muszę mieć hilink ze względu na słaby procesor w moim routerze, a podwójny NAT mi nie przeszkadza.

LEDE to normalne OpenWrt, po prostu to wydanie nazywało się inaczej.