No DHCP address on Model T31 with UCTRONICS

[Telain]

I got a https://amazon.com/dp/B0B9ZLVGJ4 (UCTRONICS Upgraded ... Micro USB to Ethernet/PoE Adapter) and before shipping it back for not working, I want to see if there's additional troubleshooting I should do.

I successfully get WIFI on wz_mini with the camera, but obviously can't access it when I try to enable the ethernet. I did see a MAC address on my switch for the ethernet adapter, but the logs just spam that there's no IP. I tried manually loading the cdc_ether driver, but didn't get anything in that case.

Is there any way I can enable ethernet to test the module and get feedback without disabling the wifi?

#####S03ethernet#####
Auto-Detect an Ethernet Driver and load it
Loading Realtek RTL8152 driver...
Manually load any other Ethernet Drivers if asked for
cat: can't open '/sys/class/net/eth0/address': No such file or directory

: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds

lsusb
Bus 001 Device 002: ID 0bda:8152
Bus 001 Device 001: ID 1d6b:0002

[Telain]

Okay, I've managed to manually load the device drivers by poking through the initialization.

KMOD_PATH="/opt/wz_mini/lib/modules/3.10.14__isvp_swan_1.0__"
insmod $KMOD_PATH/kernel/drivers/net/usb/usbnet.ko
modprobe r8152
ifconfig eth0 hw ether 00:15:d5:00:00:01
ifconfig eth0 up
udhcpc -i eth0

Now I have an Ethernet IP, so why isn't it working when it does it on its own?

[Telain]

And now it's working after a reboot, but with the MAC I assigned before (00:15:d5:00:00:01). How can I recover the proper MAC address, and can I do anything to help find why assign it properly the first time?

[Bob-AOL]

Wish I had the answer because I have what is basically the same problem. But first, these adapters work great once they are properly initialized. Not exactly plug'n'play, but relatively easy to get up and running once you realize it isn't the camera and needs its own IP address for its own MAC address.

That said....

After successfully initializing four of these adapters (the 'bad' ones at that) I've encountered a similar issue to yours trying to set up two new V3s for USB ethernet/POE using one of the known good adapters -- which already has a reserved IP address in my router/dhcp server mapped to its MAC address.

After enabling USB ethernet while the camera is in wifi mode (with the adapter in place) and rebooting to initialize the dhcp process for obtaining the adapter address, it simply hangs in the boot process and never grabs the address. The Wyze app and my monotoring app still show the wifi address as active (which it is), but wz_mini doesn't seem to have loaded as the camera is otherwise none-functional and non-reachable and requires a reboot without the SD card to again become accessible in wifi mode.

I might add that I'm using (used?) the config editor in the web interface to enable the USB/Eth function and find (found?) it an incredibly convenient and efficient method of activating the feature. My wz_mini.conf is pre-configured with only my RTSP requirements, a unique host name and the web server to enable the USB/Eth feature. Doesn't get much simpler than that and has worked fine for the purpose until now.

I'll also add that this is a Windows implementation and my Linux chops are pretty limited for anything much deeper than trial and error troubleshooting.

I'm back at it this morning and will attempt an SSH approach to enabling the USB/Eth feature bypassing the web tool, but this certainly seems like a new bug that needs attention regardless.

@gtxaspec, @virmaior ?

[virmaior]

all of my cameras are using usb direct so I don't actually know anything about the usb eth setup.

the two are similar, however, and there's supposed to be a wait loop that waits for the eth device to go up in 5 second increments or so...

@Telain what do you mean by. How can I recover the proper MAC address ? Do you mean the USB ethernet adapter's factory mac address?

[Telain]

Yes, I didn't have any luck finding a command that worked on wz_mini_hacks, and was hoping to avoid having to move it to my tablet to see what MAC it gets.

[virmaior]

@Telain you should be able to just skip the ifconfig eth0 hw ether 00:15:d5:00:00:01 line and then it should use its default -- assuming it has one.

[Telain]

I haven't reentered that command on reboots since, but it's still using the 0015 MAC. I'll just have to resort to my tablet to check it and issue the command again to set it to what it should be.

[Bob-AOL]

The dhcp discovery of the camera should do all of this when rebooted from wifi mode with the adapter attached and after the USB/Eth feature has been enabled in wz_mini.conf. Enabling USB/Eth must be done with the camera online in wifi mode. When rebooted as such with the adapter attached, the camera should then make the dhcp request which will assign an IP address to the adapter MAC address and disable wifi functionality. The Wyze app itself will show the MAC and IP addresses of the adapter when successfully established. I use Analiti as an additional verification tool which provides several other pieces of information after a successful implementation.

[Bob-AOL]

I can't get wz_mini to load at all after enabling USB/ETH and rebooting -- which should initiate the dhcp request for the adapter and bring the cam up on the wired network. Need to shut down and pull the card to get it back online.

