Trying to get DDNS to work but cant update package list


 

Jesse C

New member
I set up my DDNS through FreeDNS and followed this but I cant get it to update the package list. I get this message:

Downloading https://downloads.lede-project.org/snapshots/targets/brcm2708/bcm2708/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_core
Downloading https://downloads.lede-project.org/snapshots/targets/brcm2708/bcm2708/packages/Packages.sig
Signature check passed.
Downloading https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/base/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_base
Downloading https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/base/Packages.sig
Signature check passed.
Downloading https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/linkmeter/Packages.gz
*** Failed to download the package list from https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/linkmeter/Packages.gz

Collected errors:
* opkg_download: Failed to download https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/linkmeter/Packages.gz, wget returned 8.


When I follow the link but 404s after /linkmeter/, everything up to that works. I tried changing the link to https since I read that helps sometimes but no go. I tried both builds too, currently on the SNAPSHOT build, using a pi zero w.

Any ideas?
 
You can just go to System -> Software -> Configuration and comment out the linkmeter source (put a # in front of it) to get around that issue.

But yeah the LEDE-Project packages are a bit of a mess. It was OpenWRT and then a bunch of the good developers said "We're going to do it THIS way now!" and so I ported HeaterMeter from OpenWRT to LEDE. Then less than a year later, they put aside their differences and remerged and redid all their source lists. I decided to not port back to OpenWRT immediately and just put it off until the next HeaterMeter version. As such, some of the package repositories are stale or broken. That one however is because there's an issue in the build process that forces that package source to be included or else it won't include any of our linkmeter/heatermeter software, so the work around is to comment it out in the sources list. There's a pretty good chance that you won't be able to get the packages you want anyway though since there will be version conflicts due to the current snapshot not being the snapshot we're built from.

I'd recommend turning on DDNS on your home router if it supports it, not the HeaterMeter device.

I've also bought the smoky.link domain with the intent of having DDNS built into the system, so everyone can have their own XXX.smoky.link url, but it was backburnered because it would probably create more support requests than anything else since it also requires a hole in the home firewall. I'm also not really sure how secure it is to have HeaterMeter sitting on the Internet.
 
Last edited:
Bryan, I'd hazard a guess that a HeaterMeter exposed directly to the public Intardnet would still be far more secure than most, and especially Windows hosts. Is there any reason to have more than ports 22 (ssh,) and 80/443 (http,) open? No real reason to tempt trouble.

You got the smoky.link TLD? Very cool.

Yes, DDNS really belongs on interfaces that are exposed to the public. While you can set it up behind a firewall, it's not necessarily the best way to go about it.
 
Really the only port you need is for HTTP or HTTPS (take your pick). I'd keep the SSH port closed at the firewall since you probably can do as much normal config as needed from the webui, and can always SSH in from the local network if needed. I also map the external port on the firewall to something else (not 80 or 443 or 8080) and have it forward to port 80 or 443 on the HeaterMeter. Just having it on a non-standard port eliminates like 99% of bad guys just scanning looking for web servers.
 
Thanks for the reply Brian, So I changed the comments to:
src/gz reboot_core https://downloads.lede-project.org/snapshots/targets/brcm2708/bcm2708/packages
src/gz reboot_base https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/base
src/gz reboot_linkmeter https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/#
# src/gz reboot_luci https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/luci
# src/gz reboot_packages https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/#Packages.gz

and it returned:

Downloading https://downloads.lede-project.org/snapshots/targets/brcm2708/bcm2708/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_core
Downloading https://downloads.lede-project.org/snapshots/targets/brcm2708/bcm2708/packages/Packages.sig
Signature check passed.
Downloading https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/base/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_base
Downloading https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/base/Packages.sig
Signature check passed.
Downloading https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/#/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_linkmeter
Downloading https://downloads.lede-project.org/snapshots/packages/arm_arm1176jzf-s_vfp/#/Packages.sig
Signature check failed.
Remove wrong Signature file.
Failed to decode signature

Any thoughts? I tried getting my router configured for DDNS but it starts to load where at the top of the page it will say "LuCi Lua configuration interface" but then times out :/
 
Really the only port you need is for HTTP or HTTPS (take your pick). I'd keep the SSH port closed at the firewall since you probably can do as much normal config as needed from the webui, and can always SSH in from the local network if needed. I also map the external port on the firewall to something else (not 80 or 443 or 8080) and have it forward to port 80 or 443 on the HeaterMeter. Just having it on a non-standard port eliminates like 99% of bad guys just scanning looking for web servers.

I was thinking on the HM itself, not what's available on the outside world. If at all possible, DDNS should be on at your NAT firewall with port forwarding, and can be used with multiple systems at that point. DDNS would be useful if the HM is directly hosted on the public network, and yeah, sshd running on a non-standard port is a good idea. That will eliminate nearly all penetration attempts.
 
Let the HM be a HM and let your router do DDNS :)

