Re: Guidance on creating man pages for procd utilities
On 8/18/21 9:24 PM, Lucas Ramage wrote: Greetings, I would like to create man pages for uxc and some of the other utilities in the procd repository. Searching through some of the commits in the openwrt/packages repository shows that man pages are intensionally disabled from being built, but I still think they are helpful to have. Perhaps there could be -doc packages like in other distributions? Please advise, Doxygen would be nice. If used correctly, it can help one wrap their head around calls, structures, and requirements. The pretty HTML could be published with Github pages, or similar custom method. Yet being realistic, meaningful comments in the code would be nice. (hint) - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
> > On Tue, Jul 6, 2021, 1:06 PM Henrique de Moraes Holschuh > mailto:henri...@nic.br>> wrote: > > On 06/07/2021 12:05, Nishant Sharma wrote: > > On 06/07/21 7:56 pm, Henrique de Moraes Holschuh wrote: > >> So, to safely and responsibly enable wireless by default in a > device (or > >> firmware) you're delivering to a third-party, you need that > "per-unit > >> unique wireless password" per device thing most vendors are doing. > >> > >> [2] not really: openwrt sysugrade *does not help* in that there > is no > >> way to add variable information to an already *finished* image > file, to > >> be used on first-boot only, and which would *survive a factory > reset*. > >> > > > > How about a first-boot script that enables the Wi-Fi if it is > disabled > > and then sets the password (if not already set) using the first MAC > > address it finds on the device? > > MACs are not a secret. It is absolutely trivial to know them: they're > in just about every WiFi (and ethernet) frame. Same goes for anything > that is derived *just* from the MAC address. And anyone that is going > to automatically scan/exploit for that, will also use MAC-1, MAC+1, and > other common variants. > > What would work is to reuse the vendor-provided password that is > already > in the label and somewhere in FLASH, if you could always know where it > is in FLASH (you don't). And some models don't have it. > > One also don't know the unit's MAC address beforehand, so any scheme > that depends on that doesn't work (because you'd need that MAC address > to print the label or generate the PDF). In fact, this precludes the > "generate secret at the device at 1st boot" too. > > You could ask the user, but that isn't safe either: if she gets it > wrong > (or openwrt isn't correct about what MAC is in the printed label of > that > exact product version) you now have a device she can't access because > the passwords won't match and it would require an ethernet cable to > bypass and reset. Some models are more obvious about device unique default password storage than others. So like on my other reply if it is obvious then use it and turn on wifi. For those with wifi-on-first support, make it a check box in the hardware support table. Then small business using openwrt know what options might meet their deployment needs. - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
On 7/6/21 8:36 AM, Alberto Bursi wrote: On 06/07/21 09:12, Enrico Mioso wrote: On Mon, 5 Jul 2021, Paul Spooren wrote: Date: Tue, 6 Jul 2021 09:06:14 From: Paul Spooren To: Enrico Mioso , openwrt-devel@lists.openwrt.org Subject: Re: Enabling Wi-Fi on First boot On 7/5/21 8:45 PM, Enrico Mioso wrote: Hello all!! I would like to know your opinion on a topic I know has already been discussed: enabling Wi-Fi on first boot. I would very very much like to see this feature present in OpenWRt: because I find myself in a scenario where plugging an Ethernet cable after a fresh sysupgrade without keeping settings (due a a major upgrade or just to "start clean") could be impractical. I think you can add uci-default scripts to enable it or do you want a config option during build time? Hello Paul!! Well, I tought about uci-defaults, but I tough it won't be so easy to implement due to the fact Wi-Fi is probed asynchronously, and on some devices i saw it takes a little bit (Netgear R7800). I would have liked to have something already implemented in OpenWRt, so it could be looked at by more people and have much higher chances of working on all devices. Enrico The only thing that must be done by a uci-defaults script is to set the wifi as enabled in the uci config. Afaik all devices ship with a default config for an open wifi network called "OpenWrt" for all their radios, but have option disabled '1' in both the device and wifi-iface text blocks, which disables the wifi. The uci-defaults script should just delete that line recursively along the whole /etc/config/wifi config file and it can be done with sed. Since uci-defaults scripts are run before everything else, the device should just have all wifi enabled on first boot no matter what wifi hardware it actually uses. You can easily turn this in a package (that only installs a uci-defaults script), just look at any other package that sets a uci-default script like this https://github.com/openwrt/packages/blob/master/net/bcp38/Makefile and use it as a template for your own. Since there are strong opinions are about keeping wifi off by default (last time I checked even devices that have no other network interfaces can't have a wifi enabled on first boot, forcing users to do a first config through the debug UART console or integrate a custom wifi config file in a custom image) I do not think many core developers will want to merge this package in core repository, but you can try. I think there should not be much problems if you send your package to community packages repository. https://github.com/openwrt/packages -Alberto Most modern devices have default SSID and password in ROM somewhere that stock OpenWrt doesn't touch. It is written on the radio regulatory compliance sticker. That would seem convenient for the user OEM or OpenWrt. IF OpenWrt knows where to find it, and IF it is found on on first boot, then enable WiFi at first boot. This is especially important on WiFi only devices and as more "slim format" user devices (tablets, phones, ...) are exclusive in homes and have no ethernet. A system reflash or reset with stock OpenWrt is not an option for these users. For example, it should not be trouble to find it on TL 3600/4300/Archer and WRT 1900/3200. - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Brokenness of the OpenWrt "packages" repo
On 4/26/21 3:58 PM, Alberto Bursi wrote: On 26/04/21 16:01, Daniel Golle wrote: On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote: ... I know you won't like this. But in the end, I guess D-Bus, glib2 and in the end all of MM dependencies will have to be incorporated in the core. A stac, of big big software, I know. But supporting 4G/5G in the end will required that. ModemManager is not the only way to use 4G/5G modems. You can use umbim or uqmi for most tasks. In my experience their ability to handle device-specific bugs or "perks" is limited, unless your modem is 100% perfect and never crashes ever and can actually handle the autoreconnect on its own, you will end up in situations where you need to just set up a script that pings Google and reboots the router if network fails. They also don's support a lot of new LTE features like band lock, band aggregation and more, they are way too simple. I have bought a consumer modem/router that is like 3 times faster while using the same type of CAT6 modem due to band aggregation and the reconnect sequence if the connection drops is very fast because I have set the only 2 LTE bands it can use. MM is so much better than that. But my main issue with MM is that both maintainers (package and upstream MM maintainers) have not found a way to integrate it well enough with OpenWrt's internals so that when the modem disconnects there is nothing that notices this issue and nothing that reacts to it. So I had to cobble together a script to do this missing link, but it's far from a decent solution. (see the issue thread I opened about this) Hence why I eventually bought an actual self-contained modem with web interface and all, it's just so much better speed and is less painful to use. -Alberto Both projects are straight forward, well documented code, easy to extend in case you miss anything. Depending on half of the Freedesktop universe in order to initialize a network interface or receive an SMS in a very complicated way doesn't feel justified to me. On Mon, 26 Apr 2021, Bjørn Mork wrote: Date: Mon, 26 Apr 2021 07:51:51 From: Bjørn Mork To: Etienne Champetier Cc: Rosen Penev , OpenWrt Development List Subject: Re: Brokenness of the OpenWrt "packages" repo Etienne Champetier writes: Are you trying at the same time to complain about not run-tested updates and possibly having packages not up to date ? No. The package was fine before the version was changed. In fact, it was in much better shape before it was changed to a development version by the very same non-maintainer. If you don't care enough to even install the package, then please don't touch the package. I would personally mark it as broken or remove it instead of making it work again, but it means removing some other packages. I'd be all for that, if you apply that rule to all the unmaintained packages in the repo. It's a much better solution than having the repo full of arbitrary untested changes to unmaintained packages. Wrt dbus I'm pretty sure it would provoke an adoption. There are multiple packages depending on it, and as the immediate reports tell you: This particualr umaintained package is in active use. Bjørn I feel this with a lighter tone, but I philosophically agree with Bjorn. Here is an example of enforcement concerns. I am an active maintainer. I have a day job and all, but I do get to at least commenting on PR once a week. Here committer and merger where separate individuals. The maintainer wasn't contacted. Neither participant is even a user of Unbound, self-stated in PR, or tested the work. I realize the change was trivial, and that is not my point. An automated test-hook could have checked if the maintainer commented or the maintainer was AWOL before marking the PR ready. Trivial or complex, maintainers need to be in the loop or we lose continuity in quality and we discourage their "feeling of ownership" when we bypass them. SEE: https://github.com/openwrt/packages/pull/15511 - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Apart from it being hard to proof that people wanting to access the configuration (and status!) interface of a device running OpenWrt (or something based on it) are all prosumers or developers, for future users this assumption even has the taste of a self fullfilling prophecy. To me, the situation with self-signed certificates and the resulting warnings is a bug, not a feature, and I do appreciate the debate on what we could do about it. The suggested approach is possibly the best we can do in a world where reasonable connection security can only be achieved with the help of external certification authorities (and browser/consumer-OS vendors making everyone 'trust' them, by itself also a major bug which we are trying to work around here...). It's a bit a matter of taste if the OpenWrt CA should associate the SSH host key (which then requires SSH on the router to be accessible for the CA to verify it) or if it wouldn't be easier to just use a hash of the to-be-signed public key. The latter option has the disadvantage that user then has no means to verify the identity using the SSH host key (which had to be accepted previously, a warning not as scary looking but technically quite the same as accepting a self-signed certificate in a browser). It has the advantage that it's even easier to do as no verification of any kind would have to be done while still providing a great improvement in terms of security by asserting a mapping between hostname and TLS key used for HTTPS. However, then we still only got stuff like https://[b32(hash(pubkey))].devices.openwrt.org working, and of course http://192.168.1.1 and http://openwrt.lan may redirect to that, but httpS://192.168.1.1 would still give a warning about the certificate not being issued for that hostname. Though it would also create some non-neglectable administrational overhead if actually deployed for the .openwrt.org domain, even just using a designated OpenWrt toy root CA certificate people can install manually in their browsers, downloadable from httpS://OpenWrt.org, is already much better than training users to accept invalid certificates (as long as they still can). And it provides a good example of how vendors downstream could do it right as well (and that may ultimately converge into a new industry standard for which there is obviously a desperate need. and that could then result in lobbying for a way to operate subordinate CA for such type of purpose). A truely good solution to the actual problem imho doesn't exist (because https://youbroketheinternet.org/ ) How about a completely different approach? Install a custom certificate on the developer or prosumer machine. It is normal to have an out of chain "business intranet" certificate to install. Most OS and browsers have a means to support this. OpenWrt would just need tools, helper scripts, or instructions for three cases: (1) For those using ready built images, each release (19.7.3 vs 19.7.4) has a different certificate the user can install. They download the image and certificate. This will get them the default "OpenWrt.lan" domain. (2) For those saving configurations, their router ID or domain can have its own certificate they install. LuCI can help build this for their first run through configuration before they save. (3) For those building their own images, they locally install a certificate of their own construction. They can option to find and include that certificate as part of menuconfig or just stuff in /file/etc/... Anyway a start of an idea. - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 'tr' character class support?
On 7/10/20 8:15 PM, Jordan Geoghegan wrote:
On 2020-07-10 16:59, Rosen Penev wrote:
On Fri, Jul 10, 2020 at 4:17 PM Jordan Geoghegan
wrote:
On 2020-07-10 14:54, Rosen Penev wrote:
On Fri, Jul 10, 2020 at 2:29 PM Jordan Geoghegan
wrote:
On 2020-07-10 14:15, Magnus Kroken wrote:
Hi Jordan
On 10.07.2020 22:45, Jordan Geoghegan wrote:
Hey folks,
Does the 'tr' utility support character classes in OpenWRT? I was
playing around with an OpenWRT x86_64 VM and I noticed that 'tr'
doesn't seem to support character classes.
The command " echo HELLO | tr '[:upper:]' '[:lower:]' " does not
convert to the text to lowercase as it should (and as required by
POSIX).
This would be expected behavior. OpenWrt disables tr character
classes
in BusyBox by default, see [1]:
config BUSYBOX_DEFAULT_FEATURE_TR_CLASSES
bool
default n
config BUSYBOX_DEFAULT_FEATURE_TR_EQUIV
bool
default n
I don't know what the size cost in the BusyBox binary is, but that
will likely be the deciding factor for such a change.
1:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/utils/busybox/Config-defaults.in
Regards,
Magnus Kroken
Hi Magnus,
Thanks for confirming that so quickly.
I obviously understand that space saving is essential to OpenWRT, but
POSIX does require[1] that 'tr' support character classes:
awk '{print toupper($0)}' is an alternative.
Yes, but this means that any script expecting tr to work correctly could
explode, as tr silently ignores the character class and treats all the
characters literally.
git grep upper | grep tr\ | wc -l
3
In the packages feed. All those results are things that run on the
host, not on OpenWrt.
tr a-z A-Z works as an alternative and is used in many places.
tr a-z A-Z is bad practice as it can behave unexpectedly in different
locales; I've also heard tales of folks with Turkish locales having
issues with '0-9' for example.
Is a couple kb of space worth such a loss in portability (not to mention
deviating heavily from POSIX)?
:class:
Represents all characters belonging to the defined
character class, as defined by the current setting of the LC_CTYPE
locale cate-
gory. The following character class names shall be
accepted when specified in string1:
alnum blank digit lower punct upper
alpha cntrl graph print space xdigit
1: https://www.unix.com/man-page/posix/1posix/tr/
Unless there is an overwhelming size cost, basic POSIX binaries should
be provided "POSIX'ly correct" by default. Applying experimental theory,
a discipline's standard is the null hypothesis (H0) which is the default
decision. A deviation to the standard and especially _shorting_ the
standard is the alternate hypothesis (H1) and requires good data with
separation to accept. (standards often permit well formulated extensions
to them.)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fix TX power handling
On 4/29/19 8:24 PM, Matthias Schiffer wrote: This is just the factor of 1/2/3/4 (approximated) in dB: 10^0.0 = 1 10^0.3 ≈ 2 10^0.5 ≈ 3 10^0.6 ≈ 4 I've seen these numbers being used in WLAN drivers to account for the antenna array gain, so at least this part of the TX power computation might already be working as expected. Kind Regards, Matthias On 4/30/19 12:39 AM, Vincent Wiemann wrote: Hi Matthias, thank you for the hint. That's funny, because someone from the German Federal Network Agency said that when radios have multiple antennas, the aggregated EIRP of the antenna array must not exceed the EIRP limits of a single antenna, but I've assumed this is done in hardware and not in software. Can you hint me to the source for this lookup table? Regards, Vincent Wiemann On 29.04.2019 08:50, Matthias May wrote: On 25/04/2019 17:54, Vincent Wiemann wrote: First EIRP is by definition ERP + antenna gain - cable loss. Hi Small detail: Don't forget the antenna array gain. So EIRP as: Antenna Port Power + Antenna Gain + Antenna Array Gain - Cable Loss The Array Gain as a simple lookup table: 1 Antenna: 0 2 Antennas: 3 3 Antennas: 5 4 Antennas: 6 BR Matthias A concern could be a simple count of antennas may over estimate EIRP and reduce enabled power below what is allowed. A cheap example of simple diversity, only one antenna is used for TX based on which of the other antennas RX the best connection to a client (gain=0). Even with beam forming, a few antennas may be included in TX phased array and others RX monitors. - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Or that is $0.023647, anyway. :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On 4/9/19 7:53 AM, Vincent Wiemann wrote: Hi Bjørn, routers are critical infrastructure. We should try to achieve the best we can. One of the reasons for the Lede split was that problems were procrastinated and accumulated over the release timeline. That's the reason why we should release less often, but with a higher quality. If problems delay a release that is a sign of taking responsibility. Some time ago a friend of mine told me that they have a problem with tickets that nobody wants to take care of. I told him when those tickets appear he should automatically assign them to all people with highest priority after a due date even if it is a minor issue. Productivity has increased rapidly since then. If a device is not supported in a specific release, that might give someone the stimulus to sit down and get this device working again. E.g. many devices have a partition layout on which a bigger kernel does not fit. It is possible to change the partition layout in most cases requiring a modification of the U-Boot boot environment variable. So hard it sounds unfortunately someone needs to be urged to do it. It's the same with porting ar71xx to ath79... When we stop generating ar71xx images some device owners wonder why there is no new release for it. They become aware that they need to sort of add support for this device as if it was a new device support and they might do it. Urging is a bad word, but we need to motivate people to do changes which are not of the fun kind or we might end up in a mess again. Regards, Vincent Wiemann On 09.04.2019 11:02, Bjørn Mork wrote: Jo-Philipp Wich writes: Is there any kind of "official" roadmap/checklist available what "needs" to be done? not that I am aware of, but from the top of my head: - make sure all targets are ported properly to 4.14 - disable all devices which cannot cannot handle the increased kernel size anymore - drop all targets which are not ported to 4.14 - fix important open issues in the tracker Apologies if this is out of line... I just fealt the urge to post my personal opinion, FWIW. It seems to me that you are setting way too high standards for yourselves. From my point of view, the OpenWrt master branch is almost always in a releasable state. The OpenWrt development and review process ensures an extremely high quality, even for targets which are considered WiP. There are very few days over the last 6 months where you could not have decided to cut a release branch, and got away with it. It's something to be proud of! But you need to tell the rest of the world that you are proud of this by making releases. You should accept that the targets which are ported properly to 4.14 defines "all targets" for the next release. It's not the other way round. Any remaining targets which can be expected to be ported to 4.14 or later, if any, can and should be deferred for a later release. Note that accepting this means that there could be a "next release" in 2019 too... You should also accept that there will be unfixed important open issues at all times. You can't fix them all. To make a release, these issues will either have to be - ignored for that release, - demoted to less important. or - removed by removing the feature/target/whatever is affected by the issue from the release Look at the Debian "release critical" bug handling. It's not really about fixing all the RC bugs, but dealing with them. I realize that actually making a release is real work too, and that this has to take some time after making the initial cut. But delaying the cut for the master branch to get in an even "more ready" state is not really helping... Just my .021 € (considering inflation) Bjørn Hi Bjorn, I agree with you on this one. New OpenWrt adopted a different working model from LEDE. That is staging trees and more careful testing before actual master commits. Long ago are the days when someone thought they were special, commit without review, and just blow up the nightly builds. OpenWrt should release regularly and it should be an editing (cutting) event. Target not on envisioned kernel, cut. Package not core and sketchy, cut. What's left is pretty good. With a variety of targets and volunteer support team bugs will happen. You can test to high confidence, but in such situations nothing is 100%. Instead, you just need to be prepared to deal with them in a timely matter. Just my $0.018649 exchanged at 20190410 04:00 Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] EU feedback on "Upload of software on radio equipment"
On 3/4/19 6:35 PM, Hauke Mehrtens wrote: Hi, The European commission asked for feedback on the Radio Equipment Directive (RED) regarding the restrictions on "Upload of software on radio equipment" I posted here a comment in the name of the OpenWrt project: https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2018-6621038/feedback/F240894_en?p_id=380919 The deadline for comments was 4. March. Thank you for the help and also the others who posted feedback to the European commission. More details can be found here: https://fsfe.org/activities/radiodirective/ Hauke Historical Reference US FCC attempted a similar thing a few years ago and it received some backlash. They chose to revise the interpretation instructions for the rule. Although a regulation (FCC rule) is flexible and less worrisome. Bad legislation can hang around for a long time. FCC NPRM: https://docs.fcc.gov/public/attachments/FCC-15-92A1.pdf FCC Informal News: https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates FCC Revised Interpretation: https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g%3D%3D=594280%20D02%20U-NII%20Device%20Security%20v01r03_number=39498 Credible Response: https://ecfsapi.fcc.gov/file/60001333550.pdf ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] odhcpd: add network dependent start trigger
On 2/27/19 7:38 AM, Hans Dedecker wrote: Hi, On Mon, Feb 25, 2019 at 8:46 AM Hans Dedecker wrote: Hi, On Sun, Feb 24, 2019 at 7:06 AM Eric Luehrsen wrote: Recent (20190207) changes to odhcpd makee it dependent on OpenWrt logical interfaces. Boot time race conditions may make odhcpd binding Even before the most recent changes odhcpd was dependent on OpenWRT logical interfaces nothing has changed in that sense a challenge. Intermittent or inconsistent problems can occur with DHCP requests until odhcpd is restarted. Change start up scripts to use Can you elaborate a bit more on what issues you're observing and provide odhcpd tracing (loglevel 7) when you observe issues ? The issue you probably have observed is fixed in https://git.openwrt.org/?p=project/odhcpd.git;a=commit;h=16c5b6c9bcb71bb67a6ab15bb458bf9ab5a8fe7e Hans procd interface triggers such as dnsmasq and others have already. This does not really make sense to me as odhcpd is subscribed to ubus network event messages triggering config reload logic in case the network state of an interface changes Hans Sorry I haven't much time this week to look at it more, but yes, that looks to be directly related with the symptoms. Thanks Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] odhcpd: add network dependent start trigger
Recent (20190207) changes to odhcpd makee it dependent on OpenWrt
logical interfaces. Boot time race conditions may make odhcpd binding
a challenge. Intermittent or inconsistent problems can occur with DHCP
requests until odhcpd is restarted. Change start up scripts to use
procd interface triggers such as dnsmasq and others have already.
Signed-off-by: Eric Luehrsen
---
.../network/services/odhcpd/files/odhcpd.init | 20 +--
1 file changed, 18 insertions(+), 2 deletions(-)
--- a/package/network/services/odhcpd/files/odhcpd.init
+++ b/package/network/services/odhcpd/files/odhcpd.init
@@ -1,10 +1,20 @@
#!/bin/sh /etc/rc.common
-START=35
+START=19
STOP=85
USE_PROCD=1
+boot() {
+ ODHCPD_BOOT=1
+ start "$@"
+}
+
start_service() {
+ if [ -n "$ODHCPD_BOOT" ] ; then
+ # odhcpd needs to wait for OpenWrt logical interfaces
+ return 0
+ fi
+
procd_open_instance
procd_set_param command /usr/sbin/odhcpd
procd_set_param respawn
@@ -17,6 +27,12 @@ reload_service() {
service_triggers()
{
- procd_add_reload_trigger "dhcp"
+ if [ -n "$ODHCPD_BOOT" ] ; then
+ # one time trigger at boot to wait for logical interface setup
+ procd_add_raw_trigger "interface.*.up" 3000 /etc/init.d/odhcpd
restart
+ else
+ # reload odhcpd also for network reconfiguration
+ procd_add_reload_trigger "dhcp" "network"
+ fi
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.01 plans
On 09/27/2018 04:22 PM, Hauke Mehrtens wrote: On 09/26/2018 09:38 AM, Koen Vandeputte wrote: On 2018-09-23 00:42, Hauke Mehrtens wrote: Hi, We talked about plans for the next OpenWrt releases in this mail thread: http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html This mail is more or less a summary of the conclusions, this is still open for change especially the dates as this depends on people having time to do the work. The next release, lets call it OpenWrt 19.01, should happen in January 2019, we would branch off from master in December 2018. This is the current plan, but based on past experience it could also happen later. OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to update the targets to kernel 4.14, support for kernel 4.19 will probably be added to OpenWrt master soon, but we will not select it as the default kernel for any target till OpenWrt 19.01 is branched off, to get more testing on 4.14. The release after 19.01, which should happen in late summer 2019, should then use kernel 4.19 only. For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl already got some upgrades after the 18.06 release and could get some more updates. We are currently working on updating the wireless drivers and getting them closer to upstream. The wireless driver in OpenWrt 19.01 will be taken from kernel 4.19 or later and we want to update them more frequently in master. Otherwise we will have the normal changes in all places like with every release. LEDE 17.01 will get security updates and occasional bug fixes till OpenWrt 19.01 was released, but we encourage everyone to upgrade to 18.06 to get full security support already now, as especially some of the packages are not well maintained any more. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Hi Hauke, Hi All, Some targets are still on (EOL) kernel 3.18 today. This kernel also still exists by the grace of Greg K-H but could be dropped any moment. I've bumped it a few times (untested) just for the sake of security updates. But afaict, nobody attempted/requested to update these to a newer kernel version. These targets were also dropped in 18.06 branch. Maybe we should also consider dropping support for these targets in master? adm5120 xburst mcs814x au1000 ppc40x adm8668 ppc44x I vote for removing them if on one wants to take care of these targets. If something breaks kernel < 4.9 I anyway do not care any more. Hauke Considering that OpenWrt is volunteer spare time and hobby support, it is probably prudent to aggressively drop old and less popular targets. Considering 802.11ax is around the corner and (ac) is well established, it won't be hard to find for example ath79 compatible devices in (ac) or (n) as either new-overstock or used. They may not be able to push lots of bandwidth, but if you have <~100Mbps internet they don't need to. If you have >~200Mbps internet for example with DOCSIS3.1 provider, then you probably need a newer dual-core device to take advantage of it. Bottom line is it probably won't hurt to drop many targets, because small budget users will still have plenty to chose from. Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus
On 08/13/2018 01:29 AM, Daniel F. Dickinson wrote: Posting on list as I think the discussion should include as folks as possible in the discussion. https://github.com/openwrt/packages/issues/6745 Especially when getting started with OpenWrt finding things in menuconfig is complicated by the second level menus that are sometimes used and sometimes not, even when the category exists. Further not everything fits neatly in a category. Finally when, years ago, I tried to improve the situation the above resulted in titles that I think make it harder to find things (in retrospect). Therefore I would like to do a mass removal of the second-level menus, leaving only the broad top-level categories like 'net', and 'utlitiies'. Thoughts? I see some pragmatic challenges. Without some sorting, a category such as "Network" on a project for open source routers becomes a mess (take a second; let it soak in). This can be compensated in a few ways, but they are all a lot of work, and some could fetch unwanted emotional feedback. For one example, more aggressive use of "packages-abandoned" is probably needed even outside this topics consideration, but how do you qualify user interest or proactive maintenance? For another example, remove the catch-all "Network" and create 4-5 other named top level menus, but while a few categories may be obvious and well stocked, some other categories may not be so clear. Good Luck Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Build error in latest master
On 08/09/2018 10:14 PM, Eric Luehrsen wrote: On 08/09/2018 12:40 PM, Koen Vandeputte wrote: During compiling/testing the new kernel bumps, I'm getting this on 7 different builds: make[3]: Entering directory '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/package/base-files' rm -f /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/build_dir/target-arm_mpcore+vfp_musl_eabi/linux-cns3xxx/base-files/.configured_* rm -f /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/target-arm_mpcore+vfp_musl_eabi/stamp/.base-files_installed [ -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build -a -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.pub ] || /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/host/bin/usign -G -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build -p /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.pub -c "Local build key" [ -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.ucert ] || /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/host/bin/ucert -I -c /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.ucert -p /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.pub -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/host/bin/ucert: error while loading shared libraries: libjson-c.so.2: cannot open shared object file: No such file or directory Makefile:204: recipe for target '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/build_dir/target-arm_mpcore+vfp_musl_eabi/linux-cns3xxx/base-files/.configured_5e642ff7c79a8d8f76f1e8e04a42a0c2_8e081b74cf069e1e6800a5bbcbb282f0' failed make[3]: *** [/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/build_dir/target-arm_mpcore+vfp_musl_eabi/linux-cns3xxx/base-files/.configured_5e642ff7c79a8d8f76f1e8e04a42a0c2_8e081b74cf069e1e6800a5bbcbb282f0] Error 127 make[3]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/package/base-files' time: package/base-files/compile#0.06#0.01#0.17 package/Makefile:107: recipe for target 'package/base-files/compile' failed make[2]: *** [package/base-files/compile] Error 2 make[2]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx' package/Makefile:103: recipe for target '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/target-arm_mpcore+vfp_musl_eabi/stamp/.package_compile' failed make[1]: *** [/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/target-arm_mpcore+vfp_musl_eabi/stamp/.package_compile] Error 2 make[1]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx' /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/include/toplevel.mk:216: recipe for target 'world' failed make: *** [world] Error 2 I will say "me too" as well as others affected. There is at least one flyspray report ( FS#1754 ). Chatter in the forums about this ( https://forum.openwrt.org/t/latest-openwrt-git-cant-build-08-08-2018-ucert-libjson-c-so/18598 ). - Eric Looks like a PR may attempt to fix this ( https://github.com/openwrt/openwrt/pull/1259 ). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Build error in latest master
On 08/09/2018 12:40 PM, Koen Vandeputte wrote: During compiling/testing the new kernel bumps, I'm getting this on 7 different builds: make[3]: Entering directory '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/package/base-files' rm -f /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/build_dir/target-arm_mpcore+vfp_musl_eabi/linux-cns3xxx/base-files/.configured_* rm -f /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/target-arm_mpcore+vfp_musl_eabi/stamp/.base-files_installed [ -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build -a -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.pub ] || /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/host/bin/usign -G -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build -p /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.pub -c "Local build key" [ -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.ucert ] || /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/host/bin/ucert -I -c /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.ucert -p /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build.pub -s /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/key-build /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/host/bin/ucert: error while loading shared libraries: libjson-c.so.2: cannot open shared object file: No such file or directory Makefile:204: recipe for target '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/build_dir/target-arm_mpcore+vfp_musl_eabi/linux-cns3xxx/base-files/.configured_5e642ff7c79a8d8f76f1e8e04a42a0c2_8e081b74cf069e1e6800a5bbcbb282f0' failed make[3]: *** [/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/build_dir/target-arm_mpcore+vfp_musl_eabi/linux-cns3xxx/base-files/.configured_5e642ff7c79a8d8f76f1e8e04a42a0c2_8e081b74cf069e1e6800a5bbcbb282f0] Error 127 make[3]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/package/base-files' time: package/base-files/compile#0.06#0.01#0.17 package/Makefile:107: recipe for target 'package/base-files/compile' failed make[2]: *** [package/base-files/compile] Error 2 make[2]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx' package/Makefile:103: recipe for target '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/target-arm_mpcore+vfp_musl_eabi/stamp/.package_compile' failed make[1]: *** [/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/staging_dir/target-arm_mpcore+vfp_musl_eabi/stamp/.package_compile] Error 2 make[1]: Leaving directory '/mnt/ramdisk/koen/firmware/builds/generic_cns3xxx' /mnt/ramdisk/koen/firmware/builds/generic_cns3xxx/include/toplevel.mk:216: recipe for target 'world' failed make: *** [world] Error 2 I will say "me too" as well as others affected. There is at least one flyspray report ( FS#1754 ). Chatter in the forums about this ( https://forum.openwrt.org/t/latest-openwrt-git-cant-build-08-08-2018-ucert-libjson-c-so/18598 ). - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] firewall3: make reject types selectable by user
On 07/04/2018 01:39 AM, Alin Năstac wrote:
On Tue, Jul 3, 2018 at 11:32 PM Philip Prindeville
wrote:
On Jul 3, 2018, at 3:22 PM, Alin Năstac wrote:
On Tue, Jul 3, 2018 at 6:39 PM Philip Prindeville
wrote:
Aren’t all inbound SYNs unsolicited by definition? Is there a danger of
reflection attacks?
Not all inbound SYNs are unsolicited. Take for instance active mode
FTP transfers where the client resides on the LAN . In this case the
FTP data connection is initiated from the WAN, but it is solicited by
the FTP control connection initiated from the LAN.
I don't think it matters that much what error code firewall returns
for these unsolicited inbound SYNs, but this RFC makes
adm-prohibitited code a must.
I would have thought that dropping them would be better, since it avoids
reflection attacks.
Whether you want to silently drop or reject unauthorized connection
attempts is a matter of local policy.
Besides, in order for a reflection attack against your LAN to succeed,
the source IP address of rejected packets must be part of the LAN
prefix. This can be easily prevented, either by enabling rpfilter or
just by adding a firewall rule when the LAN prefix is statically
allocated (the usual IPv4 case).
On Jul 2, 2018, at 9:29 AM, Alin Nastac wrote:
From: Alin Nastac
RFC 6092 recommends in section 3.3.1 that an IPv6 CPE must respond to
unsolicited inbound SYNs with an ICMPv6 Destination Unreachable error
code 1 (Communication with destination administratively prohibited).
Signed-off-by: Alin Nastac
---
defaults.c | 21 -
options.h | 2 ++
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/defaults.c b/defaults.c
index 11fbf0d..6565ca2 100644
--- a/defaults.c
+++ b/defaults.c
@@ -41,6 +41,8 @@ const struct fw3_option fw3_flag_opts[] = {
FW3_OPT("output", target, defaults, policy_output),
FW3_OPT("drop_invalid",bool, defaults, drop_invalid),
+FW3_OPT("tcp_reset_rejects", bool, defaults, tcp_reset_rejects),
+FW3_OPT("admin_prohib_rejects",bool, defaults, admin_prohib_rejects),
FW3_OPT("syn_flood", bool, defaults, syn_flood),
FW3_OPT("synflood_protect",bool, defaults, syn_flood),
@@ -113,6 +115,7 @@ fw3_load_defaults(struct fw3_state *state, struct
uci_package *p)
defs->syn_flood_rate.rate = 25;
defs->syn_flood_rate.burst = 50;
+defs->tcp_reset_rejects= true;
defs->tcp_syncookies = true;
defs->tcp_window_scaling = true;
defs->custom_chains= true;
@@ -276,14 +279,22 @@ fw3_print_default_head_rules(struct fw3_ipt_handle
*handle,
fw3_ipt_rule_append(r, "INPUT");
}
-r = fw3_ipt_rule_create(handle, , NULL, NULL, NULL, NULL);
-fw3_ipt_rule_target(r, "REJECT");
-fw3_ipt_rule_addarg(r, false, "--reject-with", "tcp-reset");
-fw3_ipt_rule_append(r, "reject");
+if (defs->tcp_reset_rejects)
+{
+r = fw3_ipt_rule_create(handle, , NULL, NULL, NULL, NULL);
+fw3_ipt_rule_target(r, "REJECT");
+fw3_ipt_rule_addarg(r, false, "--reject-with", "tcp-reset");
+fw3_ipt_rule_append(r, "reject");
+}
r = fw3_ipt_rule_new(handle);
fw3_ipt_rule_target(r, "REJECT");
-fw3_ipt_rule_addarg(r, false, "--reject-with", "port-unreach");
+fw3_ipt_rule_addarg(r, false, "--reject-with",
+defs->admin_prohib_rejects ?
+(handle->family == FW3_FAMILY_V6 ?
+"adm-prohibited" :
+"admin-prohib") :
+"port-unreach");
fw3_ipt_rule_append(r, "reject");
break;
diff --git a/options.h b/options.h
index 08fecf6..e3ba99c 100644
--- a/options.h
+++ b/options.h
@@ -276,6 +276,8 @@ struct fw3_defaults
enum fw3_flag policy_forward;
bool drop_invalid;
+bool tcp_reset_rejects;
+bool admin_prohib_rejects;
bool syn_flood;
struct fw3_limit syn_flood_rate;
--
2.7.4
This could spawn a side topic: for all firewall block types would it be
useful to have a two tier response that is easily configurable for each
rule or as a global default. That is _overt_ rejection on the first
counter per time, and then _covert_ drop after that for maybe 4x cool
off period. An honest address (DNS zone update) error would quickly
resolve itself while failing connections properly rather than longer
time outs. An attack flood would not generate amplified noise.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Customizing openssh password login, preprovisioned root passwords, etc.
On 06/22/2018 12:43 AM, Philip Prindeville wrote: Hi all, A while back I proposed some PR’s to allow baking in root passwords (configurable, so it wouldn’t have to be some lame constant password) as well as turning off password login for OpenSSH server. The maintainers of base-files and openssh didn’t like either. So I’m proposing a virtual package that scribbles on both as part of its /postinst script, which was suggested as a compromise. Please see: https://github.com/openwrt/packages/pull/6311 and leave comments. Related thought: Some consumer grade routers have the WiFi key and admin password in part of the flash that OpenWrt doesn't write over. It would be nice to be able to include those as defaults, if possible. Then the password(s) would be as written on the bottom of the device after a settings reset. Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