Interestingly, two hostnames seem to remain even after rebooting without the SD card -- WZ Mini and WZ Mini Web Tools.

This used to be easy. No wonder so many folks think their adapters are bad.

[Bob-AOL]

I misspoke about the Wyze app showing the MAC address of the adapter. It shows the IP address of the adapter, but the wifi MAC address of the camera remains. The adapter MAC address requires external identification.

[Bob-AOL]

After successful initialization of the UCTRONICS adapter as displayed with both the Wyze app and Analiti analyzer showing their respective results. Note the original inactive MAC remains in the Wyze app (along with disabled wifi) but is properly identified as the Realtek hardware in the Analiti app. Both correctly display the IP address of the adapter with Analiti offering additional useful details to confirm a successful initialization of the adapter. Great little app if you haven't tried it. Much, much more than just another Android speed test.

Anyway, I'm still pissing up a rope with this and broke down and tried dusting off my Wireshark chops. Boy has it changed and boy am I rusty on top of it. Near as I can figure so far (and as seems evident with the endless 'try again in 5 seconds' loop), we're missing dhcp discovery after activating the USB/ETH feature and rebooting. May be worth digging into by someone with better chops. Aside from that, I'm also stuck on SSH authentication to try editing wz_mini.conf with Nano to eliminate the possibility that editing the file with the web script may itself be the problem. Lots of changes to wz_mini in general since my last batch of successful adapter fire-ups. None seem to have made it any easier to initialize the adapters.

POE USB ethernet for these cams is the reason most folks gravitate here. It's certainly why I recommend they do and why I've spent as much time as I have promoting the UCTRONICS adapter -- because it works flawlessly when properly initialized and _wz_mini cooperates!_.

[Bob-AOL]

@virmaior @gtxaspec

I think I can safely say that the web config editor is not applying changes to the wz_mini.conf file unless the camera is rebooted via the web-based reboot command which also seems to save the changes. Modifying the .conf file via the web config editor and rebooting the camera from the Wyze app (as has been my successful method in the past) simply results in the camera rebooting with the existing configuration being re-applied. Rebooting from the web interface saves the changes to the file as observed directly from the removed SD card, but essentially just seems to kill wifi and never establishes wired connectivity or loads wz_mini at all.

And while I've been successfully able to ssh to the wz_mini.conf file to edit, I now find myself confronted with a read-only file system that will not allow me to save any edits to the file. Talk about frustration.

Any chance this could be looked into? Initializing one of the UCTRONICS adapters used to be a simple process which now seems to no longer be the case.

Thanks for any time you may be able to spare for this. Something has clearly changed since my last round of adapter initializations. And yes, the adapters are two known good adapters.

[Bob-AOL]

Managed to get ssh working to edit wz_mini.conf live and then reboot to initialize dhcp discovery to bring up the adapter. The file edits are successful and wifi is disabled but the camera does not come back up on the adapter.

Since I now have editing capability via ssh, I'm not as concerned with the web tool issue as why the adapters are no longer being recognized even when going about everything in recommended Linux fashion.

Any assistance will be tremendously appreciated.

[Bob-AOL]

The UCTRONICS comes right up on my laptop. I'm guessing something is amiss with the driver configuration that is not picking up where the wifi leaves off in wz_mini? The camera simply becomes un-reachable until pulling the SD card to re-activate wifi. It tries, but never even spits out a DHCP discovery packet after enabling USB/ETH. And FWIW, the time and date stamps on things are all over the map way ahead in time..., like tomorrow. Not sure how that may be affecting certain functions, but a conflict here and there (everywhere?) can't be good to keep anything in sync that may require it.

'C'mon fellas. The UCTRONICS is the logical answer to the adapter question at every level if the initialization issue can get ironed out for a simple and dependable solution that just works..., which it does when wz_mini tells a dhcp server it's now on the network as an ethernet device in need of some new and well-deserved respect.

Forgive my frustration. I apologize if I'm coming off as unappreciative or contentious. What you do is magic to me and I'm only trying to help by my obviously limited means of throwin' whatever seems like it may stick at the wall trial and error process of elimination parts swapping slam the hood harder next time and maybe it'll actually start methodology...., for lack of a better description. That said, I have dusted off some command line cobwebs and Wireshark chops to also look at this from a previous life as a broadband network guy, so it's not all just hollering and headbanging. I'm trying contribute where I think I can.

Anyway, the UCTRONICS adapters are wonderful for the v3s and a perfect compliment to wz_mini when they work. This one works just fine...., just not with wz_mini on a v3.

[Bob-AOL]

I'm not quite certain how, (I have an idea or two), but the initializations began to be successful again today. See #441

[Bob-AOL]

A little late, but just to close out my "offerings" above, I ultimately traced my issues to the card reader in the particular camera under test which also seemed to create subtle and random corruption of the card itself. This made effective troubleshooting impossible resulting in chasing my tail with extreme frustration.

