yes... as above 'quirks' (raspbian function excludes power issues)
no idea what this does... but if I were you i'd try it;
kmod-usb-roles
also you may wish to check for errors or probing issues;
dmesg | grep -C3 usb
Package kmod-usb-roles (5.4.113-1) installed in root is up to date.
Ill check for Power Issues with a active USB3 hub and tell you tomorrow.
Greetings
EC_Reboot
1 Like
Perhaps if you still have a Raspberry PI OS card where the drive worked, boot it up and post lsusb -t from there. if you can get a lsusb -v from that device on PI OS it would probably give a bit more info too.
Hi Guys!
As i wrote before, the SSD works on my Odroid XU4 running Raspbian.
So i post the Output of this Machine.
Sadly i do not have a powered USB3 hub (Amazon Package awaiting ...), so i could not test the SSD plugged in to a powered USB Hub.
I hope this helps:
lsusb -l:
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
dmesg:
[ 6.890756] usb 4-1.2: new SuperSpeed USB device number 3 using xhci-hcd
[ 6.911629] usb 4-1.2: New USB device found, idVendor=174c, idProduct=2362
[ 6.911640] usb 4-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber =1
[ 6.911646] usb 4-1.2: Product: Ugreen Storage Device
[ 6.911651] usb 4-1.2: Manufacturer: Ugreen
[ 6.911657] usb 4-1.2: SerialNumber: 193873440003
[ 6.937686] scsi host0: uas
[ 6.938391] scsi 0:0:0:0: Direct-Access SanDisk Extreme Pro 2TB 0 PQ: 0 ANSI: 6
[ 6.939478] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 6.939925] usbcore: registered new interface driver uas
[ 6.940224] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
lsusb -v:
Bus 004 Device 003: ID 174c:2362 ASMedia Technology Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.20
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x174c ASMedia Technology Inc.
idProduct 0x2362
bcdDevice 1.00
iManufacturer 2 Ugreen
iProduct 3 Ugreen Storage Device
iSerial 1 193873440003
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 121
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 4
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Data-in pipe (0x03)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Data-out pipe (0x04)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Status pipe (0x02)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Command pipe (0x01)
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 42
bNumDeviceCaps 3
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x0000f41e
Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 2047 micro seconds
** UNRECOGNIZED: 14 10 0a 00 01 00 00 00 00 11 00 00 30 40 0a 00 b0 40 0a 00
Device Status: 0x0001
Self Powered
1 Like
at this point... you would be best to create a thread on the general forum in probably the Hardware category called something like;
"UGREEEN 174c:2362 ASM2362 rpi4 [help]" or similar...
the reasons are;
- alot of talented people have likely 'ignored' this thread (too much irrelevant traffic) so don't see your posts
- it's looking like a general / 'official' support query from here... which is likely to benefit the whole community if/when resolved
Please link the most relavent post/s of yours within that thread... so people have easy access to the relevent info...
as requested... you may also wish to gather and post the (usb|block|scsi) results from dmesg on boot of OpenWrt...
once the fix is known/created... yes... i'm more than happy to do what I can to facilitate as many disk types within the build by default...
(if I did not say so already... removing usb-modeswitch is another long shot thing to try)
general notes:
-
lvm/raid etc. are exceptions as they add alot more bulk and typically will only be used by people who have the skills or need further custom settings... ( and they may be difficult to 'conditionally' turn off once installed )... however like most things... if there is a really cool use... that is reliable/transparent-ish/wanted by many... i'm always willing to reconsider on these grounds...
-
as stated before... while you can expand openwrt to fill the whole (single OS) drive... a better option is to use the extra drive via 'block-mount' to something like /storage... I can help with this.... or as @mk24 recommended in another thread... to create an additional partition beyond partion2(rootfs) which should persist after sysupgrade (have not physically tested this myself but have seen the sysupgrade code and should work fine I think). extroot-overlay is not supported in this build and even if it was... sysupgrade creates all sorts of requirements to transparently recreate on upgrade...
Thanx a Lot for your Help Wulfy!
Greetings!
EC_Reboot
1 Like
try this, updated 7 days ago
for your reading pleasure
Many thanks for the fw build I'm quite comfortable with your build openwrt rpi4. Can you add openwrt-passwall, or tell me how to install openwrt-passwall for rpi4b? Thanks you
1 Like
hmmm... never really heard of this...
you can probably start with a normal/new thread about this on the forum to discuss how to install or alternatives
1 Like
Thank you, I'm using other Fw for couple month that includes Passwall, clash,etc related to socks/v2ray. Currently I'm using your fw with wireguard for the vpn.
1 Like
one other has previously also mentioned this...
if there are a few users that want (anything)... then i'm willing to look into it further...
considerations/criteria for including stuff;
- how many people need it
- is it needed for internet connectivity
- how large is it
- is there an official package (or well supported opkg 'ipk' that is easy to add)
- can it be 'silenced' or made 'inert' for the people who do not use this functionality
in the case of 'v2ray/passwall' etc. it does seem like there may be some general interest... but my unfamiliarity with it makes it difficult to include in the build without more knowledge / testing...
one possibility medium term may be to have the 'build' scan attached usb devices during setup for 'ipk/packages' and install them...
you may wish to ask the developers of 'passwall' if they intend to;
- upstream / submit a PR to official openwrt for this package
- or if there is a regularly updated 'ipk' that is compatible with master/21.02
then we can wait and see if many others would be interested or if there are other ideas... and I can investigate further...
(note: there may be some pre-requisites in this case... like 'socks' type packages I can add now that also may help)
thanks for the suggestion... it's good to know what people use the build for... especially if those things are stuff that's totally new to me... 
ouch... in the case of v2ray... just testing an install...
- it's big... probably too big to install by default... although... there is a possibility to 'set it up/download' during firstboot... ( which would obviously happen over the normal connection )
-rw-r--r-- 1 root root 5.3M Jun 25 15:54 geoip.dat
-rwxr-xr-x 1 root root 16.5M Jun 25 15:54 v2ctl*
-rwxr-xr-x 1 root root 16.6M Jun 25 15:54 v2ray*
- there is no init.d start script... which in a way is good... because it is 'inert'... but may also be restrictive / ambigous / labourious / inconsistent for individuals to setup on their own... and I honestly couldn't provide 'support' for that...
in the case of 'passwall'...
- github does not seem to provide ipks/packages ( needs to be build with an SDK or BUILDROOT )
- seems to be a frontend / sit on top of v2ray ( so also large )
depends
LUCI_DEPENDS:=+coreutils +coreutils-base64 +coreutils-nohup +curl \
+dnsmasq-full +ipset +ip-full +ipt2socks +iptables-mod-tproxy \
+libuci-lua +lua +luci-lib-jsonc +microsocks +tcping +resolveip \
+unzip \
+PACKAGE_$(PKG_NAME)_INCLUDE_Brook:brook \
+PACKAGE_$(PKG_NAME)_INCLUDE_ChinaDNS_NG:chinadns-ng \
+PACKAGE_$(PKG_NAME)_INCLUDE_Dns2socks:dns2socks \
+PACKAGE_$(PKG_NAME)_INCLUDE_Haproxy:haproxy \
+PACKAGE_$(PKG_NAME)_INCLUDE_Kcptun:kcptun-client \
+PACKAGE_$(PKG_NAME)_INCLUDE_NaiveProxy:naiveproxy \
+PACKAGE_$(PKG_NAME)_INCLUDE_PDNSD:pdnsd-alt \
+PACKAGE_$(PKG_NAME)_INCLUDE_Shadowsocks_Libev_Client:shadowsocks-libev-ss-local \
+PACKAGE_$(PKG_NAME)_INCLUDE_Shadowsocks_Libev_Client:shadowsocks-libev-ss-redir \
+PACKAGE_$(PKG_NAME)_INCLUDE_Shadowsocks_Libev_Server:shadowsocks-libev-ss-server \
+PACKAGE_$(PKG_NAME)_INCLUDE_Shadowsocks_Rust_Client:shadowsocks-rust-sslocal \
+PACKAGE_$(PKG_NAME)_INCLUDE_ShadowsocksR_Libev_Client:shadowsocksr-libev-ssr-local \
+PACKAGE_$(PKG_NAME)_INCLUDE_ShadowsocksR_Libev_Client:shadowsocksr-libev-ssr-redir \
+PACKAGE_$(PKG_NAME)_INCLUDE_ShadowsocksR_Libev_Server:shadowsocksr-libev-ssr-server \
+PACKAGE_$(PKG_NAME)_INCLUDE_Simple_Obfs:simple-obfs \
+PACKAGE_$(PKG_NAME)_INCLUDE_Trojan_GO:trojan-go \
+PACKAGE_$(PKG_NAME)_INCLUDE_Trojan_Plus:trojan-plus \
+PACKAGE_$(PKG_NAME)_INCLUDE_V2ray_Plugin:v2ray-plugin \
+PACKAGE_$(PKG_NAME)_INCLUDE_Xray:xray-core \
+PACKAGE_$(PKG_NAME)_INCLUDE_Xray:xray-geodata
so;
- it's big ( needs to be installed during or after firstboot )
- it needs to be custom compiled?
- it's big
so... I guess if/when there is a reliable source for an ipk/package/s for this... some more testing or investigation may be possible...
2 Likes
hardening-nowan-reverted-temporarily
#two new options for the next build ( non-default add to /root/wrt.ini to enable )
HARDENING_DROPBEAR_NOWAN=1 #dropbear.@dropbear[0].nowan='1'
HARDENING_DNSMASQ_NOWAN=1 #dhcp.@dnsmasq[0].nowan='1'
HARDENING_UHTTPD_NOWAN=1 #uhttpd.main.nowan='1'
- note: not recommended for 'non-typical setups' but you free to test if you like
- note: does not currently support wan interfaces not labelled wan
- note: uhttpd does not support alternate ports at the moment
the ini parameters are firstboot only... but uci values can be added and service restarted... to force reapply of these ini parameters run;
/etc/custom/firstboot/53-hardening
1 Like
I opened a discussion on their repo and recommended manually compile because too many dependencies packages.
yes I tried the fw with passwall need time to finish all those.
it's the result of how many depend packages here, sad.
well there some alternative that worth it to try Openclash ofc they offered ipk and mentioned installing dependencies beforehand which is much easier than passwall, perhap.
1 Like
On a fresh install I have done the following to change the WAN macs.
- Goto Network -> Devices
- Click configure for the relevant devices
- Change mac
- Save & Apply -> Reboot
Result:
The macs show the new ones I have set in Network -> Devices but these changes are not applied to Network -> Interfaces - Here we still have the old macs.
My setup is a RPi4 2GB with a TP-Link UE300 USB 3.0 -> Ethernet adapter.
Screenshots: https://imgur.com/a/v4OasFK
1 Like
- build version?
(3.2 vs 3.1 have some network config differences... )
- if 3.2 did you upgrade to it or install from factory?
version: rpi-4_snapshot_3.2.13-2_r16904_extra
a fresh install from factory -> rpi4.64-snapshot-26363-3.2.13-2-r16904-ext4-fac.img.gz
1 Like
interesting...
( preface... that build is slightly beta... apologies I should have made that clearer on github ... you can start again with 3.1 (factory) if you are not up for a little config file editing )
specific-advice-compressed-verbage
now...
the 'migrated' (mine) VS the 'generated' (yours) have handled the 'device' sections differently... ( note: several changes / fixes have been committed since that 3.2 was build... but as imagebuilder is not working for a week or so... i've been unable to push anything newer )
see my config for reference;
**onfig interface 'loopback'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
option device 'lo'
config globals 'globals'
option ula_prefix 'fda9:424a:1c04::/48'
config interface 'lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option hostname 'router'
option delegate '0'
option ipaddr '10.2.3.1'
option device 'br-lan'
config interface 'mng'
option proto 'static'
option ipaddr '10.90.90.3'
option netmask '255.255.255.0'
option device 'eth0.90'
config interface 'wan'
option proto 'dhcp'
option hostname 'router'
option macaddr '00:11:32:96:42:65'
option macmatch 'd0:37:45:77:5c:13'
option vendorid 'fish'
option dhcpopts '42'
option device 'eth1'
config interface 'wan6'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix '56'
option device 'eth1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
note1: macaddr is left under interface ( which WORKS for my setup ) ( another forum thread suggests that it doesn't or doesn't of matching 'device' exists??? meh... next build should clarify... you can just copy what I have if you want a quick fix (ignore the 'macmatch' line)
note2: it's (generated-yours) created 'device' sections for non-bridge physical ifaces... neither here nor there but interesting that the migration did not do this...
hope that helps... let me know if something needs more clarification...
(note: when the next 3.2 is created(current master) I will test with your config and see what if any bugs are present/remain)
thanks for the really usefull feedback!
Thank you for the quick and thorough reply.
I have edited my config accordingly
- Removed all option macaddr
- Added option macaddr to wan6 and wan (both the same)
- Reboot
In the GUI I still see the old mac in Network -> Interfaces
Have I done something wrong?
NOTE: the rest of the mac is "smartly greyed out"
As new users are not allowed to post more then 3 replies to one topic I am editing this post to reply:
EDIT1: I have removed all config device except the one you have stated, still no change of the mac in Network -> Interfaces for Wan and wan6.
EDIT2:
I have applied the suggested changes to the config - upon reboot I get:
Here is the new config:
EDIT3:
I have used https://miniwebtool.com/de/mac-address-generator/ to generate the mac address, can you suggest a different one, that works for sure from your experience?
EDIT4:
Hmm if 3.2 is that experimental I might as well downgrade to 3.1
EDIT5:
Well I have now downgraded to 3.1 ^^, generated new macs with https://www.macvendorlookup.com/mac-address-generator - now wan and wan6 got the mac change applied 
- How did you test the macs, is there something we can use to prevent inserting potentially invalid macs in the future?
EDIT6:
I got all the macs changed now for lan, wan, wan6 - only the wireless one is not changing yet (have already tried 4 different macs - setting in Network -> Devices followed by a reboot.
EDIT7:
I was looking for a GUI way to do the change, when I did not find a possibility to change the mac in Network -> Wireless, I looked for one in Network -> Devices and there we can actually change it for lan (eth0) and wifi (wlan0). The change is being reflected properly for eth0 but not for wlan0.
1 Like