I tried to but it will start to load and will say "LuCi Lua configuration interface" on a white screen but wont go past that, just tries to load till it times out. Any thoughts on what I might have set wrong? I tried forwarding port 80 then 443 on HM but neither worked.
 
Can I run what I have set up and will someone let me know if I have this right? On FreeDNS I have my heatermeter IP address linked to my DDNS address, then I have on my router my login creds for FreeDNS with the DNS address, then I have a port 80 forwarded on the Heatermeter IP address. Is that right?
 
Wait a sec.... you should have the external IP address from your router listed at FreeDNS (hopefully, your router has a DDNS feature for FreeDNS.) This shouldn't be a 192.168.x.y, 172.x.x (or some such) or 10.x.y.z address (all RFC1918 test network, non-routable, addresses.)

Secondly, I would suggest that you use some other port other than 80 on the dirty side of your router for this just as a bit of security by obscurity. Hitting your FreeDNS address with the other port number will redirect to your HM on port 80.
 
ah ok, that first part makes sense. My router doesn't have a profile for FreeDNS, but it has a custom profile where I can add my login, so I switched the DNS to direct to my external IP address. Sorry I'm not great with network stuff. Could you help me with the port forwarding part? I'm not sure exactly what you are saying by the dirty side of my router. So on my port forwarding page on my router right now I just have one entry and it is the HM IP address and port 443 forwarded. How should I change that?
 
Let's see if I can do this in 10 minutes..... (and I failed, it's now 2 hours later.)

General theory, first. For TCP/IP communications, you use both an x.y.z.t IP address, as well as ports at that address. You'll have a ip/port pair at each end of the connection. Yes, I'm not going to talk about subnet masking, Multicast, etc., those will just confuse the issue. There is a series of IP addresses, originally defined in RFC1918, that will never be available on the public Internet, and will always be safe for use behind a Network Address Translating firewall (again, a more advanced topic.) The short story is that a NAT firewall allows you to run an RFC1918 network in your home, and present a single IP address to the world (it plays games with ip/port pairs and connections.) IP addresses really don't have any particular significance, although there are some geo-locating facilities & the like. Ports, on the other hand, have some structure. A target port should be a "well known" port. HTTP uses 80, HTTPS uses 443, SSH uses 22. The source port on the originating side will be some random port picked by the operating system. BTW, my use of the term "dirty" refers to the public Internet, as it's a big bad ugly world out there and no one can be trusted.

Let's break this down, for what does need to happen to get a remote connection to work. The browser will do a name service lookup for your HM external name (FreeDNS,) and make a connection to HMDirty:80. HMDirty is the IP address that your home router uses on the public network side. Your router needs to have a port forward, from HMDirty:80 to your internal HMaddress:80. Think of it this way: The initial packet connection is like a package delivery to a gated community. It comes to the gatehouse (your router) and gets direction to the right house (IP address) and doorway (port.) Every inbound packet talks to the gatehouse (HMDirty) and a particular door, and the guard there knows how to get the package to the right house (HeaterMeter.) You can (and I do sort of suggest this) pick a different inbound port other than 80 (different door at the gatehouse) and still forward to your internal HeaterMeter on port 80.
 

 

Back
Top