[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Switching from SysVinit to systemd

So pretty much the popular kids (distros) are all using systemd. As a user who only started using linux two years ago, only familiar with systemd, and it's esay to administrate. I would like to know what could be the downside of switching OpenWrt's init system from SysVinit to systemd.

Solved by delgh1 in post #12
Sorry I didn't RTFM and see /etc/init.d and automatically assume it was sysvinit My reputation is ruined and I'm gonna delete myself from the internet
1 Reply

[Assistant]
delgh1:
switching OpenWrt's init system from SysVinit to systemd.
Well, to my knowledge the actual init / process manager in OpenWrt is procd, an OpenWrt specific tool...
https://openwrt.org/docs/techref/procd
Architecture in
https://openwrt.org/docs/techref/procd#openwrt_operating_system_architecture

2

Aside from OpenWrt not using sysvinit in the first place (as detailed by hnyman already), did you check the installed size of systemd and its dependencies - relative to the typical flash sizes supported by OpenWrt (8-16 MB spi-nor, but even 'high-end' modern routers with NAND rarely have more than ~20-64 MB usable)?
--
While I'd be very interested in looking at a proof-of-concept build with systemd, systemd-networkd and iwd myself, it just wouldn't really be reasonable for anything but x86_64 (and even there systemd-networkd[0] and iwd[1] tend to show their deficiencies in production). It would be really interesting to compare what works and what doesn't (maybe even as proof case for systemd upstream), how far the rabbit hole goes.
[0] upgrade systemd in place restarts systemd-networkd (and all active network connections), which in turn stalls the ssh session doing the upgrade. journal full, needs cycling, which in turn respawns systemd-networkd and -you guessed it- kills off all active network connections…
[1] it's by far not as battle proven as hostapd, so anything beyond the basics on well-behaving participants may- or might not work, toss a coin.

2 Replies
2

Thanks for the informative replies, now how do I delete this thread


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Port forwards that dynamically follow internal hosts by their DHCP lease/mac address or hostnames?

It would be in this dialog
Instead of specifying a destination by IP address, you could write a mac address, hostname or even select a "host" from the dhcp lease
for instance
dhcp.@host[36]=host
dhcp.@host[36].name='screenul'
dhcp.@host[36].mac='3C:52:82:DB:AB:97'
dhcp.@host[36].ip='192.168.1.230'
(also I wonder, it is possible to create a "static" lease without specifying an ip address ?)
This would require a event script to update the internal firewall rules when --dhcpscript even is fired from the dhcp server. Plus maybe a once per 15 minutes check that reads all port forward rules and ensure that the firewall IP destination for the port forward actually matches the port forward port definitions

[Assistant]
Typically the best way to handle this is a dhcp reservation. This ensures that the ip address never changes. Is there a reason that the dhcp reservation doesn’t accomplish the same thing you are trying to handle?

7

In my case it is an dev environment. Where VMs got generated multible times by day. Wie did use rules for hostnames ans MAC so hostnames and MAC are known bevore the vm got online.
Static Leases can not keep up with that and it would not be very effective since we then would ned a person that the whole day does nothing else than setting static leases.

Script a static lease reservation and trigger it by hotplug on a DHCP server event:
https://openwrt.org/docs/guide-user/base-system/dhcp_configuration#static_leases
https://openwrt.org/docs/guide-user/base-system/hotplug#how_it_works

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Support for obtaining IPv6 privacy addresses

Right now it doesn't seem straightforward (or even possible) to enable the use of privacy addresses for outbound connection from an OpenWrt device. If an IP was obtained via odhcp6c (which is also the only supported way to obtain an address using SLAAC on OpenWrt), it uses EUI-64 by default.
A recent paper has shown that this allows an adversary to track users of a network with dynamic IPv6 prefixes. All that is needed is a single device in the network with an EUI-64 address to track other devices, even if they use privacy addresses.
There are a few vectors that will leak EUI-64 addresses of OpenWrt routers and APs by default:
NTP
DNS (not an issue for APs)
For the router itself, the ip6ifaceid="random" option can be used to obtain a random IP from IPv6-PD (which is not the same as a privacy address). But this is not applicable to APs downstream as the odhcp6c equivalent ifaceid does not support random, and not to mention that it'd complicates inbound connections to them.

4 Replies
1

[Assistant]
Hi
alaviss:
to enable the use of privacy addresses for outbound connection from an OpenWrt device
i like to ask, what is it good for ?
OpenWRT is router, not a consumer device
Downstream devices, like PC,Android ... will have they implementation of privacy
but router ?
sorry, but i don't see any reason

2 Replies
1

Because routers do interact with the Internet, via DNS (as the DNS caching server) or NTP. Some people might run ad-blocking DNS which connects to CDNs to download block lists, leaking its IPv6 address.
The paper linked above shows that it only takes one device using EUI-64 to allow user tracking across different IPv6 prefixes.

1

IPv6 prefix privacy
Installing and Using OpenWrt
A method to change the Privacy Secret is noted in this thread.
FYI - a search of the forums will produce many threads on this subject.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Connection Time for Associated Stations

I think it's a good idea to add "Uptime" column of associated stations in luci.
Or maybe there is a luci package for that already?

1 Reply
1

[Assistant]
eR2022:
"Uptime" column of associated stations
Can you show an screenshot/example from another device/firmware?
Can you show an example from a [desktop] OS?
(Hoping this exists in code somewhere already.)

Is that the time since DHCP lease, or does it mean something different ?

The Uptime column is the time of each device connected to listed wifi.
It has nothing to do with DHCP lease.
If I reboot all Cisco AP, all the devices connected will have the same Uptime once connecting again, but in the DHCP server will have different leases times. Of course, later if one device is shutdown/reboot will have a new Uptime.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: X86 Firmware Selector: Root Partition Size Parameter

Hello,
What an amazing piece of software OpenWRT is. I cannot be happier using it on a repurposed x86 device as a router. Customisable, secure and effective for a lot a network related tasks. We are lucky to have community of developers who give their time to make it better year-on-year.
I have a request. Could the firmware selector website give us the ability to request a certain sized partition for the root partition on X86 builds? This would eliminate the need to manually resize the root partition using tools such as GParted or rootfs.
I'm probably naive to think that it could be a straightforward implementation, but one may dream.

2

[Assistant]
It should be, problem is it'll increase the amount of storage required for generating and storing those images.

2 Replies
1

You are right, it might require more storage for generating and storing those images. I am curious how much more storage this will add? Are the x86 builds that popular? This would also only apply to people who would want to use the option too I imagine?

1

Llethur:
This would also only apply to people who would want to use the option too I imagine?
Sure, but not only for x86, but all platforms with removable boot media, like the Raspberries and Banan Pis, to name a few...


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Automatic channel width mode for wifi

hello. is it possible to add the ability to automatically select the channel width in the settings Wi-Fi?

Solved by lleachii in post #13
You understand somewhat correctly - or you're failing to consider TX and RX (it's difficult to determine). The client device controls its TX The AP master controls its TX RX is not under the control of the receiving radio. Hence, there is no "only for a specific device". So you (perhaps ) und…
2 Replies

[Assistant]
saber716rus:
automatically select the channel width in the settings Wi-Fi
What does this mean in practical usage?
When connected to an AP as client?
Or when configured as master AP?

2 Replies
1

saber716rus:
ability to automatically select the channel width
it's already there ?
just perhaps not the width you'd like it to be ...

1 Reply

in the wi-fi settings. Where the channel and channel width are configured.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [Solved] Would it be possible to add a Shutdown link in System menu

I'm using OpenWRT on a Raspberry Pi 4b, and it works great. I can't believe how well it works actually.
OpenWrt 22.03.5 r20134-5f15225c1e / LuCI openwrt-22.03 branch git-23.119.80898-65ef406
I can open a terminal and send the shutdown command from there but I usually just use the GUI for everything else.
I'm perfectly able to use the terminal, I was just wondering if it is possible for me to add it, or do you have any plans to add in the future?

Solved by lantis1008 in post #14
Could you not use luci-app-commands for this?

[Assistant]
It's not the primary application of luci-app-advanced-reboot, so you'd have to ignore the actual "advanced reboot" functions which are unsupported on your device. But the package also provides a "shutdown" option.

4

Yeah, I installed it and decided not to click the link since it warned me about partitions and such.
I was hoping for a "cleaner" option. It seems so logical for it to be there, especially since it's one simple command in the terminal.
I'll stick with the terminal for now. I rarely shutdown the router anyway. Only needed it while I was building it really.
I marked the topic as solved. Thanks.

rjc3rd:
I was hoping for a "cleaner" option.
I guess it would not be all that hard to make a small luci-app-shutdown package that introduces a minimal shutdown page, or maybe an extension to the "reboot" page.
You have to keep in mind that virtually no plastic/SoC routers have an actual "shutdown" and at best put the SoC in an infinite halt state. That's just recently changing with the advent of SBCs and X86 appliances.

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Add random MAC generation after each reboot

Router MAC address randomization is crucial for enhancing user privacy by preventing network operators from tracking devices using their real MAC addresses as consistent identifiers. This practice has been adopted by many operating systems, including iOS 8+, Android 8+, and Windows 10, to mitigate tracking methods such as footfall tracking in retail stores. However, more advanced tracking techniques have emerged, necessitating the implementation of MAC randomization not just during network scanning but also during actual network connections. Google's Android 10, for instance, made MAC randomization the default behavior for both scanning and connecting to networks, marking a significant shift towards privacy protection.

4 Replies
3

[Assistant]
How is the router having a random MAC going to improve, privacy?

2 Replies

If I don't change my WAN MAC every boot I always get the same IP from my provider