Discovering the problem with the card reader and moving on to a different camera and SD card yielded the expected (and repeatable) results I've become accustomed to when initializing UCTRONICS adapters.

Apologies for aspersions cast.

[xconverge]

@Telain were you able to get up and going and stay running? I have reproduced a lot of your findings, however I haven't been able to get anything to stick past a reboot.

[Bob-AOL]

All of my UCTRONICS devices are working flawlessly with my v3s. Start with a clean wz_mini.conf file. If you can successfully boot the camera from the SD card loading wz_mini, your adapter should be easily initialized by simply enabling usb and auto-detect live online via ssh and rebooting the camera for the changes to be applied. Use the Wyze app for convenience to learn the new IP address of the adapter once the reboot process completes. You may need to do a second restart from the app for the new address to appear. Be patient. Cloud delay can take a couple of minutes to resolve. The camera's wi-fi IP address and MAC address are no longer relevant and are replaced on the network by that of the ethernet adapter (though the old MAC address will remain in the camera's app and the adapter's will need to be determined by other means.) The camera is now a completely new device on the network.

[xconverge]

@Bob-AOL thanks for trying to help, I have seen you post the same thing several times, and I am glad it works for you. There is something more detailed/advanced going on that I am trying to debug

wz_init.log shows bad stuff happening after the attempt to change to use the ethernet adapter. If I disable using the ethernet adapter, I can run through the commands from above that @Telain ran (after looking through the init scripts as well myself)

KMOD_PATH="/opt/wz_mini/lib/modules/3.10.14isvp_swan_1.0" insmod $KMOD_PATH/kernel/drivers/net/usb/usbnet.ko modprobe r8152 ifconfig eth0 hw ether 00:15:d5:00:00:01 ifconfig eth0 up udhcpc -i eth0

and can then get an IP address, but I can't get anything to stick past a reboot and am getting tired of swapping the SD card back and forth haha

