Builds for Linksys WHW03 V2 + V1

Edit: I found the 801.11r option. It used to be located in the security settings but now it has it's own tab. I was following some older guides on YouTube so I was looking in the wrong place all along. Thanks again.

1 Like

Hi @protectivedad, thanks for your work. Is there any chance of providing your build directly in github's releases like how @flipy is sharing his builds in https://github.com/flipy/openwrt/releases/tag/whw03-0.0.7? Thanks.

I would be highly interested to get a new build for my WHW03-V1 as well.
Unfortunately, I'm not able to build it on my own :frowning:

1 Like

@vtremblay Did you ever get access to EmberZNet stack?

Me to! Still looking for a good/easy way of flashing those.

I was dumped a original firmware (WHW03 V1) and what I found about ZigBee :

in /etc/system/wait

# get ZigBee radio ready
echo "[utopia][init] initializing ZigBee interface" >> /dev/console

if [ $HW_VERSION = "1" ];then
	echo "[utopia][init] initializing V1 interface" >> /dev/console
	GpioOutZigBee="56 45 49 55"
	GpioInZigBee="50"
else
	echo "[utopia][init] initializing V2 interface" >> /dev/console
	GpioOutZigBee="29 45 49 31"
	GpioInZigBee="50"
fi

for ii in ${GpioOutZigBee}; do
	echo "[utopia][init] GPIO OUT ${ii}" >> /dev/console
	echo "${ii}" >/sys/class/gpio/export
	echo out >/sys/class/gpio/gpio"${ii}"/direction
done

for ii in ${GpioInZigBee}; do
	echo "[utopia][init] GPIO IN ${ii}" >> /dev/console
	echo "${ii}" >/sys/class/gpio/export
	echo in >/sys/class/gpio/gpio"${ii}"/direction
done

# This will let poll() function to detect event.  Fast command responses via SPI
echo falling >/sys/class/gpio/gpio50/edge

echo "[utopia][init] ZigBee interface ready to use" >> /dev/console

# for nodes, at boot up always set the backhaul status to down
sysevent set backhaul::status down

also found zbbootloader.sh

#/bin/sh

HW_VERSION="$(syscfg get device::hw_revision)"

SetGPIO()
{
	local l_gpio=$1
	local l_value=$2

	echo "$l_value" >/sys/class/gpio/gpio"$l_gpio"/value
}

ZBReset()
{
	local l_value=$1

	SetGPIO 49 "$l_value"
}

ZBNwake()
{
	local l_value=$1

	if [ "$HW_VERSION" = "1" ];then
		#VelopV1
		SetGPIO 55 "$l_value"
	else
		#VelopV2
		SetGPIO 31 "$l_value"
	fi
}

ZBRunStandAloneBootloader()
{
	ZBReset 0
	ZBNwake 0

	ZBReset 1
	sleep 3

	ZBNwake 1
	sleep 1
}

ZBRunStandAloneBootloader

also it's contain a firmware for ZigBee: Silicon Labs EM3581 (SoC) in /usr/sbin/ncp-fw

ncp-spi-use-with-ezsp-spi-btl-5.8.1.ebl

Looks like it's connected over SPI

1 Like

Silly question but what's the policy on submitting someone else's code in a pull request?

I've created a snapshot build based on the changes in protectivedad's repository mentioned above and everything seems to just work. I don't see a reason for not creating a pull request, but I'd love to give credit where it's due. This would, however, cause the committer and author to be different and I'm not sure if that's in accordance with the guidelines.

Does anyone know if this would be acceptable?

I've tried building from protectivedad's repo on my V1 (I have successfully flashed a 21.02 build from flipy) but I must be missing something in the config - it builds correctly, but it won't boot and I have to revert tot he 21.02

If you (or anyone else) could share a valid .config file in a gist on github I would appreciate it - I have no problem getting an image out of the build, just not sure if I have the config correct

good news is that I got the build to work on my V1 based off 23.05.2, and for anyone else looking to recreate it, I have posted step by step instructions here:

You will need a Linux system (VM or physical, I had issues with WSL) with docker to follow the instructions and a github account, or if the version looks good you can just skip all that and nab my branch, build yourself.

I will do a v2 build too and will look to add them to a release on that fork, will post here if and when I manage to make that happen.

1 Like

I created the release as promised, take a look here:

2 Likes

thanks for working on the PR!

(i'm supposing your build here mainly matches your PR.)

some questions:

  1. does your PR include a fix for the issues related to board files discussed earlier on this thread? (i think the active board file(s) depend on the country the interface is configured to work on.)

  2. radio0: does your PR allow channels 100~165? or is it restricted to 149~165?

  3. radio2: does your PR allow channels 36~64? or is it restricted to 36~48?

(sorry i need to ask, i don't have any of these devices.)

thanks!

might that related to this?

Oh, sorry, should have been more clear - the issues I had were related to docker volume mounts on WSL and nothing to do with OpenWrt. I also couldn't build it on the WSL Ubuntu I was running but I suspect that was just a matter of the version of Ubuntu I was running.

1 Like

does your PR include a fix for the issues related to board files discussed earlier on this thread? (i think the active board file(s) depend on the country the interface is configured to work on.)

I did not have to make any changes to the board files with 23.05 but now that I re-read some of the earlier stuff it's worth noting that I did not mess with the regional settings at all. I will see if I can poke them and if they work.

I did make note of this during my testing, but now I don't remember the details - I will check when I get home. I got myself a wiki login so I can create the relevant data page once the support is added, and I intend to add these details there.

1 Like

Following up here, channels 100-165 and 16-64 respectively are selectable. Set to auto they are currently operating on 161 and 36 on my v1 unit. The iw list command reports this correctly also (with the unavailable channels listing as disabled).

I also confirmed that I did not change the country code - it is set to the default and the radios "just worked". I will test some non-defaults and see if that impacts anything.

1 Like

thanks! i will try getting my hands on a V1 and a V2, and figure out why the official V2 port only supports a reduced channel range (possible bug).

Thank you so much for the V1 image :muscle:
Would it be possible to use the WAN port as a normal network port? I've tried several configurations, but all relate in a non-communicating velop.

thanks in advance
Björn

I swear, I've done it exactly the same way, and did not work.
Now it's working?!?

Thanks

hi, thanks!

i got the gray piece out, then the 3rd recessed screw, then the 3 little corner screws. total screws: 6 (3 big, 3 little).

trouble is, i can't slide the side plates towards the end where the gray piece used to be to unlock them. yes, i see one must slide before the other, but i can't slide the first. what kind of devilish trick is this?!