Trying to add archived opkg feed to opkg to install packages for old firmware

Hi there,

I'm currently working with a Spectrum SAX1VK1 and the only working firmware I have is rather old. Here's the HW info:

Hostname	OpenWrt
Model	Askey RT5010W-D187
Architecture	ARMv8 Processor rev 4
Target Platform	ipq807x/generic
Firmware Version	OpenWrt SNAPSHOT r22242-c8c91909d9 / LuCI Master git-23.039.28596-41e9b8d
Kernel Version	5.15.98
Local Time	2024-05-13 19:22:00
Uptime	0h 2m 26s
Load Average	0.13, 0.06, 0.02

Trying to install openvpn-ssl, tmux, tmate, etc doesn't work. The default opkg config is as follows:

opkg update

Updated list of available packages in /var/opkg-lists/openwrt_core
Signature check passed.
Updated list of available packages in /var/opkg-lists/openwrt_base
Signature check passed.
Updated list of available packages in /var/opkg-lists/openwrt_luci
Signature check passed.

The feed I want to add (because just downloaded packages results in a dependcy missing or architecture mismatch is here (the closest release is 22.0.3)

Editing the opkg config in Luci and CLI, it seems like it is expecting a .gz file - but all I have is that directory ... so when I try to add it, I get this error:

Failed to allocate uclient context
Collected errors:
 * opkg_conf_parse_file: /etc/opkg/customfeeds.conf:5: Ignoring invalid line: `'
 * opkg_download: Failed to download /Packages.gz, wget returned 1.

I'm trying to add tmate so a community member can drop in to the terminal and see what is going on (latest snapshot for Askey RT5010W-D187 results in no functional WAN link).

Is there a protocol for adding old package feeds that are compatible with current kernel, firmware, and architecture? Downloading the packages I want individually and SCPing them to /tmp, then trying to manually install locally results in missing dependencies.

Thanks in advance :pray:

You have a snapshot release running. This means that the packages won’t work from any other release build or even subsequent snapshots.

You will have to upgrade to a current snapshot first. snapshot packages aren't retained or archived, when they've been superseded, they'll be replaced by the newer updates (which aren't compatible anymore). ...and your build is at least 2 months old, so too much has changed.

You can sysupgrade to stable release first (yes, it is same hardware under different labels, search these forums for more identical models)

1 Like

thanks for the reply.

I've been able to install packages by updating the feeds opkg.conf in Luci to the closest corresponding build (no more kernel errors).

That said I have just one issue now - the kmod-tun in that repo (release 22.03) needs kernel > 6, I have 5.15.

I located the right kmod-tun file (5.15) in the downloads staging area here, but I am getting a malformed pkg error from opkg and luci when trying to install it.

I've scp'd it into /tmp and tried a local opkg install - leaving the filename as is (kmod-tun) as well as renaming it to kmod-tun.ipk.

It's my understanding that the files in the staging packages section are already built, no?

Thanks for reply.

Yes, I've been flashing the latest stable release and snapshot all week - when doing so, I can't get a WAN connection. I've tried backing up and restoring the config from the working fw to the latest fw, lots of factory resets and power cycles, none of it works. The firmware installs, Luci works fine, LAN and radio work fine, but no WAN link (this is the SAX1V1K snapshot on the same download section).

When flashing to the Dynalink DL-WRX36 image, the router will not boot (it appears to be looking for a boot image on a partition, I will see if I can find the specific error in the log and update in here if I locate it). I tried it once, and in order to get back to uboot I had to short out the clock pin to the VDFF, then set env variables to tftpboot to recovery.img, then SSH in there and revert to the previous release from the Github guide. It was a bit of a hassle, but I'll do it again if there is community confidence around it. I've been asking people in the SAX1V1K thread what FW image they are successfully using but have yet to receive a reply.

The SAX1V1K is the same hardware (minus a USB port, one LAN port, and a different size and type of memory) - I imagine these distinctions might be the issue? Or perhaps I am doing something wrong? I flashed via Luci as well as sysupgrade -v -n -F /tmp/sysupgrade.[bin | img]

All ears if you have any advice, for now I'm just trying to config it the best I can until I can get a new build on there

You need to do all setup by hand, no backups

I have been doing all setup by hand, yes. I included the backup/restore remark as a means to show that it is one of the options I've attempted as a way to get the WAN port to work.

Unless I am mistaken, connecting the router to an upstream router with DHCP after a fresh install of latest snapshot should result in the WAN port grabbing an address, no?

1 Like

Yes, wan port is dhcp client and lan ports are served from with dhcp dns http ssh aka openwrt.lan.

Can you restart wan interface and grab log(read)?

Check ip link and ethool wan and dmesg for tthings looking like errors.

1 Like

Yeah, I tried all that - no dice.

Issue (with ethtool, mdio, dmesg, and other diagnostic outputs) are here if you care to check it out - I've already opened the issue in the SAX1V1K thread here on the forums and don't want to clog things up in this thread as well.

Helps if you format logs with 3x backticks. Please add whats asked here.

yes, i messed up the formatting on my first report in there. i was reproached for it and made note!

i am currently using the working WAN-functioning snapshot [OpenWrt SNAPSHOT, r22242-c8c91909d9], so those logs won't be useful.

Trying to post the logread saved from the latest snapshot (with no WAN), I'm unable to post it here as it exceeds permissible length.

Is the information in that github issue thread insufficient or would you rather just have it here so everyone else can see?

I asked for extracts from files, not 2000 screens soft roll.
From release 23.05.3 or latest snapshot. What you are using is before 23.x with packages being wiped in weeks after created.

And there
mii-tool -v wan
mii-tool -v lan1

ethtool wan
... lan1 (not eth0 or dsa parent port)

and extract from logread while restarting non-working wan connection.

Outline of workaround: assign vacant LAN port as WAN.

EDIT: add those tools 'ethtool' and 'mii-tool' when constructing image in firmware selector. Kind of impossible to install without wan.

Sorry man not sure I'm communicating clearly.

I have some outputs (with the exception of mii-tool) from the latest snapshot as of three days ago (which I prepopulated in the image builder with those tools) at this link. At that link there is ethtool and mdio*9, not sure if that is useful to you. Someone in that thread indicated they believe this could be of import:

kernel 5.15 (the working WAN firmware)

[ 2.958003] Generic PHY 90000.mdio-1:00: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:00, irq=POLL)
[ 2.961674] nss-dp 3a001000.dp1 lan4: Registered netdev lan4(qcom-id:1)
[ 2.971615] Generic PHY 90000.mdio-1:01: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:01, irq=POLL)
[ 2.977841] nss-dp 3a001200.dp2 lan3: Registered netdev lan3(qcom-id:2)
[ 2.987750] Generic PHY 90000.mdio-1:02: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:02, irq=POLL)
[ 2.993948] nss-dp 3a001400.dp3 lan2: Registered netdev lan2(qcom-id:3)
[ 3.003910] Generic PHY 90000.mdio-1:03: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:03, irq=POLL)
[ 3.010164] nss-dp 3a001600.dp4 lan1: Registered netdev lan1(qcom-id:4)
[ 3.225434] QCA808X ethernet 90000.mdio-1:1c: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:1c, irq=POLL)
[ 3.225974] nss-dp 3a007000.dp6-syn wan: Registered netdev wan(qcom-id:6)

kernel 6.6 (the snapshot)

[ 2.703648] dp2: ppe offload disabled: 0 for macid 2
[ 2.707391] dp2: Switch attached to macid 2 status: 0
[ 2.881792] dp3: ppe offload disabled: 0 for macid 3
[ 2.881824] dp3: Switch attached to macid 3 status: 0
[ 2.961348] dp4: ppe offload disabled: 0 for macid 4
[ 2.961381] dp4: Switch attached to macid 4 status: 0
[ 3.041351] dp6-syn: ppe offload disabled: 0 for macid 6
[ 3.041384] dp6-syn: Switch attached to macid 6 status: 0

I appreciate you taking the time to help out here, I will build a new image and collect that requested data when I can wrap up with some broadband-dependent work at the end of the day.

In the meantime, here is the ethtool wan output:

ethtool wan
Settings for wan:
        Supported ports: [ ]
        Supported link modes:   1000baseKX/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseKX/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 28
        Transceiver: external
        Auto-negotiation: on
        MDI-X: Unknown
        Link detected: no
1 Like

It has no usable gigabit mode.
KX is PCB style connector, like in blade format servers.

Do you need my help making br-wan with this WAN port and one of LAN ports so that you get working internet on current release?

Thanks for the reply (and the kind offer to help).

I'm a wee bit in over my head but I am a quick study and picking things up wrt OpenWRT. I just started last week.

Frankly I just want to get this thing working as expected, and it seems like there are a ton of people using this Askey Router, though mostly as the the D-link WRX36 flavor (not the Spectrum SAX1VK1). I don't have the greatest confidence in my understanding, but does it seem reasonable that given the WRX36 has a USB port and different memory, it wouldn't work on this unit? The boards are the same, but the peripherals are a bit differnet (memory size, type, and USB).

Likewise I don't know why there are snapshots at the firmware selection page for this unit if the WAN doesn't work - wouldn't that imply someone has tested it (the core functionalty of it - WAN) with success?

I'm also not sure why the FW posted here works, and there seems to be people in this Git thread stating that they've been working on it here, but the latest versions I've been flashing don't work, though I suppose it is a custom build. I've tried contacting the author but haven't heard back.

So to answer your question, yes I'd definitely be interested, but I'd like to first rule out that I'm not doing something wrong as this is a pretty common router with a fair amount of activity around it and I seem to be the only one running into this significant issue. Any ideas how to more exhaustively rule that out?

EDIT: typos

Dynalink (nineties-sounding name) is not d-link (real home network company since nineties)
Try to shorten your bug report, link to that pull request, probably this thread to draw some attention from original commiters.

Outline for br-wan:
1/ ip link -> determine unused LAN port (in form of lan1@dsa or lan1@eth0)
2/ remove port from br-lan editing /etc/config/network
3/ add br-wan without adding any ports and check "bring up empty bridge"
4/ edit /etc/config/network and re-assign "device" from wan to br-wan from wan and wan6 connections (yeah, stylish have 2 different things to have same name)

config interface 'wan'
        # option device 'wan'
        option device 'br-wan'
        option proto 'dhcp'

config interface 'wan6'
        # option device 'wan'
        option device 'br-wan'
        option proto 'dhcpv6'

5/ reboot (no wan at this point)
6/ connect cable to liberated LAN port, and add that LAN port and the non-functional WAN to br-wan.

99/ try plug cable in wan port after kernel upgrades just in case bug fixed.

Thanks - I will try all these things when I have the opportunity to reflash to latest.

Can you expound on this? Are you suggesting to add a new issue in github and link to this thread? Or update the extant one?

Just shorten kilometers long unformatted logs to essential pieces, it is really no hope anyone ever looks at them

this worked, thanks very much.

  1. Is there any substansial downside to this setup? I imagine any firewall rules will not be applicable or restorable if/when this bug is patched, as the interface and device names will change.
  2. What do you advise is the best place to report this issue? OpenWRT forums? Or just update the thread I linked you to earlier?

Appreciate your help.