welcome to wz_init.sh
PID 1

 __          ________  __  __ _____ _   _ _____
 \ \        / |___  / |  \/  |_   _| \ | |_   _|
  \ \  /\  / /   / /  | \  / | | | |  \| | | |
   \ \/  \/ /   / /   | |\/| | | | | . ` | | |
    \  /\  /   / /__  | |  | |_| |_| |\  |_| |_
     \/  \/   /_____| |_|  |_|_____|_| \_|_____|
                  ______
                 |______|

#####S01bind#####
Replace stock busybox
Replace stock fstab
Replace stock inittab
Replace /etc/profile for local/ssh shells
Mount kernel modules in /lib
Replace system hostname
#####S02tmpfs#####
Mount wz_mini tmpfs
Create workspace directory
Mounting global tmpfs
#####S03busybox#####
Install busybox applets
#####S04model#####
WYZE_CAKP2JFUS detected
#####S05mount#####
mounting /system
Current Mounts:
rootfs on / type rootfs (rw)
devtmpfs on /dev type devtmpfs (rw,relatime,size=46572k,nr_inodes=11643,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/mmcblk0p1 on /opt type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mtdblock2 on / type squashfs (ro,relatime)
/dev/mmcblk0p1 on /bin/busybox type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mmcblk0p1 on /etc/fstab type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mmcblk0p1 on /etc/inittab type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mmcblk0p1 on /etc/profile type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mmcblk0p1 on /lib/modules type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mmcblk0p1 on /etc/hostname type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /opt/wz_mini/tmp type tmpfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
/dev/mtdblock3 on /system type squashfs (ro,relatime)
#####S06car#####
Checking for CAR FW
#####S07inject#####
Copy stock rcS
Add verbose debugging to rcS
Inject init.d scripts to rcS
Modify Global Paths in rcS
Copy factory app_init.sh
Replace factory app_init.sh path
Enable libcallback
set path for iCamera
#####S08passwd#####
Replace stock password
#####S09firstboot#####
First boot already completed
#####S10kmod#####
Enable 8189fs
Enable atbm603x_wifi_sdio
#####S11configbackup#####
Factory config backup directory missing
T31 platform backup
Factory configs backup directory present, not backing up again
#####S12ssh#####
Running dropbear ssh server
#####S14terminfo#####
Terminfo already present
#####S15fwupdate#####
Current stock firmware version:
[VER]
appver=4.36.9.139
/opt/wz_mini/etc/init.d/S15fwupdate: line 74: [-f: not found
#####S16factorycheck#####
Replace factorycheck with dummy, to prevent bind unmount
#####S18ntp#####
#####S20initsetup#####
#####S21killmisc#####
#####S30patchicamera#####
Reverting iCamera patch.
Removed.
+ echo /sbin/mdev
+ /sbin/mdev -s
+ echo 'mdev is ok......'
mdev is ok......
+ echo ' __________________________________
|                                  |
|                                  |
|                                  |
|                                  |
| _   _             _           _  |
|| | | |_   _  __ _| |     __ _(_) |
|| |_| | | | |/ _| | |  _ / _| | | |
||  _  | |_| | (_| | |_| | (_| | | |
||_| |_|\__,_|\__,_|_____|\__,_|_| |
|                                  |
|                                  |
|_____2020_WYZE_CAM_V3_@HUALAI_____|
'
 __________________________________
|                                  |
|                                  |
|                                  |
|                                  |
| _   _             _           _  |
|| | | |_   _  __ _| |     __ _(_) |
|| |_| | | | |/ _| | |  _ / _| | | |
||  _  | |_| | (_| | |_| | (_| | | |
||_| |_|\__,_|\__,_|_____|\__,_|_| |
|                                  |
|                                  |
|_____2020_WYZE_CAM_V3_@HUALAI_____|

+ export 'PATH=/bin:/sbin:/usr/bin:/usr/sbin:/opt/wz_mini/bin'
+ export 'PATH=/system/bin:/bin:/sbin:/usr/bin:/usr/sbin:/opt/wz_mini/bin'
+ export 'LD_LIBRARY_PATH=/system/lib:/opt/wz_mini/lib'
+ export 'LD_LIBRARY_PATH=/thirdlib:/system/lib:/opt/wz_mini/lib'
+ ifconfig lo up
+ mount -t squashfs /dev/mtdblock3 /system
mount: mounting /dev/mtdblock3 on /system failed: Resource busy
+ mount -t jffs2 /dev/mtdblock6 /configs
+ /opt/wz_mini/etc/rc.d/K03rcd
+ /opt/wz_mini/etc/rc.d/K01network
#####S01swap#####
Swap archive missing, not extracting
Swap file found, enable
ifconfig: wlan0: error fetching interface information: Device not found
K01network: Network HW not ready yet, try again in 5 seconds
#####S03ethernet#####
Auto-Detect an Ethernet Driver and load it
Loading Realtek RTL8152 driver...
Manually load any other Ethernet Drivers if asked for
cat: can't open '/sys/class/net/eth0/address': No such file or directory
#####S04usbdirect#####
USB Direct disabled
USB RNDIS disabled
S06networkalt: wpa_supplicant not initialized yet, try again in 5 seconds
S09coredump: wpa_supplicant not initialized yet, try again in 5 seconds
#####S10firmware#####
Firmwware updates enabled, monitor script running
#####S14nightdrop#####
#####S17motor#####
Motor enabled
#####S18fps#####
Seting system FPS if greater than default
sh: 20: unknown operand
sh: 20: unknown operand
+ /opt/wz_mini/tmp/.storage/app_init.sh
#############ubootddr = 600.000MHz ########
################## to wait wifi vendor id ####################
################## [vendor:0x007a] atbm603x wifi ###################
(O _ o) welcome to the config file repair script [start part]!
(O _ o) this is valid mac!
(O _ o) set [/configs/.product_config] to read-only!
(O _ o) to mount kback...
(^ _ ^) kback mount ok!
(O _ o) found the md5 file in kback! [/mnt/MD5.6202a99abc6245907ace2d00c17326af.config]
(O _ o)  real  md5 is [6202a99abc6245907ace2d00c17326af]
(O _ o) record md5 is [6202a99abc6245907ace2d00c17326af]
(^ _ ^) check md5 file [/mnt/MD5.6202a99abc6245907ace2d00c17326af.config] is ok!
(^ _ ^) the md5 file in kback is ok!
(- _ -) to umount kback...
(- _ -) i will exit!
Updating device time to:
Fri May 13 20:22:36 UTC 2022
===========welcome to ver-comp tool=========
[ver-comp]dbg: appver:  4.36.9.139
[ver-comp]dbg: rootver: 4.36.3.19
[ver-comp]exec cmd: cp -rf /system/bin/app.ver /configs/
#######################
#   IS USER PROCESS   #
#######################
[FC] mount tfcard finish!
[FC] Test.tar no exist
[FC] umount tfcard finish!
[FC] In [user] mode!
kernel.core_pattern = |/system/bin/ucoredmp_collector.sh --pid %p --signal %s --name %e --time %t --output-dir /media/mmc/cores
kernel.core_pipe_limit = 1
net.unix.max_dgram_qlen = 128
#####S01wlanhw#####
Waiting for wlan hw init
#####S03ipv6#####
net.ipv6.conf.all.disable_ipv6 = 1
ipv6 disabled
#####S04wireguard#####
Wireguard disabled
#####S08hostname#####
Set hostname to WCV3
: IP Address not acquired yet, try again in 5 seconds
#####S10httpd#####
httpd enabled
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
S14storemac: wpa_supplicant not initialized yet, try again in 5 seconds
S06networkalt: wpa_supplicant not initialized yet, try again in 5 seconds
S09coredump: wpa_supplicant not initialized yet, try again in 5 seconds
#####S13mp4write#####
mp4_write disabled
#####S21syslog#####
: IP Address not acquired yet, try again in 5 seconds
#####S14storemac#####
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
store original mac
#####S15v4l2rtspserver#####
rtsp hi_res disabled
rtsp low_res disabled
#####S16rtmp#####
K01network: IP Address not acquired yet, try again in 5 seconds
#####S06networkalt#####
Renaming interfaces
#####S09coredump#####
Killing dumpload
Setting kernel core pattern
: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
: IP Address not acquired yet, try again in 5 seconds
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
S12remoteaccessory: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
K01network: IP Address not acquired yet, try again in 5 seconds
ifconfig: wlan0: error fetching interface information: Device not found
: IP Address not acquired yet, try again in 5 seconds

[Telain]

I don't understand why but my camera has kept the MAC I manually assigned through reboots.

[xconverge]

I don't understand why but my camera has kept the MAC I manually assigned through reboots.

Interesting, then you just enabled the usb adapter flag and the the autodetect flag and it continues to work?

Also do you use a poe injector or poe switch?

I plugged the adapter into a pi zero w and it came up instantly with an IP so I think the adapter is fine. I will play with the init scripts a bit to see if I can get things going in an order that persists

[Telain]

Correct. After I gave it a MAC, I haven't had any problems enabling the USB ethernet with auto detect.

[xconverge]

This logic changed a bit as part of a refactor and I wonder if we just need to spin for a cycle or two as HW comes up for certain HW.

I will play around more and see

before: https://github.com/gtxaspec/wz_mini_hacks/blob/fcf827118d240b6e658d937e07b993ae4e59e197/SD_ROOT/wz_mini/etc/init.d/wz_user.sh#L349

after: https://github.com/gtxaspec/wz_mini_hacks/pull/216/commits/0702bb997c9a909846487e95b63f197b02f9b723#diff-768d694019649b2ed800d1826268ce9f1bb26cce89d2303458188164fd2456f3R49

[Bob-AOL]

@xconverge > am getting tired of swapping the SD card back and forth haha

From where to where and why? They do become less and less reliable over time -- especially in and out of cheesy card readers in cheesy little cameras!

May want to try a fresh card and a new and unmolested version of the distro in the most basic form possible just to cover those bases. May also want to fire up Wireshark and see what's happening on ports 67 and 68 as observed from the wi-fi IP address of the camera as you reboot to initialize discover for the adapter. This must occur as a soft reboot with the adapter already attached to the camera and the network. A power cycle restart will simply disable the wi-fi driver if ETH has been already enabled in wz_mini.conf. Consequently a discover request will not occur nor an IP address be obtained for the adapter and the camera will not completely boot since it still thinks it needs an IP address for the hard coded MAC.

And if I'm being repetitive, forgive me. The process works when implemented as designed on devices that don't otherwise have hardware or firmware issues of their own. Sometimes it's just a 'forest for the trees' kinda thing.

[xconverge]

I need to swap the sd card to make changes and check logs when the swap from wifi to Ethernet fails because I am left with no means to ssh to it.

I understand Linux and networking enough to understand where to look and what to try. Telling people that it works is not helpful more than once or twice. I will report back any findings next time I look at it

[Bob-AOL]

I need to swap the sd card to make changes and check logs when the swap from wifi to Ethernet fails because I am left with no means to ssh to it.

There's your problem.

[Bob-AOL]

Are you initially making your changes and rebooting online via ssh?

[Bob-AOL]

Just trying to help, dude. You're missing something very, very simple or it would work.

By all means keep us posted on your progress.

[xconverge]

Ok, progress

I changed the end of S03ethernet to the following, note that cat /sys/class/net/eth0/address outputs all 0's for my device, I suspect the "upgrade" uctronics version has some sort of change that impacts this

...

        echo "Manually load any other Ethernet Drivers if asked for"
        if [[ "$ENABLE_USB_ETH_MODULE_MANUAL" != "" ]]; then
            for i in $(echo "$ENABLE_USB_ETH_MODULE_MANUAL" | tr "," "\n"); do
                insmod $KMOD_PATH/kernel/drivers/net/usb/$i.ko
            done
        fi

        echo "Sleeping..."
        sleep 30
        echo "Done sleeping ..."

        echo "Detected MAC as ..."
        cat /sys/class/net/eth0/address

        MAC_ADDR="00:15:d5:00:00:01"
        echo $MAC_ADDR | tr '[:lower:]' '[:upper:]' >/opt/wz_mini/tmp/eth0_mac

        echo "Hardcoded MAC to "
        cat /opt/wz_mini/tmp/eth0_mac

        ifconfig eth0 hw ether $MAC_ADDR
        ifconfig eth0 up

        echo "ifconfig eth0 up completed"

    else

        echo "USB Ethernet disabled"
    fi
    ;;
*)
    echo "Usage: $0 {start}"
    exit 1
    ;;
esac

Here is the log statements:

#####S03ethernet#####
Auto-Detect an Ethernet Driver and load it
Loading Realtek RTL8152 driver...
Manually load any other Ethernet Drivers if asked for
Sleeping...
ifconfig: wlan0: error fetching interface information: Device not found
K01network: Network HW not ready yet, try again in 5 seconds
Done sleeping ...
Detected MAC as ...
00:00:00:00:00:00
Hardcoded MAC to
00:15:D5:00:00:01
ifconfig eth0 up completed

I will be running some more tests/uptime/reliability, but this is progress, and is certainly something that needs to/could be addressed in the init scripts for this HW. I suspect just some robustification

[xconverge]

I get a dropout after a few minutes after boot ~5 minutes, has happened twice so far. I think I am going to chalk this up to...not worth it for now

[Bob-AOL]

Is it possible the controller in the upgraded devices is no longer a Realtek? Their prefix is 00:e0:4c...

[xconverge]

per the original post (which I am experiencing as well and why I posted this here)

I also get

lsusb
Bus 001 Device 002: ID 0bda:8152
Bus 001 Device 001: ID 1d6b:0002

so I am 90% sure it is a realtek 8152, and the fact that I can bring it up with the modprobe of 8152 tells me yes,..

[bjs-pdx]

I've been trying to get one of these to work without success. But here is some of what I have discovered. I've connected the newer version of the adapter (UC-3AF-USBEthernet-01) and find that on an Ubuntu laptop and on a Raspberry PI nano it never comes up with the same MAC twice...always different. The original version of the adapter without the -01 works well and I have it connected to my Pan V2. Here is some output from my DHCP server showing the PI:

[xconverge]

I boxed mine up and am sending it back. I will try the OTG route with a different adapter/chipset I already have on hand that is supported, will work better for me to run a usb cable instead of flat ethernet cable anyways, so I can't help anymore, sorry :(

[bjs-pdx]

I now have 3 of the Uctronics adapters working. Seems to be an issue with the newer "updated" version of the adapter. I have the "non-updated" ones and all three came online without any issues.

Link to the ones I used: https://a.co/hqQUut8

Non-working version: https://a.co/4Ibxg25

[bjs-pdx]

Well, I've tested various V2s and one Pan V1 and can say that the Uctronics adapter just doesn't work with any of them. For the life of me, I can't figure out what changed. The V2 and Pan V1 WERE working but now do not. Tried several different adapter/camera combinations without success.

From my point of view, the only cameras to use with the wz_mini_hacks and the Uctronics adapter is the V3. It works like a champ with minimal effort. The Pan V2 is limited by the inability to reposition the camera vertically making it just a stationary camera, if you position it correctly before booting the hack firmware and assuming it never moves from the preferred position.

[willkitto]

I seem to be having the same issues as @xconverge and @Telain using the same UCTRONICS "updated" adapters. modprobe r8152 works to enable the interface, but with no mac address.

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00

If I add a HWaddr manually with "ifconfig eth0 hw ether..." then I can successfully enable and use the ethernet interface.

But any time I attempt to use the startup scripts using the wz_mini.conf setting of ENABLE_USB_ETH="true" then I get nothing but failure. I have attempted similar startup script type work-arounds as in @xconverge 's post, adding the "ifconfig eth0 hw ether .." to S03ethernet or before, but for some reason it always fails. I can't seem to trace through the startup scripts how the ENABLE_USB_ETH actually does the job of taking over for the wlan0 interface. I was hoping I could just bypass the numerous if then else statements of the startup scripts and make my own version with the hardcoded Hwaddr added in, but the only place in the rc.d directory that ENABLE_USB_ETH seems to make any difference is the S03ethernet file. S06networkalt would use it too if bonding is enabled.

Has anyone had any luck with this issue?

Are there any instructions anywhere that help explain how iCamera works so that one could restart it manually using the eth0 interface instead of the wlan0 interface in this weird case where the startup scripts fail because of this missing HWaddr bug?

S07bonding mentions Fooling iCamera in a few places so it seems like this may need to happen when just using eth0 as well, without bonding, but I can't seem to figure out where this takes place.

[Bob-AOL]

There is nothing wrong with the script and nothing needs to be re-invented to initialize a good adapter. And the camera will not boot to eth0 unless the adapter has been successfully initialized on the network with its own MAC address at least once. The camera needs wi-fi to boot unless somehow told otherwise -- which is accomplished by dhcp discover when initializing the adapter from a wi-fi state live online with the adapter attached to the network and able to obtain an IP address for its MAC address. This, of course, is all done via wz_mini.

[Bob-AOL]

@willkitto

Are there any instructions anywhere?

This is how it works with a good adapter and no self-inflicted issues introduced otherwise.

UCTRONICS Adapter Setup.pdf

[bjs-pdx]

I have some speculation on why the "updated" Uctronics adapters may be a problem. I no longer have one of these but I do have four of the "non-updated" ones working: two on V2s and two on V3s.

When I had the updated version I couldn't get it to work with the cameras...any of the cams. However, the adapters worked with a Raspberry Pi Zero and my ubuntu laptop. But they were both assigning random MACs for the cards. @Bob-AOL suggested that this was due to security settings in the OS which uses random MACs to obscure the device. But as noted by @willkitto earlier in the post probing the NIC shows no MAC or at least all zeroes. On the non-updated versions I get a RealTek MAC.

My suspicion is that the updated ones don't have a burned in MAC and the cameras are unable to deal with that and assign a random one. There is an earlier post that shows the updated ones will work if you assign your own MAC but it doesn't stick past reboot. From a Google search: https://forums.macrumors.com/threads/usb-ethernet-adapter-changes-mac-address-everytime.1976166/

" If the USB device does not have a specific MAC address on the outside of the device and it is a "cheap" adapter. It is likely that the mac address is a software programmable MAC address that is assigned by the driver at load. I think these are the worst invention ever created but just like there are software based modems and com ports there are software based network cards."

Anyway, just my thoughts on this. Here are the MACs on my cameras:

Link encap:Ethernet  HWaddr 00:E0:4C:xx:xx:xx   Garage V2
 Link encap:Ethernet  HWaddr 00:E0:4C:xx:xx:xx   Driveway V3
 Link encap:Ethernet  HWaddr 00:E0:4C:xx:xx:xx   Thing2-Garage V3
 Link encap:Ethernet  HWaddr 00:E0:4C:xx:xx:xx   Thing1 V2

[bjs-pdx]

Further reading and research on the interwebs indicates the lack of MAC could be a manufacturing problem. Does anyone have contacts with Uctronics who could pass along the findings and ask if the lack of MAC is by design or by accident???

[Bob-AOL]

I've recently initiated dialogue with them and have received favorable responses regarding their interest in solving the issues experienced by Wyze Cam folks attempting to use their adapter. They don't deny that production issues have been a problem with the product, but aren't convinced the problems experienced by Wyze Cam hack applications don't also have other sources of initialization failures having nothing to do with their device. I agree completely as you well know and as exhibited here by your own experiences.

That said, they have a v3 on the way and instructions for implementing wz_mini_hacks along with a detailed explanation of how to most effectively initialize their device with a properly configured wz_mini SD card. I expect to remain in the loop of their testing and results from purely an experienced end-user perspective and will report accordingly.

The adapters have MAC addresses as Realtek Semiconductor devices. The only difference between the original "bad ones" and the "upgraded" ones is an ID to gnd being set in the newer devices for use in situations that may require it. This could explain why some adapters may be "seen" by some systems and not others and obviously why one can be seen but not heard (MAC address established) if it is indeed bad or not properly initialized for its particular application -- like hanging off a hacked Wyze Cam that may have any number of inherent issues present in the hard coded firmware or ancillary hardware that prohibit wz_mini from even working as intended in the first place.

Case in point is the bad adapter recently sent to me by SomebodySysop. It was recognized by my Windows laptop as a Realtek Semiconductor USB device but that was it. No dhcp discover packet sent, so no way for a MAC address to be identified let alone an IP address assigned. Just a non-functioning adapter for whatever reason -- somewhere beyond the ethernet stage since it was at least identified a USB device. It just couldn't get past the transport layer to establish the data link required for going any further. At least that's my take on it, but I'm a network guy, not a developer. On the other hand, the programming itself could be keeping the data link from being established...

It'll be interesting to see what UCTRONICS comes up with for a solution from their perspective. I will certainly pose any relevant questions beginning with the MAC issue as you've presented it.

A good UCTRONICS adapter generally works with the Wyze devices listed in the README if the methods and considerations provided are followed -- with obvious exceptions for the earlier products and pitfalls everywhere for the adventurous who only read half the required info before embarking on a rewrite of the hack to add what they missed to begin with.

The biggest problem with even a perfectly working adapter is the README indicating it should be 'automatically detected' with no explanation of how this is supposed to magically happen...., and it doesn't.

I have two of the 'upgraded' adapters and had zero issues initializing them for/with v3s.

[willkitto]

@bjs-pdx Thanks for adding your experiences and thoughts @Bob-AOL Thanks for reaching out to UCTRONICS! I am very interested to hear what they come up with.

Just to reinforce my experience with these adapters: Default MAC address is all zeros. Using ifconfig to change the MAC address, I can make the adapter work on the network. I can use a static ip address or use udhcpc -i eth0 to get an ipaddress from my dhcp server. All this will work. I even created a custom startup script that loads the r8152 module and assigns a MAC address. This works successfully, so the system will boot up with a functioning eth0. But, it doesn't work with the wz_hack startup scripts. If ENABLE_USB_ETH is set to "true" then it fails. I don't know why. This is why I want to know more about how the startup scripts work so I can just force it to work with a custom startup script.

I added a new variable to the wz_mini.conf file:

#Example
USB_ETH_MAC_ADDR="12:34:56:78:90:12" 

And here is my custom startup script that uses the above variable to assign the MAC address to the eth0. '/opt/wz_mini/etc/rc.d/S02network_preload'

#!/bin/sh
### BEGIN INIT INFO
# Provides:
# Short-Description: USB Ethernet Support
# Description:       Preload USB Ethernet adapter stuff
### END INIT INFO

. /opt/wz_mini/etc/rc.common
. /opt/wz_mini/wz_mini.conf

case "$1" in
        start)

                echo "#####$(basename "$0")#####"

                if [[ "$USB_ETH_MAC_ADDR" != "" ]]; then
                        echo "Loading Realtek RTL8152 driver..."
                        insmod $KMOD_PATH/kernel/drivers/net/usb/usbnet.ko
                        modprobe r8152
                        sleep 0.3
                        ifconfig eth0 down
                        sleep 0.3
                        ifconfig eth0 hw ether $USB_ETH_MAC_ADDR
                        sleep 0.3
                        ifconfig eth0 up
                fi
                ;;
        *)
                echo "Usage: $0 {start}"
                exit 1
                ;;
esac

Reason for all the "sleep" commands: Running the ifconfig eth0 hw ether command immediately after the modprobe r8152 would often fail to assign the MAC address. Adding the sleep commands in-between seemed to help things succeed, presumably this gives enough time for the module to finish loading.

This all works fine when ENABLE_USB_ETH is "false." But when turning it "true," something breaks for some reason. It seems like it should work, but some step is not functioning. I can't find any reason in the startup scripts why setting ENABLE_USB_ETH to true would make such a drastic difference.

[Bob-AOL]

Nice work there. With your permission I'll include it in my next correspondence with UCTRONICS. Same with any other contributors here. Lots information in this thread addressing the heart and soul of how the USB/ETH function is supposed to work. A simple interface toggle that re-triggers dhcp when wi-fi is lost and initializes a wired adapter in its place.

I personally still see it as a network issue, not coding. A good adapter works without modification to wz_mini. A bad one doesn't, even though it may still work on a more fundamental platform like a Raspberry Pi or other platform capable of seeing and examining devices on more of a raw level -- similar to your approach above.

As a network guy and not a developer, what I see is a device working at the physical level but not at the data level to even reach the control level. OSI layers 1, 2, & 3.

The above exercise substitutes the Layer 2 and 3 activity which in turn enables device functionality at layer 1 -- until it is rebooted which removes it from the network, thus requiring new parameters be established for renewed functionality. The script is simply substituting for a non-existent DHCP process because it isn't being initialized when wz_mini is toggled into wired mode. Aside from the possible raw id packet, no discover is even sent. no request returned. no offer, no ack. Nothing.

It's not that the adapter doesn't have a MAC address. It doesn't exist at all as far as the network is concerned. Forcing it into functionality externally indicates to me a data path problem with the device, (or perhaps the process), but not the hack.

Regarding the "true"/"false" issue, wouldn't rebooting the camera to make the change wipe the temporary adapter settings and basically just get you back to square one?

[bjs-pdx]

@willkitto If you are within your return window for Amazon I'd send back the adapter and get a different one. This is the link to the ones I have purchased and have been able to get working:

https://a.co/3qrX2cL

[Bob-AOL]

Ditto, though I have two "upgraded" versions which also work.

I think we're getting closer, fellas.

[bjs-pdx]

So, with the updated ones, do they show a RealTek MAC or ???

[Bob-AOL]

Yes.

[bjs-pdx]

That would seem to differ from the ones with all zeroes or missing any MAC.

[willkitto]

Nice work there. With your permission I'll include it in my next correspondence with UCTRONICS. Same with any other contributors here.

Of course

It's not that the adapter doesn't have a MAC address. It doesn't exist at all as far as the network is concerned. Forcing it into functionality externally indicates to me a data path problem with the device, (or perhaps the process), but not the hack.

Not sure what you are talking about here. Once the adapter is working it is working. Once the module is loaded and then a MAC address is set, it is then on the network. The unknown to me is why the wz_hack scripts don't run with it after that point. My assumption is that there are some other tools, outside of /opt/wz_mini/etc/rc.d that do something, and I just haven't found those functions yet.

Regarding the "true"/"false" issue, wouldn't rebooting the camera to make the change wipe the temporary adapter settings and basically just get you back to square one?

My above script is in the etc/rc.d directory and therefore runs at boot every time. I named it S02 so that it runs before the S03ethernet script which just checks for which module to load and once loaded does something with its mac address with the following command: cat /sys/class/net/eth0/address | tr '[:lower:]' '[:upper:]' > /opt/wz_mini/tmp/eth0_mac I haven't found a reference to /opt/wz_mini_tmp/eth0_mac anywhere else, so I can't figure out why it does this.