1 Reply
1

Generate a new random WAN MAC address at every boot
Network and Wireless Configuration
As I wrote here Vodafone changed my IPv4 DHCP lease time to 24h but I don't like that ;- ) Thanks to
@LEDEuser
I started with this, but it didn't work out because macchanger failed, stating eth0 is up. Couldn't deactivate before execution because then macchanger complains about a missing device. I changed the script: #!/bin/sh /etc/rc.common START=99 start() { # Generate a random MAC address new_mac=$(macchanger -e eth0.2 | awk '/New MAC/ {print $3}') ifconfig eth0.2 down ifconfig e…


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Support for doh and dot

New dns provider called https://dns0.eu it was build using same nextdns founder and technology so it is a really good option.

3

[Assistant]
There was a failed attempt at PR to have these included in luci-app-https-dns-proxy (https://github.com/openwrt/luci/pull/6238 https://github.com/openwrt/luci/pull/6239 https://github.com/openwrt/luci/pull/6240), if someone wants to address the issues with those PRs and resubmit, I'd gladly accept the PR.

1

What is the status will this merge so we can have this on next release.

Why should OpenWrt funnel traffic to a for-profit DNS provider by default? And why do people mistrust the DNS servers of their for-profit ISP only to voluntarily funnel all their queries to a for-profit DNS provider?

3 Replies
1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Auto Reboot after Specific Hours

I have installed OpenWRT 3.05.3 on TP Link CPE220 v3. I want to reboot my router after specific hours.

1 Reply

[Assistant]
Most people are going to advise against that unless you have a very good reason.

It is not good practice and I'm not going to encourage it unless you can give a very good reason.
Most likely the problem you think a reboot will fix is fixable another way.

Rebooting your router cleans out the device's short-term memory (also called “cache”) to keep it running smoothly . It also allows the router to re-select the least crowded channel for each frequency, which means a stronger connection to your devices.

2 Replies


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [RFE] replace crypt() hash algorithm

Hi,
Currently in use is MD5, broken and insecure. It should be replaced by SHA-512 or Blowfish(bcrypt): https://en.wikipedia.org/wiki/Crypt_(C)#Support_in_operating_systems
EDIT: it looks like Blowfish(bcrypt) is not supported by BusyBox passwd command.
Thanks,

Solved by xosevp in post #10
DONE: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=86e3016896f43fdcd1ee34a8aafe92b2dab9367e https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=10180295b817abb3efdc9db3fb4bb62d585fad7a See ml thread ( [Are we still use md5 as default as password hash?] ) : http://lists.…
1

[Assistant]
More discussion:
github.com/openwrt/openwrt
FS#3911 - Consider changing /etc/shadow's default password hashing algorithm
opened
Jul 3, 2021
openwrt-bot
flyspray
*mcaju:*

Currently the default algorithm used for storing passwords in /etc/sha…
I remember posing this question before. The suggestion was NACKed. Don’t remember why.

Wikipedia…Support of something is one thing and using it is another.
We need to first establish where and what use MD5 to begin with!
CONFIG_CRYPTO_CRC32=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
CONFIG_CRYPTO_LIB_POLY1305_RSIZE=2
# CONFIG_CRYPTO_MD5_OCTEON is not set
CONFIG_CRYPTO_RNG2=y
# CONFIG_CRYPTO_SHA1_OCTEON is not set
# CONFIG_CRYPTO_SHA256_OCTEON is not set
# CONFIG_CRYPTO_SHA512_OCTEON is not set
If I look in kernel config for Octeon is is turned off. Mvebu, Realtek and Ath79 I don’t even find any kernel crypto config.
So is it turned off by default in upstream Kernel?
But then as far as Dropbear question then we come to the subject of what specific crypto hash different packages use. But that isn’t really OpenWrt.
For Luci it is OpenSSL, WolfSSL or mbedTLS that is controlling the crypto solution.

1 Reply

Regarding the /etc/shadow file, only /bin/passwd (busybox) and libc(musl) are involved:
# passwd --help
BusyBox v1.36.1 (2023-11-16 11:38:18 UTC) multi-call binary.

Usage: passwd [-a ALG] [-dlu] [USER]

Change USER's password (default: current user)

        -a ALG  des,md5,sha256/512 (default md5)
        -d      Set password to ''
        -l      Lock (disable) account
        -u      Unlock (enable) account

# ldd  /bin/passwd
        /lib/ld-musl-mips-sf.so.1 (0x77d5c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x77d2a000)
        libc.so => /lib/ld-musl-mips-sf.so.1 (0x77d5c000)


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: IPv6 WAN fail-over without IPv6 NAT

The current recommendation for WAN fail-over is to use mwan3. However, for IPv6, it needs NAT or NPT. This is understandable: mwan3 deals not only with fail-over, but also with load-balancing, and for load-balancing the decision regarding the choice of the source address must be delegated to the router on a per-connection basis, and therefore the originating host in the LAN must use a dummy temporary source address that will be replaced as needed.
However, none of that should be necessary if there is no policy routing involved, i.e. if either all the traffic goes out through WANA or all traffic goes through WANB. Indeed, the prefix delegated from either WANA or from WANB should be directly announced on the LAN, and reannounced with zero validity period during the fail-over if that WAN breaks.
The current "solution" by OpenWrt is to announce all delegated prefixes on the LAN, which also does not make sense in the context of the fail-over to an expensive or slow connection.
I admit that I cannot formulate the feature request more precisely, but the end goal is: simplify the IPv6 WAN fail-over for those who don't care about load balancing, and do not require IPv6 NAT in this setup.
What exactly needs to be done for this is unfortunately unknown. I think of these factors:
Periodic IPv6 connectivity checking as a core feature for all interfaces that have a route to ::/0
Not announcing delegated prefixes for interfaces that are "up" on paper but don't actually work
Not announcing delegated prefixes for interfaces that are "up" but should not be used (e.g. the LTE prefix when the fiber connection is up)

1

[Assistant]
What about sending 2 advertisements, one for each prefix, with a different preference?

2 Replies

I don't know whether all operating systems use the preference in the source selection process. What would be the advantage of announcing this extra useless prefix information? Besides, that still leaves us with the remaining parts - namely, periodic checks, and somehow making sure that prefixes that belong to a WAN that went down or stopped working are immediately depreferred.

Well, you asked for ideas, so there was one.
If the OS doesn't use the preference in the source selection process, NAT6 is the only way.
The remaining parts are simply some checking mechanism, i.e ping, dns query, http get, to verify the availability of the uplink and adjust the RA.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Status-> System log, new text should be at the top, not bottom

Here is what I mean

[Assistant]
See discussion at:
System log - Newest to Oldest?
Installing and Using OpenWrt
Hi Team, Under 'Status - System Log' Is there a way to reverse the output of the System Log? I would like to flip the log so the latest lines appear at the top of the output (newest to oldest).
I tested that "reversed syslog" on my own system, but as I had already used OpenWrt so long, it seemed wrong to have log as new lines on top.

2

Thanks !
I pulled the code from the syslog.js on my system, but it was just one continuous and unreadable line of text.
I asked chatgpt to properly format and indent the code, it returned the following
'use strict';
'require view';
'require fs';
'require ui';

return view.extend({
    load: function() {
        return Promise.all([
            L.resolveDefault(fs.stat('/sbin/logread'), null),
            L.resolveDefault(fs.stat('/usr/sbin/logread'), null)
        ]).then(function(stat) {
            var logger = stat[0] ? stat[0].path : stat[1] ? stat[1].path : null;
            return fs.exec_direct(logger, ['-e', '^']).catch(function(err) {
                ui.addNotification(
                    null,
                    E('p', {}, _('Unable to load log data: ' + err.message))
                );
                return '';
            });
        });
    },
    render: function(logdata) {
        var loglines = logdata.trim().split(/\n/);
        return E([], [
            E('h2', {}, [_('System Log')]),
            E('div', {'id': 'content_syslog'}, [
                E('textarea', {
                    'id': 'syslog',
                    'style': 'font-size:12px',
                    'readonly': 'readonly',
                    'wrap': 'off',
                    'rows': loglines.length + 1
                }, [loglines.join('\n')])
            ])
        ]);
    },
    handleSaveApply: null,
    handleSave: null,
    handleReset: null
});
According to that post, it would be a matter of changing the code
fs.exec_direct('/sbin/logread'
to
loglines.join('\n') => loglines.reverse().join('\n')
Unfortunately, the orignal line no longer exists in the current incarnation of syslog.js

2 Replies

I think that you can see the format from my previous WNDR3700 community build's (Build for WNDR3700v1/v2 / WNDR3800 (discontinued)) download site:
https://www.dropbox.com/sh/t52c02rm20y8x9p/AADxlYKJTMLWFphgVngR1G-_a/master-r18195-d1c7df9c4b-20211127?dl=0&subfolder_nav_tracking=1
...-luci.patch shows the changes:
https://www.dropbox.com/sh/t52c02rm20y8x9p/AADxlYKJTMLWFphgVngR1G-_a/master-r18195-d1c7df9c4b-20211127?dl=0&preview=WNDR3700-master-r18195-d1c7df9c4b-20211127-1006-luci.patch&subfolder_nav_tracking=1
I wanted to show only the 50 last lines, and the code goes like shown below:
I created a seaprate menu item and page for that, so the code is a bit more complex, but the crucial part is:
loglines.join('\n') change to
loglines.slice(-50).reverse().join('\n')
or just
loglines.reverse().join('\n')
key extract:
render: function(logdata) {
+  var loglines = logdata.trim().split(/\n/);
+
+  return E([], [
+   E('h2', {}, [ _('Last 50 lines of System Log (recent on top)') ]),
+   E('div', { 'id': 'content_syslog' }, [
+    E('textarea', {
+     'id': 'syslog',
+     'style': 'font-size:12px',
+     'readonly': 'readonly',
+     'wrap': 'off',
+     'rows': 52
+    }, [ loglines.slice(-50).reverse().join('\n') ])
+   ])
+  ]);
+ },
full code:
diff --git a/modules/luci-mod-status/htdocs/luci-static/resources/view/status/recentlog.js b/modules/luci-mod-status/htdocs/luci-static/resources/view/status/recentlog.js
new file mode 100644
index 000000000..219034a4b
--- /dev/null
+++ b/modules/luci-mod-status/htdocs/luci-static/resources/view/status/recentlog.js
@@ -0,0 +1,33 @@
+'use strict';
+'require fs';
+'require ui';
+
+return L.view.extend({
+ load: function() {
+  return fs.exec_direct('/sbin/logread', [ '-e', '^' ]).catch(function(err) {
+   ui.addNotification(null, E('p', {}, _('Unable to load log data: ' + err.message)));
+   return '';
+  });
+ },
+
+ render: function(logdata) {
+  var loglines = logdata.trim().split(/\n/);
+
+  return E([], [
+   E('h2', {}, [ _('Last 50 lines of System Log (recent on top)') ]),
+   E('div', { 'id': 'content_syslog' }, [
+    E('textarea', {
+     'id': 'syslog',
+     'style': 'font-size:12px',
+     'readonly': 'readonly',
+     'wrap': 'off',
+     'rows': 52
+    }, [ loglines.slice(-50).reverse().join('\n') ])
+   ])
+  ]);
+ },
+
+ handleSaveApply: null,
+ handleSave: null,
+ handleReset: null
+});
diff --git a/modules/luci-mod-status/root/usr/share/luci/menu.d/luci-mod-status.json b/modules/luci-mod-status/root/usr/share/luci/menu.d/luci-mod-status.json
index e726c56b2..3c9fe48c5 100644
--- a/modules/luci-mod-status/root/usr/share/luci/menu.d/luci-mod-status.json
+++ b/modules/luci-mod-status/root/usr/share/luci/menu.d/luci-mod-status.json
@@ -35,9 +35,18 @@
   }
  },

