[Solved] Opkg update fails, Due to Port Number?

Hi,

I see lots of posts about opkg failing due to DNS ... but I'm pretty sure that's not the case here. DNS is working fine ... but I think the issue is trying to get opkg to pull from,

https://www.mydomain.com:4443/

I have to use the custom port number as 443 is not available - and thinking that's what is causing the grief here? Has anyone seen this, and/or been able to get it to work?

Thanks!

I'm unclear as to how your port number is related to problems with opkg... perhaps a little more info would be useful

  • Is this the location of your own personal repo?
  • Where is this server relative to your router?
  • Have you verified that the server is listening on port 4443?
  • are you able to use opkg normally for the standard repo?

Sure, NP! :slight_smile:

  1. Yes, my repo - for modules I built, and tied to my kernel version that way.
  2. Behind the router. I did try going there from a browser on my network, works fine ... I see the full file listing.
  3. From 2, yep. Was perhaps thinking about installing curl (manually), try that? Some other way to check it perhaps?
  4. Sort of :wink: ... I get an error, not matching kernel version (hence going with my build output). Make sense?

Thanks!

Gottcha. Thanks for that additional info.

Did you put these into the custom feeds? What is the output of:

cat /etc/opkg/customfeeds.conf

Is some other service running on port 443 on server itself?

I did not, I modified the "stock" feeds => so just tried modifying customfeeds.conf, same result.

Yep - AT&T gateway, you can't shut 443 off :frowning:

You said that the server is behind your OpenWrt router, right? If that's the case, you can run the server with port 443. Then, if it is necessary to access externally, you can port forward 4443 > 443, thereby avoiding the issue with the port that's in use by AT&T's gateway.

Once that's set, you can simply use the lan IP address of your server and/or you can create a local DNS entry for your domain so that it connects to the local IP (rather than the public IP) and therefore doesn't need to deal with the unusual port number.

If these are not options, have you tried specifying the port in the feeds URL?

1 Like

So I've just run an experiment...

The following feeds as specified for a Pi4

src/gz openwrt_core https://downloads.openwrt.org:444/releases/23.05.2/targets/bcm27xx/bcm2711/packages
src/gz openwrt_base https://downloads.openwrt.org/releases/23.05.2/packages/aarch64_cortex-a72/base
src/gz openwrt_luci https://downloads.openwrt.org/releases/23.05.2/packages/aarch64_cortex-a72/luci
src/gz openwrt_packages https://downloads.openwrt.org/releases/23.05.2/packages/aarch64_cortex-a72/packages
src/gz openwrt_routing https://downloads.openwrt.org/releases/23.05.2/packages/aarch64_cortex-a72/routing
src/gz openwrt_telephony https://downloads.openwrt.org/releases/23.05.2/packages/aarch64_cortex-a72/telephony

Note that the first one now says

https://downloads.openwrt.org:444/...

When I specified port 443, it worked without issue (the server does use port 443). Specifying port 444 (as shown here) causes it to fail (expected here because the server isn't using port 444).

That suggests that the port numbers are respected, provided that you included them in your url structure.

Agreed! But ... that won't work :frowning_face:. Because I'm going through Cloudflare, so the SSL cert on the local machine is not "valid".

Hang on! You hit on it - brilliant! I can stay internal, then drop https, just go with http. That works. Thanks!!

Will use that in custom.conf, just need to remember the defaults to put the OpenWrt servers back ... LOL.

Thanks!!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.