+ "admin/status/recentlog": {
+  "title": "Last 50 lines in log",
+  "order": 4,
+  "action": {
+   "type": "view",
+   "path": "status/recentlog"
+  }
+ },
+
  "admin/status/logs": {
   "title": "System Log",
-  "order": 4,
+  "order": 5,
   "action": {
    "type": "alias",
    "path": "admin/status/logs/syslog"
@@ -67,7 +76,7 @@

  "admin/status/processes": {
   "title": "Processes",
-  "order": 6,
+  "order": 7,
   "action": {
    "type": "view",
    "path": "status/processes"
@@ -92,7 +101,7 @@

  "admin/status/realtime": {
   "title": "Realtime Graphs",
-  "order": 7,
+  "order": 8,
   "action": {
    "type": "alias",
    "path": "admin/status/realtime/load"


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Ethernet port icons on OpenWrt

I came back from Freshtomato to OpenWrt for my latest router. What I am missing from Freshtomato is easy-to-read ethernet port icons. which are excellent on Freshtomato but absent on OpenWrt.
How can I get similar icons on OpenWrt any opkg package or luci plugin et etc?

1 Reply

[Assistant]
KOA:
How can I get similar icons on OpenWrt any opkg package or luci plugin et etc?
Are you sure they're missing?
Browse to: Network > Switch
KOA:
What I am missing from Freshtomato
(Is this OpenWrt-related?)

1 Reply
3

They are 'missing' for DSA though, it seems. I for one cannot find a page that shows them, I only have devices on DSA in 'production'.

1 Reply
3

found, but these aren't animated. first world problems.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Buttonless Failsafe Mode

See:
OpenWrt Wiki – 1 Oct 16
Failsafe Mode, Factory Reset, and Recovery Mode
Failsafe Mode, Factory Reset, and Recovery Mode OpenWrt offers several ways to “start over” with your router. * Failsafe Mode is useful if you have lost control of your device, and it has become inaccessible, perhaps through a configuration...
For devices that are in hard to access locations like outdoor mounted devices or devices that do not have a physical reset button, wouldn't it be a good idea to facilitate a buttonless failsafe mode?
For example, rather than press a button after 5 seconds from power on, how about a device connected to LAN sends a particular packet sequence or similar? Or an SSID is generated with a name and key.
I'm sure there are flaws in my ideas above, but I hope there might be a viable way to facilitate triggering a buttonless return to failsafe mode.
Having just had to reach out a window with a screwdriver and then purchase a ladder following a bad config that blocked access, I think something along these lines might be very useful.

1 Reply
2

[Assistant]
I initially thought you could just touch /tmp/.failsafe, but that’s going to be deleted on reboot right?
Failing any other more clever ideas, what about modifying this file to look for a trigger file in a persistent storage
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/lib/preinit/30_failsafe_wait;hb=3cfa465387ee75451d59a37a3a198bba2deed3ed#l88
It would have to wipe this file once in failsafe.

2 Replies

I'm likely being dense here, but once access to router has been lost, how would you write out that file to persistent storage to trigger the failsafe?
To give some more context, I realise that with LuCi there is the fantastic revert feature whereupon absent reconnection following change, the changes are reverted. But no such feature exists in respect of modifying files over ssh such as /etc/config/network. In fact, there is no error checking whatsoever upon 'service network restart', meaning a bad config file setting (perhaps even just a dot in an interface name?) can give rise to loss of access that persists across reboots. Perhaps a separate feature request ought to be to introduce some basic error checking before accepting a modified network configuration on restart and outputting warning of issues likely to give rise to loss of access.
Another option for buttonless failsafe might be to automatically revert to failsafe if no LAN devices connect post reboot or network change, or something along those lines.

3 Replies

Sorry when you were saying failsafe without physical access, I was more thinking access to a fully functional and ok device. Which would then beg the question, why would you want to reboot such a device to failsafe.
Maybe I’m the dense one


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Applications for LuCI to support LTE/5G modems

Hello everyone
I don't know what the developers or other users think about it, but maybe we could add such packages because nothing has been happening in OpenWrt for years.
I have the impression that many people despise LuCI because there is a console and nothing else is needed.
I tried to add this missing functionality myself (https://github.com/4IceG) and maybe someone on the forum is using my packages (I know they're not great, but it's always better than nothing).

1 Reply
13

[Assistant]
Dear
@IceG
,
As an LTE user myself I agree. Perhaps we could generalize this out; LTE support in general in OpenWrt is lacklustre.
For example, take the LuCi ModemManager protocol. Even in 22.03, ModemManager has to be manually upgraded using an .ipk from master and hacked to achieve automatic reconnection upon an ISP-triggered disconnect event. The problems and possible fixes are known about, but remain as such.
You SMS tool looks pretty nifty.
I suppose an issue we face is that an insufficient number of developers rely upon LTE themselves, and so don't care about the lacklustre LTE support.
Perhaps if more LTE users could chip in with their thoughts in this thread we could help amplify the issue for attention.

1 Reply
5

IceG:
I don't know what the developers or other users think about it, but maybe we could add such packages because nothing has been happening in OpenWrt for years.
Using your packages for my LTE modem and I couldn't agree more,OpenWRT really requires some packages officially.
Apart from that
@IceG
your work on LTE modems is something I really appreciate.

1 Reply
2

Hello everyone
Lynx:
Dear
@IceG
,
As an LTE user myself I agree. Perhaps we could generalize this out; LTE support in general in OpenWrt is lacklustre.
But this is also the fault of the users themselves, I often saw topics on the forum asking for help or support in starting a modem and I saw answers, leave it OpenWrt, install the ROOTer environment, there is support for modems.
Honestly, I was about to delete this topic, seeing the likes and interest, I feel like I made a fool of myself.
The ROOTer team does not care about OpenWrt support for two reasons, they have no desire or need to patch their packages to the high standards of OpenWrt. Another reason is that they earn their support/work, so why would they share/give it up.
Lynx:
You SMS tool looks pretty nifty.
I do not recommend the version for LuCI JS yet. The package has only just been created and still needs a lot of work.
UsamaKhursheed:
Using your packages for my LTE modem and I couldn't agree more,OpenWRT really requires some packages officially.
Apart from that
@IceG
your work on LTE modems is something I really appreciate.
Probably if it wasn't for my Polish mentality and these packages wouldn't exist. In thought.. I will not wait for someone to add such functionality, I will try to add it myself. This way, some users have the opportunity to complain about my packages.

3


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: DSCPCLASSIFY in Main repo?

@yelreve
@ldir

Is there any chance that your package dscpclassify will come into the main repo? I’m using it in my custom builds for a few weeks now and I have to say: good job, it works very well, is easy to use and has some advantages to other DSCP marking packages like qosify.

Solved by yelreve in post #72
Back from my Christmas break now, I hadn't spotted this thread! - Really pleased to see people are getting good use out of the scripts.
@Hudra
seeing your git issue I added the counters functionality before I spotted this forum topic😅, I'll take a look at
@ldir
's/
@amteza
's commits and merge/tweak. …
3

[Assistant]
can i ask you what are the advantages over packages like qosify ?
just curious and i want to give it a shot

One main advantage over qosify (at least for me now) is that qosify only looks at the remote port and not the local port of a specific ip. The readme of qosify says that this feature is planned but who knows when this will happen…
My main use case is gaming and for example cod uses random udp remote ports ranging from 30000-50000 and the local port is always 3074. So, with qosify I can either prioritize all ports from 30000-50000 or use additional iptables/nftables rules to mark the packets.
But adding additional rules has one big disadvantage: iptables/nftables marking only works on egress because tc on ingress runs before dscp marking. So if you want your rules to work on ingress you have to use an ifb, or restore via ctinfo or use tc on your wan and lan (which probably isn’t the best approach if you have a bridge with wifi etc…) which all can be complicated…
With DSCPCLASSIFY I can just prioritize local port 3074 of my gaming pc.
What DSCPCLASSIFY does is it uses ctinfo to restore the DSCP mark of a flow on ingress and it’s also integrated into sqm as sqm script so you have a UI (at least for the tc part).
And also, the config file uses the same syntax as OpenWrt’s firewall config so setting up DSCP marks is also pretty straight forward.
More info on their github readme:
GitHub
GitHub - jeverley/dscpclassify: An nftables based service for applying DSCP...
An nftables based service for applying DSCP classifications to connections, compatible with OpenWrt's firewall4 for dynamically setting DSCP packet marks (this only works in OpenWrt 22.03 and a...
GitHub
GitHub - ldir-EDB0/dscpclassify: nftables ruleset for OpenWrt fw4 for...
nftables ruleset for OpenWrt fw4 for dynamically setting DSCP packet marks - GitHub - ldir-EDB0/dscpclassify: nftables ruleset for OpenWrt fw4 for dynamically setting DSCP packet marks

3 Replies
1

im using it right now with sqm but dscp markings don't seem to work at all on ingress
root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 128535308540 bytes 158278519 pkt (dropped 2, overlimits 0 requeues 29351)
 backlog 0b 0p requeues 29351
  maxpacket 1514 drop_overlimit 0 new_flow_count 25563 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.1 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 804e: dev eth0.2 root refcnt 2 bandwidth 700Kbit diffserv8 dual-srchost nat nowash ack-filter split-gso rtt 100ms atm overhead 36
 Sent 51980434 bytes 263407 pkt (dropped 26588, overlimits 244552 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 4215602b of 4Mb
 capacity estimate: 700Kbit
 min/max network layer size:           28 /    1492
 min/max overhead-adjusted size:      106 /    1696
 average network hdr offset:           14

                  Tin 0        Tin 1        Tin 2        Tin 3        Tin 4        Tin 5        Tin 6        Tin 7
  thresh        700Kbit    612496bit    535928bit    468936bit    410312bit    359016bit    314136bit    274864bit
  target           26ms       29.7ms         34ms       38.8ms       44.4ms       50.7ms         58ms       66.3ms
  interval        121ms        125ms        129ms        134ms        139ms        146ms        153ms        161ms
  pk_delay          0us          0us       41.9ms          0us          0us       13.2ms       12.7ms       6.76ms
  av_delay          0us          0us       5.14ms          0us          0us       1.03ms       2.74ms        461us
  sp_delay          0us          0us         90us          0us          0us        133us        238us         19us
  backlog            0b           0b           0b           0b           0b           0b           0b           0b
  pkts                0            0       207869            0            0          155        81654          317
  bytes               0            0     40767491            0            0        14688     15760199        13512
  way_inds            0            0         1064            0            0            0            0            0
  way_miss            0            0         1935            0            0          143          926            2
  way_cols            0            0            0            0            0            0            0            0
  drops               0            0         3618            0            0            0            0            0
  marks               0            0         3571            0            0            0            0            0
  ack_drop            0            0        22970            0            0            0            0            0
  sp_flows            0            0            1            0            0            2            1            0
  bk_flows            0            0            1            0            0            0            0            0
  un_flows            0            0            0            0            0            0            0            0
  max_len             0            0        17061            0            0          379         1342          240
  quantum           300          300          300          300          300          300          300          300

qdisc clsact ffff: dev eth0.2 parent ffff:fff1
 Sent 120208152550 bytes 137226444 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev ifb-dns root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 1346336 bytes 7994 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc cake 804f: dev ifb4eth0.2 root refcnt 2 bandwidth 12Mbit diffserv8 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms atm overhead 36
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 0b of 4Mb
 capacity estimate: 12Mbit
 min/max network layer size:        65535 /       0
 min/max overhead-adjusted size:    65535 /       0
 average network hdr offset:            0

                  Tin 0        Tin 1        Tin 2        Tin 3        Tin 4        Tin 5        Tin 6        Tin 7
  thresh         12Mbit    10500Kbit     9187Kbit     8039Kbit     7034Kbit     6154Kbit     5385Kbit     4712Kbit
  target            5ms          5ms          5ms          5ms          5ms          5ms          5ms          5ms
  interval        100ms        100ms        100ms        100ms        100ms        100ms        100ms        100ms
  pk_delay          0us          0us          0us          0us          0us          0us          0us          0us
  av_delay          0us          0us          0us          0us          0us          0us          0us          0us
  sp_delay          0us          0us          0us          0us          0us          0us          0us          0us
  backlog            0b           0b           0b           0b           0b           0b           0b           0b
  pkts                0            0            0            0            0            0            0            0
  bytes               0            0            0            0            0            0            0            0
  way_inds            0            0            0            0            0            0            0            0
  way_miss            0            0            0            0            0            0            0            0
  way_cols            0            0            0            0            0            0            0            0
  drops               0            0            0            0            0            0            0            0
  marks               0            0            0            0            0            0            0            0
  ack_drop            0            0            0            0            0            0            0            0
  sp_flows            0            0            0            0            0            0            0            0
  bk_flows            0            0            0            0            0            0            0            0
  un_flows            0            0            0            0            0            0            0            0
  max_len             0            0            0            0            0            0            0            0
  quantum           366          320          300          300          300          300          300          300


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: IP-MAC Binding

enforce Static Lease.
Even when using Static Lease clients can use any IP they want.
https://www.makeuseof.com/what-is-mac-binding-how-does-it-work/

1 Reply

[Assistant]
RSHARM
updated the threat
I guess you mean "thread" instead of "threat"...
RSHARM:
Even when using Static Lease clients can use any IP they want.
https://www.makeuseof.com/what-is-mac-binding-how-does-it-work/
Whoever wrote that article does not know what they are talking about... period. Assigning a static IP address on the DHCP server, does not prevent any device from using any IP address; there is not even the need to spoof the MAC address. You do not even need a DHCP server or a router to have a functioning network.
This could only work on wireless networks, where you can block/allow access by MAC address; but you cannot prevent MAC spoofing. If you need real network security, use IEEE 802.1X.

3

eduperez:
Assigning a static IP address on the DHCP server, does not prevent any device from using any IP address
That is why a feature to limit a IP to a MAC
This could only work on wireless networks, where you can block/allow access by MAC address;
Why?
but you cannot prevent MAC spoofing. If you need real network security,
It is still something
IEEE 802.1X.
Is it like Captive Portal ?
Other OS have IP MAC binding
tp-link.com
How to configure IP&MAC Binding Wi-Fi Routers (new logo) | TP-Link
How to configure IP&MAC Binding Wi-Fi Routers (new logo)
Cisco
Configuring Controller Settings - Configuring IP-MAC Address Binding ...
https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01101.html.xml
Also See
superuser.com
What is the difference between ARP binding and DHCP address reservation?
networking, router, routing, dhcp
asked by totymedli on 02:43AM - 22 Apr 15 UTC

You can have static ARP entries with Linux too using ip neighbor.
And no. 802.1x is not used for/to be a captive portal...

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Add “DNS” setting to static lease configuration

This is a companion request to Add "default gateway" setting to static lease configuration
In some cases, it might make sense to point certain devices to difference DNS servers
For instance I might have google's dns, my ISP's dns, a pihole, my VPN's DNS and other DNS with special exclusion list, for instance a dns server that will not resolve any of Microsoft's, apple's, facebook's and all of China's DNS records.
And it would be helpful to switch certain devices between each of those choices from the static lease configuration page.
Here is what that might look like
Like the other feature request, the list of DNS servers might be a little drop down menus where you can select from a multitude of known DNS servers.

4

[Assistant]
What's wrong with the standard, OpenWrt and RFC-method way of doing so?
Configure host-specific DNS server over DHCP (option 6)
Network and Wireless Configuration
The example shows how to set certain hosts to use other DNS servers via DHCP Option No. 6.

1

Cannot be done in the interface, as shown in screenshots, the option is missing

1

shodanx:
Cannot be done in the interface
Unless I've mistaken, you're literally showing it in your screenshot.
I'm guessing you mean web interface (can't determine since you show it)?
You may want to clarify and provide more details.
Are you asking for OpenWrt to "guess" public DNS servers people wish to use, and then have a pre-screened list already added?


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Enabling dynamic DNS is too convoluted, difficult

Hi,
TL;DR See Step 9 for the actual request for this feature request
Needed to setup dynamic dns, I was surprised that it I hadn't previously made it work.
During setup I realized I had given up on it last time I tried it.
So I'm using freedns.afraid.org and here is what the setup looks like
Step 1
Go to System -> Software
Click on Updates lists, wait a little and then click dismiss
In the filter type "ddns"
Now choose among this list the appropriate software that needs to be installed
In my specific case that was
ddns-scripts-services
ddns-scripts-freedns
luci-app-ddns
Click on each, click install, the dependencies are fine
Step 2 setup
Refresh interface a few times until
Services -> Dynamic DNS
appears, and click on it
Delete the two examples IPv4 and IPv6, they cannot help you
Step 3 get special URL
Go to freedns.afraid.org, the dynamic dns section, specifically
freedns.afraid.org
FreeDNS - Free subdomain AND domain hosting!
Free DNS hosting, lets you fully manage your own domain. Dynamic DNS and Static DNS services available. You may also create hosts off other domains that we host upon the domain owners consent, we have several domains to choose from!
You must already have created your A and AAAA records, if not, do that first
For the revelant record get your "Direct URL", it will look something like this
https://freedns.afraid.org/dynamic/update.php?bnXXXXXXXIUYYYYYYYYGVpMZZZZZZZZZAxNjE=
Step 4 final setup
Now return to your router configuration page
https://router.lan/cgi-bin/luci/admin/services/ddns
Click "add new services..."
In Name, DON'T write your domain name, that will make an error that it already exists, maybe, just write something with no space or punctuation that isn't your domainname exactly
Next choose your "DDNS Service provider"
The list is not in alphanumeric order, select this one
Now click Create service, it will make an error, don't worry about it, it's an error of success
Dismiss the other error, it's fine, it means it works
Here you will need to read the docs
Read
OpenWrt Wiki – 23 Apr 17
DDNS client
DDNS client See also: DDNS client configuration Introduction DDNS stands for Dynamic DNS. Simply put, using this service gives a name to your IP. So if you're hosting something on your line, people would not have to bother typing your IP. They can...
and specifically
OpenWrt Wiki – 23 Apr 17
DDNS client
DDNS client See also: DDNS client configuration Introduction DDNS stands for Dynamic DNS. Simply put, using this service gives a name to your IP. So if you're hosting something on your line, people would not have to bother typing your IP. They can...
There are four options for setup, the fourth option is the correct one ! The other will save plaintext password to your DNS on the device, don't use them, unless option four doesn't actually work
In Lookup Hostname write your actual dynamic domain name
DDNS Service provider should already be afraid.org-keyauth
In domain, write your actual dynamic domain name
In username, you don't have anything to write here, but you also HAVE to write something here, write any nonsense, for instance "BLABLBLABLBLABLA"
Next password, this isn't your password, this is your key
So remember the direct URL from before
https://freedns.afraid.org/dynamic/update.php?bnXXXXXXXIUYYYYYYYYGVpMZZZZZZZZZAxNjE=
Your key is everything after the ? character
So, write bnXXXXXXXIUYYYYYYYYGVpMZZZZZZZZZAxNjE=
Don't check "Use HTTP Secure", that will probably break it,
If you click it anyway you will have to answer the Sphinx's following riddle
Path to CA-Certificate
And it's a trick question, you don't have that, the answer is literally to write IGNORE in that textbox
Your settings panel should now look like something like this
Click Save
Step 5 Using it
Now it doesn't work, click restart
You should see this friendly error message
And the line of your service should look something like this
Step 6 testing it
Now everything looks like it should work, let's try to ping our domain
If you get this message it means you have followed my instructions perfectly !
Now your results might look different, something about receiving a ping reply
This is probably because when you created your A record, the DNS server automatically filled in your current IP address already. In this case, wait several weeks for your IP address to randomly change, then you should see the message from the above command line, at this point you can proceed to Step 7
Step 7 Give up
Find a dark secluded area and lie down, wait until your breathing ceases
Step 8 Ask for divine intervention from the machine
Step 9 Write feature request to make setup easier
This that could be improved to make setting this up easier
It should be easier to find what packages to install in software
The DDNS service provider should be in alphanumeric sort order
There should be a link to the openwrt wiki page for the chosen DDNS Service provider (https://openwrt.org/docs/guide-user/services/ddns/client#freednsafraidorg)
If the user already has an update URL, there should be a very obvious place he can paste it in, this URL probably would have most of the required information to auto-fill the rest of the settings page,
The Username, for DDNS Service provider where it does not matter, it should not be visible, if it has to be visible, it should be acceptable to leave it blank.
If the setting HTTP Secure is checked then, it should be acceptable to leave Path to CA-Certificate blank or pre-fill the textbox with "IGNORE", or have a button that will download the appropriate certificate file, place it in the appropriate location and fill in the Path in this textbox. If the certificate is autodownloaded, the signature should be presented to the user with the message "We cannot verify the signature of this certificate, show signature, do you accept it ? Yes/No
HTTP Secure should probably be on by default, but it probably should "just work" by default, without requiring further user input or else the user will probably skip this security feature entirely while he is hunting for the solution for his other problems.
Fixing, well I don't know what my current problem is, it's very weird but I'm out of ideas

1 Reply
1

[Assistant]
And to anyone struggling with the exact same specific issue I was having
Which was that my WAN port is connected into another mandatory router from the GPON ISP with no bridge capability
Go to edit and check the "Log File Viewer" for clues
And then set for external URL IP checking
Of course now an IP change will translate into up to 10 minutes of downtime but I don't see a better option until I managed to reprogram my GPON SFP

1 Reply

who not add all this to the Wiki, via Applying for OpenWrt wiki account ?

1

I have a wiki account, but that wiki page is already 50 pages long and I have already spent my sunday evening figuring out and documenting my attempt. Sorry but I'm spent.
Also I believe that much of this documentation could be dispensed with, if the UI of luci-ddns could be make a bit more user friendly and resilient.
The points that need attention, I have highlighted near the end of my post and I would add, for my specific case, make ddns script parse the log file, and automatically (or ask user) switch to URL resolving of the external address when the WAN IP is a invalid or private address.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Initial network configuration via firmware selector

There is a very useful server already, https://firmware-selector.openwrt.org/. It allows one to customize the downloaded image by supplying the list of installed packages and the first-boot script (uci-defaults).
The feature request is to improve the user experience by providing ready-made uci-defaults templates for basic tasks such as configuring the static IP on the WAN, or setting up PPPoE credentials, or setting up WiFi SSID and password, or enabling/disabling IPv6. Just a link to a wiki page with examples that can be copy-pasted is enough to consider this feature request done, but of course a GUI will be better.

Solved by mwarning in post #9
I do not think there is a need to set the channel and the device. Also not every router has two wireless devices. A simple uci set wireless.@wifi-iface[0].ssid='My AP' uci set wireless.@wifi-iface[0].encryption='psk2' uci set wireless.@wifi-iface[0].key='xxxxxxxxxx' uci commit wireless seems to b…
1 Reply
2

[Assistant]
You have it more or less ready. The firmware selector has a textarea to add a script to execute the first boot. If you include here the uci commands to do this config, will work (I suppose, I've not tried it).
The only thing missing is a link to the web page with samples.

patrakov:
Just a link to a wiki page with examples that can be copy-pasted is enough to consider this feature request done
McGiverGim:
The only thing missing is a link to the web page with samples.
The OpenWrt Firmware Selector
Release and security announcements
@aparcar
now added a field that let the user add a script to custom images: [archer] This script e.g. would automatically enable and configure the WiFi: # WiFi password (at least 8 characters) key="12345678" # WiFi name ssid="OpenWrt" wifi_enable_device() { local cfg="$1" uci set wireless.$cfg.disabled='0' } wifi_setup_interface() { local cfg="$1" uci set wireless.$cfg.ssid="$ssid" uci set wireless.$cfg.key="$key" uci set wireless.$cfg.encryption="psk2" } config_load wireless …

I made a feature request ticket: https://gitlab.com/openwrt/web/firmware-selector-openwrt-org/-/issues/36

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: LUCI - add support for managing tags in DHCP and DNS configuration web page

Hello,
I use tags in dnsmasq configuration for adding specific DCHP options to static leases.
I can assign existing freeform tags to static leases form the web page, but I have to add the tags manually in the configuration.
So, it would be nice if there was a way for adding/ removing/ editing tags using the DHCP and DNS configuration web page, instead of having to add them using uci or by manually editing the /etc/config/dhcp file.
Thank you in advance,
Panos

Solved by systemcrash in post #12
Yes, I have this case covered in my patch-set - it is not in master yet - and things will change before it finally arrives: [Screenshot 2023-11-23 at 23.13.50] Setting up the tags: [Screenshot 2023-11-23 at 23.11.48]
1 Reply
2

[Assistant]
panosst:
I use tags in dnsmasq configuration for adding specific DCHP options to static leases.
I apologize as I don't intend to take this thread away from your request, but I was not aware of this functionality and I have a question if you don't mind.
Do these tags allow you to send out DHCP Option 6 to certain clients for specific DNS addresses, while sending out another DHCP Option 6 to other clients for specific DNS addresses?
I spent some time reading the dnsmasq manpage after seeing your post here. But I have to admit, I feel confused about it to a certain extent. If you could possibly share a couple of snippets/examples of how you use it, that would be appreciated. Thank you.

2 Replies

It works in the following way:
you add a tag with the dhcp option you want in the configuration
ex.
subnet mask 255.255.255.0 , gateway 192.168.151.10, dns servers 192.168.151.10 and 192.168.151.11
config tag 'net2'
 list dhcp_option '1,255.255.255.0'
 list dhcp_option '3,192.168.151.10'
 list dhcp_option '6,192.168.151.10,192.168.151.11'
route 192.168.1.0/24 -> 192.168.151.10 and route 192.168.124.34/32 -> 192.168.151.11
config tag 'route3'
 list dhcp_option '121,192.168.1.0/24,192.168.151.10,192.168.124.34/32,192.168.151.11'
and then in the web interface you add these two tags, net2 and route3 (both or one of them) to the static leases/hosts/clients you want to use them and for example the hosts configuration looks like this:
config host
 option name 'testPC2'
 option mac '12:34:56:78:9a:bc'
 option ip '192.168.151.61'
 option leasetime '12h'
 list tag 'net2'
 list tag 'route3'
The second part, adding tags to the host already works from the web gui.
The first part, creating the tag does not work from the web gui, this is what i asked for.

2 Replies
1

Thank you so much, I appreciate it. Seeing your examples in OpenWrt-specific dhcp config format definitely helps me understand it much better now. This is fantastic. Lots of possibilities with tags which is great.
I would also like to second your feature request. I think having this functionality within LuCI to manage tags better would be good to have.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [LuCI; Wi-Fi] Move Country Code from “Advanced Settings” to “General Setup”

I suggest to move Country Code setting in LuCI web interface
(Network -> Wireless -> radioX "Add" or SSID-X "Edit")
from Advanced Settings to General Setup, as it is mandatory for channel availability.
Background from someone that hasn't configured OpenWrt routers for years:
After 2.4 and 5Ghz Wi-Fi setup, I wondered why my access point still displayed 5GHz network as "disabled" for most channels and wasn't able to connect.
Till I found Advanced Settings and switched Country Code accordingly (initial value was driver default), my conclusion was, the router's 5GHz band must have been damaged, so I already thought about sending it back.
The Quick Start guide does not suggest to change this setting either in the Wi-Fi section.
Enhancement: Maybe even define a global Country Code setting amongst all radios for simplicity?
This change might help other newcomers as well. What do you think?

6

[Assistant]
My main thought is radios disabled and either force user to pick a location and/or have the defaults be the most restrictive regulatory DB so you don't transmit when you're not meant to transmit. LuCI banner? Screwing that up is most likely a federal offence everywhere.
First thing I do on all AP's all the time is change country code because I'm not in US.
But that's only a problem really because I factory reset my AP's a lot and run SMB sized deployments.
But once I knew how to do custom images (with image builder locally, or with firmware selector) i.e. uci defaults, most of the problem went away.
Perhaps more knobs on firmware selector? I have no idea what the right solution is other than let users know that they should change their location.
I guess it's a blind spot once you know you need to configure it and where it is in openwrt, or you just keep porting your config through version updates.
edit: my next thought was some sort of location detection package for people who don't know how to set it but that's fraught with danger =P

2 Replies

evs:
and/or have the defaults be the most restrictive regulatory DB so you don't transmit when you're not meant to transmit
In most cases this default country code is called "World" - with a code of 00.

2 Replies
2

evs:
I have no idea what the right solution is other than let users know that they should change their location.
That would be a good start . Maybe a paragraph about country code in the quick start for Wi-Fi?
But then I have an issue with the wording "Advanced Settings", as it suggests an optional setting for more technical users. But Country Code seems to be mandatory for proper channel choice.
Another low hanging fruit would be to disable all channels in LuCI, that cannot be selected due to Country Code. I was able to select every channel, and afterwards just got a "disabled" interface in web interface without connectivity. This is no good user experience for newcomers in my opinion.
Btw: my firmware is 23.05.5.
lleachii:
In most cases this default country code is called "World" - with a code of 00.
Interesting. For me it was "driver default", not sure if that makes a difference.

4 Replies
2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Home assistant

Hi,
I know there was a topic with this subject. I know that there are some attemps on github to make integration for home assistant. I know that there is two official integration for openwrt in home assistant.
But, don't get me wrong because I don't know how to write this without to maybe offend people doing their best in their free time, are just not good enough,
Can we finally have a nice ingratiation for openwrt routers in home assistant? But that I mean gui, click and go. Just look at integration for other routers vendors. They are way better then you can get on openwrt. But on the other hand openwrt is way better then most of them can offer.
I'm pretty sure I'm not the only guy using openwrt and having home assistant. I'm not developer and I can't help in that way because I obviously don't have enough knowledge and skill to do it.
But can eventually something be done? And is there a way that we who are using home assistant can help?

1 Reply
1

[Assistant]
dandek01:
two official integration
I'm not aware that either of them are 'official' (by which I assume you mean created by the openwrt devs).
dandek01:
But can eventually something be done?
Yeah, eventually someone with the required knowledge, skills, free time, and desire to create an integration may come along and create something. If that's not good enough then I guess you'll have to roll up your sleeves and have a go yourself.

2

krazeh:
I'm not aware that either of them are 'official' (by which I assume you mean created by the openwrt devs).
By official I meant home assistant integration.
krazeh:
If that's not good enough then I guess you'll have to roll up your sleeves and have a go yourself.
This where I don't want this eventual discussion goes. If it is not good enough for me?
Have you ever tried those integrations? And have you tried other integrations for other routers? If you have time please do so. And I'm pretty sure you will notice some difference.

1 Reply

What do you want the integrations to do? That’s the question.
I’m aware of the presence integration which takes advantage of the ubus api to get an auth token and then make calls. The only parameters required are login and password. Pretty simple to set up, why does it need to be more grand than that?
Do you want the OpenWrt configuration side automated or the HA side automated, or both?
I don’t think someone will pick this task up unless it is of specific interest to them. HA generally requires some manual configuration skills, this doesn’t feel like a large hurdle in this instance.
Yes, I’ve used it.

1 Reply
3


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Implement easy reboot schedule

Hello.
I think it would be helpful to add easy reboot scheduler option on the System > Reboot tab. So you don't have to set up commands all the time. I use it on all of my devices and i believe most of other users too.

1 Reply
1

[Assistant]
Without dismissing your request, are we allowed to ask why you want/need to reboot all your devices on a schedule?
i believe most of other users too
I honestly don't think so.

2

I meant this for home and office use. I'm talking about weekly/monthly reboots to avoid stability or performance issues that may rise up over time.

3 Replies

chosik:
So you don't have to set up commands all the time
why not cron it ?

1 Reply
1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Would you support requiring a USB stick for all devices in order to eliminate storage space limitations?

OpenWrt has been struggling with the flash space on small devices for a long time. Hell, it struggles with what to do with ample storage space on large devices, but that's another topic.
The vast majority of those same small-flash-space, though, have USB capability. It wouldn't actually be all that difficult to make the internal flash space a secondary bootloader that booted a device from USB. While this would do nothing for the RAM in small devices, it would eliminate virtually all storage space limitations across the board. The cost is that everyone would need a USB stick of some sort to use OpenWrt.
So, I'm curious, what is the consensus on requiring a USB stick in order to use OpenWrt if it means eliminating storage space limitations across the board.
YES - I support requiring a USB stick for all devices to elimitate storage space limitations
NO - Let's stick with the way it is
47 voters
Results

[Assistant]
Keep in mind that quite a few of the affected devices don't even have USB ports to begin with (tl-wr841n, most of the xiaomi devices, etc.). Low flash usually goes hand in hand with low RAM as well, so not much to be gained from 'huge' USB storage.

1 Reply
7

slh:
low RAM
Yes, thank-you. I did mention that in the OP. That said...
slh:
the affected devices
... virtually all devices are affected. I would assert that virtually all devices are more hampered by their limitation on storage than they by their RAM.
With more storage space you can add swap. With more storage space the average user can use opkg to swap out features they don't need for ones they want. Something you can't otherwise do without a custom build or a new custom image. And, it eliminates wear on irreplaceable internal flash, something that OpenWrt is hard on.
In any case, this isn't about convincing people. I'm honestly curious about the perception.

4 MB devices are definitively hampered by their flash size, no doubts about that.
Starting around 8 MB (even considering the announcement to deprecate 8/64) that holds less truth for the time being. On the one hand going from wolfssl to mbedtls will recover a little space, on the other hand there are some things to keep 8 MB flash devices going for a few more years (opkg, mbedtls (and with that losing https access and wpa3, neither of which would be a major problem for now) - the problem just is that neither of these do enough to help out on 4 MB flash.
Pretty much all (very few exceptions exist) devices that fall into the 4 MB flash category will however also fall into the 32 MB RAM category, and that is a real problem right now already. Depending on the target, its RAM hunger (xDSL modems allocating some RAM for device firmware), this may range from failing to boot a 'normal' image to failing under duress (WLAN on, multiple connected STAtions). The problem of rising image sizes is the upgrade process needing to master them - e.g. I'm already in a situation where I have to aggressively kill processes and prevent kernel modules from loading to be able to sysupgrade successfully (8/32 devices).
swap on flash (regardless of internal flash (even worse, due to flash wear) or USB (aside from very highend USB stick or SSDs, but you aren't very likely to use to on a 4/32 device) is something that's never a good idea (as it slows down the device massively and damages the swap location).
I do actually think that chainloading OpenWrt from USB might be a nice option, but it will fail for many devices that would need it most - and even where it does work, the low RAM sizes keep its effective improvements limited (you may now phyiscally have the storage space for larger images, but increase the RAM pressure even more).
Then I'm quite concerned about the exact terminology you're using here, as I read it as all devices without USB slots will no longer be supported ("Would you support requiring a USB stick for all devices", which seems to be re-affirmed by "Hell, it struggles with what to do with ample storage space on large devices" and gets rather explicit with "The cost is that everyone would need a USB stick of some sort to use OpenWrt").
My answer to this would be a firm, "no, hell no!".
Quite a few mid- to highend devices these days (802.11ac and 802.11ax) come with healthy amounts of internal flash (256 MB NAND is common there, of which often around 80-100 MB can be used (dual-firmware), down to ~40 MB on some Linksys ones, not great, but not a hindrance for using OpenWrt as a router), but don't have any USB ports (the SOCs all have it, but many brandnew devices don't bring them out) or other means of adding removable storage (nor eSATA, nor sdhc). USB3 ports have become a rarity over the last 2-3 years (at best you may get one USB2 port, but even that's no longer common), even for high-end and popular -already fully supported- devices. This idea -especially following your intended phrasing of 'must have USB'- would break many very useful 802.11ax devices users have bought within the last 2-3 years needlessly.

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Feature Request : White-list only internet access for new DHCP clients

Hi,
If you're like me, you have several hostiles devices that will automaticall self-destruct if ever allowed to use their call-home backdoor on the unfiltered internet.
What we need to not accidentally destroy these devices is White List Only internet access for unknown device.
Or "DHCP client whitelist", not sure exactly what to call this, it has other uses.
So first how to do this.
Easy mode is, somehow set default Gateway for dnsmasq either to a unused address on your network, or maybe if that's possible, give no gateway address ?
First warning here, Android devices will bounce off a wifi that doesn't give them a valid gateway address and we might also need "fakeinternet" as part of this package.
Ok, now, a new unknown device connects to the network, it gets a dynamic address and a wrong or blank gateway. We're half-way there already !
Next, each new dhcp client needs to be added to the whitelist file /etc/config/dhcp
First thing, we need a tag that contains the good gateway address
config tag 'good_gateway'
        list dhcp_option '3,192.168.1.88'
        list dhcp_option '6,192.168.1.112'
This will set both the gateway, helpfully named dhcp_option '3 and the DNS named dhcp_option '6
Last step, adding dhcp clients to the whitelist
config host
        option name 'mycomputersname'
        option dns '1'
        option mac 'AB:CD:00:12:34:5F'
        option ip '192.168.1.10'
        option tag 'good_gateway'
I'm not sure if option dns '1' needs to be defined
I don't know if you have to decide on an ip address for every single device with option ip '192.168.1.10' preferably this line can be left off and every client just gets an address from the pool
I don't know if you can specify more than one tag per client, that would be great
And now, the Feature Request part of this message
It should be possible in LuCI to do this without modifying config files
So here is what needs to change to perform the minimum requirements
First, there needs to be a way to set the DHCP server's default gateway IP
I had a look in the current interface and I cannot see how to specify a blank or invalid or unused IP address as the gateway address
I had a look at the config files, but still can't tell where the dhcp server is being told what gateway to use
It is probably using the br-lan interface called WAN's IP address
But I don't want to set that address to a blank, invalid or unused address !
So I have to find how to set the dhcp server's default gateway address to an arbitrary value
Ah, it might be addign
option '3,192.168.1.88'
to the config dnsmasq section of /etc/config/dhcp
--------FEATURE REQUEST HERE !--------
So, ok ! Please add the ability to specify Option 3
To https://router.lan/cgi-bin/luci/admin/network/dhcp the "General Settings" page
(also option 6 DNS please)
(Also, if if you're feeling fancy, check if the option is hardcoded in the config file, if it isn't then write "automatic" in the text box, maybe with the current value "automatic(192.168.1.1)"
--------FEATURE REQUEST HERE !--------
Next, we need to define tags and assign them to static leases
First we need a way to list and assign, at least one, tag to a static lease
This is on the Static Lease page
(how do I make a link to the static lease page ?! It always links to https://router.lan/cgi-bin/luci/admin/network/dhcp#)
This is on the Static Lease page
As you can see, no way to set a tag
So, what we need here is
A combobox where you can see all the defined tags, and choose, at least, one
Then add, at least one, tag name to the "config host" section of the config file for that host
The text is literally
        option tag 'good_gateway'
--------FEATURE REQUEST HERE !--------
Add ability to select one (or more) tag on the "DHCP and DNS/Static leases/my host/Edit" page
--------FEATURE REQUEST HERE !--------
Also, how do I NOT set an hardcoded IP address here ?
Can I just leave IPv4 address blank here ?
I'm going to need to make so many host definition, I don't want to give them all an hand picked fixed address ! It should be obvious how to create a "dynamic static lease", yes, you read that right.
Ok next we need to create Tags with our settings
Tags are really simple it's just this text
config tag 'deadend_gateway'
        list dhcp_option '3,192.168.1.254'
        list dhcp_option '6,192.168.1.253'
config tag 'good_gateway'
        list dhcp_option '3,192.168.1.88'
        list dhcp_option '4,192.168.1.55'
        list dhcp_option '6,192.168.1.112'
Oh BTW, option 4 is the NTP server
config tag 'Android_fakeinternet_gateway'
        list dhcp_option '3,192.168.1.36'
        list dhcp_option '6,192.168.1.111'
In this case 192.168.1.111 is a DNS server which runs anti-google DNS filtering
and 192.168.1.36 is a gateway with google/android style fakeinternet
config tag 'Android_filtered_gateway'
        list dhcp_option '3,192.168.1.35'
        list dhcp_option '6,192.168.1.111'
And this is good internet, but all the google websites are DNS filtered AND IP Banned from that gateway
--------FEATURE REQUEST HERE !--------
Ability to see, list, create and modify DHCP option tags
In https://router.lan/cgi-bin/luci/admin/network/dhcp# probably a newtab, similar to "IP Sets" but call it "DHCP Tags", create custom tags and add them to the file /etc/config/dhcp
--------FEATURE REQUEST HERE !--------

2 Replies
1

[Assistant]
While this is not exactly the answer you are looking for: Why don't you just create Firewall rules instead?
You could block all traffic by default and only allow Internet access based on the MAC address.
And/or separate your network into VLANs, where the "trusted" VLAN has Internet access enabled by default and the "untrusted" network requires explicit access permissions.

1

@andyboeh
That seems more difficult
Now all the packets would need to be inspected by a firewall, adding a per packet amount of cputime spent on firewalling. I don't think my archer c7 will still work at 300mbps if I enable the firewall.
Also I haven't figured out how to make firewall rules that follow dynamic IP around. I don't wish to spend time assigning and maintaining lists of static IP addresses.
Doing it in the dhcp server seems like the clean way.
I don't expect hostile devices to find their own way to the gateway and disregard dhcp settings, yet.
Even if a firewall was involved, then I would still want the "dynamic static leases" in the dhcp server and they would have to drive the firewall addresses.
So, dhcp internet whitelisting has to work first.

shodanx:
Now all the packets would need to be inspected by a firewall, adding a per packet amount of cputime spent on firewalling. I don't think my archer c7 will still work at 300mbps if I enable the firewall.
Yes. I assumed that you were talking about your main router that already has a firewall enabled. Your C7 needs to process every single packet anyway for NAT to work properly, the additional overhead consist of a simple address check.
shodanx:
Also I haven't figured out how to make firewall rules that follow dynamic IP around. I don't wish to spend time assigning and maintaining lists of static IP addresses.
You don't need to. Use the MAC address instead, the DHCP server manages its clients also based on the MAC address.
shodanx:
Even if a firewall was involved, then I would still want the "dynamic static leases" in the dhcp server and they would have to drive the firewall addresses.
You can still use static DHCP leases, no problem here.

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Prevent default ssh login from internet

By default openwrt allow to login everybody to your router as root with weak or even without a password. Which can be a problem for some cases.
To solve the issues I made a patch which prevent any password ssh logins from internet, only local lan logins are allowed.
gitlab.com
axet/openwrt-tl-wr842nd-v2/-/blob/master/packages/network/services/dropbear/patches/lanpass.patch
I recommend it for everyone. Even better - to include it to the default openwrt build.

1 Reply

[Assistant]
axet:
By default openwrt allow to login everybody to your router as root with weak or even without a password. Which can be a problem for some cases.
No, it does not. The firewall prevents access to the SSH port by default. If you're testing with your WAN IP from the internal network, it is still going to work. Please test again from a different internet connection and you will see that it's not possible to log in.

5

You right. It is protected by firewall. But for some cases you want to open your dropbear to internet. And better if dropbear will prevent password logins from internet by default but not from local network.

1 Reply

Isn't this configurable already?
config dropbear
 option Port '22'
 option Interface 'lan'
 option PasswordAuth 'on'

config dropbear
 option Port '22'
 option Interface 'wan'
 option PasswordAuth 'off'
 option RootPasswordAuth 'off'

config dropbear
 option Port '22'
 option Interface 'wan6'
 option PasswordAuth 'off'
 option RootPasswordAuth 'off'

1 Reply
5


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: OpenWrt http/s redirection

Hello there, I just need some help with redirection, I tried to learn opennds but then, it is too much for a single webpage to be shown when redirected. So is there any way that I can bypass the browser's request for certificate authenticity? Or atleast the browser can show the "ACCEPT THE RISK AND CONTINUE" button when the webpage is not safe? Because I have tried various browsers, especially those famous browsers but then they didn't allow the webpage I created to be loaded. Or is it possible to return a 302 or 307 status code when being redirected?

this shows that there is no "ACCEPT THE RISK AND CONTINUE" button.
Thanks for the help.

[Assistant]
Can you elaborate on how OpenWrt is related here?

1 Reply

... or just get a proper cert ?
they're free

1 Reply

Well, I just wanted to redirect all ip's that are not registered from my iptables to another webpage that I created. But then the browser doesn't seem to honor the self-signed certificate that I had. So I don't know where to ask. But I saw this forum and tried to get help


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Use .home.arpa as default TLD for local network

RFC 8375 designated .home.arpa as the standard TLD for home networks. It makes sense because, according to this article:
Routers and Domain Name System (DNS) servers know, [in theory], not to forward ARPA requests they don’t understand onto the public internet.
OpenWrt defaults to the non-standard .lan. Any reason for this?

1 Reply
14

[Assistant]
I switched my home network to home.arpa at some point in the past year after reading the same article and RFC. I had no reason to actually do it, but no reason not to, either.
No one in my family noticed, complained, or complimented me.
Looks like it's been .lan since the beginning.
github.com/openwrt/openwrt
moving to dnsmasq as dhcp server
committed
Jul 6, 2004
embeem
+23 -15
SVN-Revision: 75

7

keith24:
OpenWrt defaults to the non-standard .lan. Any reason for this?
I think it's just because this was done looooong ago.
But yes, I would like to see the change to home.arpa too. Doing the same since 4 years, too.
IIRC this domain was also mentioned in the homenet proposals and RFCs.

2 Replies

_bernd:
I would like to see the change to home.arpa too.
Submit a PR?

2 Replies
1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Simplified wifi repeater gui setup

Is it possible to look into simplified alternative LuCI configuration that auto-configures repeater mode by scanning for an AP, setting up client/AP interfaces, and enabling WDS if selected, with minimal user input,checking each of the currently error prone intermediate steps like setting up relayd and verifying the situation.
Even with latest openwrt the slightest mistake takes hours of troubleshooting allegedly freshtomato and gargoyle would have it, could anyone look into it perhaps ?

1

[Assistant]
If you're able to contribute the code, that would go a long way.
To give some context for the challenges:
there are lots of "repeater" type configs, starting with the distinction between ethernet connected bridged devices and wireless backhaul.
With wireless backhaul, if the upstream device is not OpenWrt, it is likely that relayd will be required.
If it is OpenWrt, WDS or 802.11s (mesh) can be used, but selecting the appropriate method is contextual within the specific environment and usage scenarios.
With both WDS and 802.11s, there are things on both the upstream AP and the downstream devices, so now you have to communicate and coordinate changes between the two devices.
With that in mind, it's not a one-size-fits all type configuration and so creating a GUI is not easy. It would be great, though.... so if you have the ability to contribute, this would be worthwhile project.

1

I hope the official openwrt maintainers might consider some sort of alternative gui guided procedure somehow, I haven't got a firm grasp of what it would entail, because I'm confused even by the different wiki possibilities client, wds client etc.

1

gfanini:
I haven't got a firm grasp of what it would entail, because I'm confused even by the different wiki possibilities client, wds client etc.
I guess that's my point.
The reason that the device manufacturers (with their own firmware ecosystems) can do this successfully is that they don't need to make any assumptions about the rest of the system, and they can write special code to make it work automagically.
Because OpenWrt supports hundreds of different devices and cannot assume that the rest of a user's network (specifically in this case, the upstream wifi AP) is actually an OpenWrt system, it would need to present all the possible options to the user. Maybe it could be guided in some way, but there's nuance in each situation that wouldn't be captured so it might be even more confusing to go through a 'wizard flow' that would need to ask lots of questions and gather a lot of info before it could do anything.
The other thing to consider is that for relayd and 802.11s/mesh, there are packages to install. Those take up valuable space and are not universally needed, so they wouldn't be included in the default firmware images. As a result, an automatic system would need to figure out how to get itself online, download and install packages, and then configure them appropriately -- this would be pretty tricky to design as an automatic/guided system where the existing network parameters are unknown.
Hopefully my bullet points above are helpful and provide the appropriate guidance about which path you might want to take. But, with that in mind, that is why the forum is here -- we can help you select the appropriate approach, point you to the documentation, and then guide you through it if you get stuck.

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: An idea for new OpenWRT development | Faking ICMP latency when OpenWRT act as VPN Client

Hi all
I would like to share my great idea with OpenWRT community.
many of OpenWRT users are using OpenWRT because of the capability to make their home router as VPN client and route all traffic through a VPN Server (either commercial VPN Server or their own built VPN Server).
now , clients in their home network are using the router to get access to the Internet. there are some app , for example HULU streaming services that it's doing all it can to determine if it is running behind a VPN connection or Proxy.
I was thinking how actually HULU app can determine if it's running behind a VPN or NOT. one option is with IP reputation database. but lets assume that the IP Address is not FLAGED as VPN Server base. still HULU app can perform additional checkups to determine if it is running behind a VPN. How ? to do simple PING request to destination in the same GEO zone that the VPN client pretended to be. if the latency is between the acceptable range then this eliminate the thinking that the Client sits behind VPN , but if the latency is outside the acceptable range then there is great suspicious that the Client sits behind a VPN connection.
now , how actually the OpenWRT community can help in this ?
I will tell you how.
OpenWRT should have a software package that provide fake ICMP results for specific clients.
Assuming that you have a streamer , Like just for the sake of the example , lets say Amazon FireTV Stick. which itis being connected through WiFi to OpenWRT router. once you installed that software Package which can help you in faking ICMP result. you can choose which clients will have fake ICMP results. that package should provide you the capability to choose which Clients in the network will get fake ICMP results. besides that , the OpenWRT will catch those ICMP communications and will fake the result. so for example:
Amazon FireTV HDMI Stick , get an IP address in the internal network like: 192.168.1.140
OpenWRT has IP address such as: 192.168.1.1
OpenWRT will do deep packet inspections for specific clients you choose. you choose in our example 192.168.1.140
once OpenWRT catch a packet which contains ICMP request to a destination. then OpenWRT will fake the response with predefined delay.
good idea ? what do you think ? can the OpenWRT community would like to develop such thing ? share your ideas in this thread.

2 Replies

[Assistant]
Leaving the potential contractual issues aside, the first step would be for you to confirm that the client actually follows your scheme and employs ICMP for that purpose.

1 Reply
2

That idea is full of misconceptions.
no one can send icmp to your private lan.
and artificial latency will make you look even more vpn.

1 Reply
2

onemancrew:
many of OpenWRT users are using OpenWRT because of the capability to make their home router as VPN client and route all traffic through a VPN Server (either commercial VPN Server or their own built VPN Server)
If the homerouter is the vpn server than the clients are usually smartphones, smartpads, laptops etc somewhere out in the world calling home to either get data from home or surfing through the home ISP connection.
Why would that setup want fake and slower ICMP results?


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: TL-WR1043ND snapshot images - High download numbers - Spanish users needed

The issue
Quite unusual issue where we need the help of spanish residents:
Since 30.09.2018 we see abnormally high download numbers for the TL-WR1043ND snapshot factory image in the download stats, which create a tremendous amount of traffic.
See also https://downloads.openwrt.org/stats/#countries
Analysis
Analysis of the download servers logfiles revealed that
99,7% of the 1043nd snapshot downloads originate from Spain
75% Wget; 25% uclient-fetch
both without version as "usual" user agents
sometimes 100% Wget OR uclient-fetch from one IP, sometimes both at the same time at other IPs
approx. 20k different IPs, spread over hundreds of network ranges
downloads are rarely completed, instead are cut off at varying sizes; HTTP status however is almost always (99%+) 200, instead of 206 as one would expect
downloads originate mainly from 4 different network names (see graphic below)
downloads show a significant timely pattern in seconds, minutes, and hours that the downloads happen
Tip for the pictures: to see them in real (big) size -> right click on the picture -> "Show picture"
Download size vs. netname
Timely pattern: Seconds
Graphing download size (in bytes) vs. seconds shows the following:
=> two strong peaks around 21..24sec and 32..35sec.
Timely pattern: Minutes
The same for minutes:
=> Every 10 minutes (at 01 / 11 / 21 / 31 / 41 / 51) download size increases by factor of 2.5 for a time of 6minutes
Timely pattern: Minutes + seconds
green = seconds
blue = minutes
=> The "seconds" pattern (21/32sec, see above) and the 10min pattern are clearly visible.
Timely pattern: Hours + seconds
It is getting more interesting by the minute... or should I say by the second?
Remarkable things in this graphic:
red: spikes in 3h intervall; seconds peak at 32sec
blue: significantly different seconds pattern at 02h / 06 / 12 / 20
blue: similar pattern at 02h / 12 / 20; two peaks at 21 + 47 sec
blue: different pattern at 06h (almost equally spread over the seconds)
Preliminary conclusion
Due to the restriction to Spain, the timely pattern and amount of download requests observed we come to the conclusion that this traffic can not originate from single users trying to download the 1043nd snapshot image for flashing their device, but from some bot / script that either does performance testing (user's internet line / OpenWrt download server transfer speed), or checking if there is a new snapshot build available.
Whatever the reason for the described download behaviour may be, we feel that using the OpenWrt ressources (server time + download bandwidth) to this extent for any other purpose than flashing the downloaded image is not appropriate.
We would like to find out the reason for the shown download behaviour, in order to finally lessen the impact on the OpenWrt resources to a normal range (compare stats linked above).
This is when you as a spanish resident enter the game: We need your help in finding the cause of the high download numbers.
Request to spanish OpenWrt forum users
Can you think of any reason for the download behaviour shown above?
Is there a spanish forum, website, blog, ... which could have triggered this by publishing
a speedtest-script
check-for-new-snapshot script
or ...something completely different?
Are you running OpenWrt on one or more devices, and are you knowingly / unknowingly taking part in these periodical downloads?
If you are running a continuous speedtest / check for snapshot updates / something else on your OpenWrt device, please check if there are any irregularities since today (404 errors / no statistics / ...)
Thanks for your time and your feedback!
Sidenote: If anybody knows Clifford Stoll: I'm feeling a bit like him now, searching 75ct

1 Reply
1

[Assistant]
As a workaround (if more fine grained blocking isn't successful):
The tl-wr1043ndv1 is well supported by ath79 by now, so it would be easy to totally remove image generation for it in the ar71xx target.

1

Spanish user reporting for duty!
I searched Google using keywords in Spanish, but could not find anything relevant. I am currently active in a Spanish forum related to OpenWrt, and have posted this question and a link to this post there. I am searching for other Spanish forums where this could have been discussed, and will post there, too.
Let's hope someone can shed a bit of light about this.

3

Have you tried to check if the IPs mostly originate from a specific area in Spain? The netnames doesn't seem to be proportional to the size of the ISPs in Spain at all, but maybe they are proportional to the size of the providers in a specific area.

2 Replies
1