Re: [PATCH 1/1] ltq-vdsl-app: add line_state number and power_state number
Smal typo? Mumber instead of Number?
Best Regards
Sebastian
> On Mar 9, 2021, at 12:36, Florian Eckert wrote:
>
> With the old ubus dsl API, the numbers for the individual line_states and
> power_states were also returned. These were not ported to the new DSL
> C-API. This commit changes the following JSON output.
>
> * current JSON output for state:
> "state": "Showtime with TC-Layer sync"
>
> * new JSON output for state:
> "line_state": {
>"mumber": 2049,
>"string": "Showtime with TC-Layer sync"
> },
>
> * current JSON output for power_state:
> "power_state": "L0 - Synchronized"
>
> new JSON outpug for power_state:
> "power_state": {
>"mumber": 0,
>"string": "L0 - Synchronized"
> }
>
> Signed-off-by: Florian Eckert
> ---
> .../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 22 +++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
> b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
> index 52b2be20e1..9d78b61188 100644
> --- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
> +++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
> @@ -306,7 +306,9 @@ static void version_information(int fd) {
> static void line_state(int fd) {
> IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
>
> + void *c;
> const char *str;
> +
> switch (out.data.nLineState) {
> STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
> STR_CASE(DSL_LINESTATE_EXCEPTION, "Exception")
> @@ -351,8 +353,13 @@ static void line_state(int fd) {
> str = NULL;
> break;
> };
> - if (str)
> - m_str("state", str);
> +
> + if (str) {
> + c = blobmsg_open_table(&b, "line_state");
> + m_u32("mumber", out.data.nLineState);
> + m_str("string", str);
> + blobmsg_close_table(&b, c);
> + }
>
> m_bool("up", out.data.nLineState == DSL_LINESTATE_SHOWTIME_TC_SYNC);
> }
> @@ -377,7 +384,9 @@ static void g997_line_inventory(int fd) {
> static void g997_power_management_status(int fd) {
> IOCTL(DSL_G997_PowerManagementStatus_t,
> DSL_FIO_G997_POWER_MANAGEMENT_STATUS_GET)
>
> + void *c;
> const char *str;
> +
> switch (out.data.nPowerManagementStatus) {
> STR_CASE(DSL_G997_PMS_NA, "Power management state is not available")
> STR_CASE(DSL_G997_PMS_L0, "L0 - Synchronized")
> @@ -388,8 +397,13 @@ static void g997_power_management_status(int fd) {
> str = NULL;
> break;
> };
> - if (str)
> - m_str("power_state", str);
> +
> + if (str) {
> + c = blobmsg_open_table(&b, "power_state");
> + m_u32("mumber", out.data.nPowerManagementStatus);
> + m_str("string", str);
> + blobmsg_close_table(&b, c);
> + }
> }
>
> static void g997_xtu_system_enabling(int fd, standard_t *standard) {
> --
> 2.20.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc3
Hi, great news the RC3 announcement. thanks a lot. On Jul 16, 2015, at 17:11 , ql li wrote: > AQM inflexible, overly complex set Could you elaborate a bit? Which AQM system do you find inflexible, qos-scripts or sqm-scripts? Complex to set up, I wonder? Both systems have a luci GUI in which all you need to do is fill in two numbers (Download and upload speed) and check one box and in sqm you also need to select the interface on which to establish AQM (then press save & apply) I wonder how it could be simpler? All the other options are basically optional and help to deal with the fact that reality is complex ;) Best Regards M. > > 2015-07-16 23:02 GMT+08:00 Yousong Zhou : >> >> On Jul 16, 2015 10:40 PM, "Steven Barth" wrote: >>> >>> The OpenWrt developers are proud to announce the third release candidate >>> of OpenWrt Chaos Calmer. >>> >> >> Thanks, guys. >> >> regards >> >>yousong >> >>> ___ __ >>> | |.-.-.-.| | | |..| |_ >>> | - || _ | -__| || | | || _|| _| >>> |___|| __|_|__|__||||__| || >>> |__| W I R E L E S S F R E E D O M >>> - >>> CHAOS CALMER (15.05 RC3) >>> - >>> * 1 1/2 oz GinShake with a glassful >>> * 1/4 oz Triple Sec of broken ice and pour >>> * 3/4 oz Lime Juice unstrained into a goblet. >>> * 1 1/2 oz Orange Juice >>> * 1 tsp. Grenadine Syrup >>> - >>> >>> - >>> http://downloads.openwrt.org/chaos_calmer/15.05-rc3/ >>> >>> ** Improvements since RC 2 ** >>> * brcmfmac: support for BCM43602 >>> * mt76: updated version with new firmware support, TX & DMA fixes >>> * Updated 3.18 to 3.18.18 >>> * Fixed image builder generation >>> * Various security updates (e.g. openssl, curl) >>> * Minor fixes >>> >>> ** Improvements since RC 1 ** >>> * Fixed broken ImageBuilders for most targets >>> * Updated 3.18 to 3.18.14 >>> * Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling >>> * Images (special format) for Asus brcm47xx and bcm53xx devices >>> * Improved stability of sysupgrade on brcm47xx and bcm53xx >>> * Added HTTPS enforcement option to uhttpd >>> * Fixed umask issue >>> * Added support for a few new boards >>> >>> >>> ** Highlights since Barrier Breaker ** >>> >>> * Linux kernel updated to version 3.18 >>> * Improved Security Features >>>- Rewritten package signing architecture based on ed25519 >>>- Added support for jails >>>- Added support for hardened builds >>> * Improved Networking Support >>>- Added or improved support for lots of 3G/4G modems (MBIM, QMI, NCM, >>> ...) >>>- Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050] >>>- Netfilter performance enhancements (conntrack route cache) >>>- Improved support for self-managing networks >>> [draft-ietf-homenet-hncp] >>>- Better multi-core support for the network stack >>>- Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning >>> technologies >>>[draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6] >>>- Improved network auto-setup capable of detecting and bootstrapping >>> IPv4-only, >>> 6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT >>> and combinations without explicit configuration [based on RFC 7084] >>>- Added support for Smart Queue Management (SQM) QoS, AQM and Traffic >>> Shaping >>>- Improved support for DNSSEC >>> * Platform and Driver Support >>>- Added support for feeds of externally maintained targets >>>- New mt7621 subtarget for Mediatek 11ac SoC >>>- New mt76 mac80211 based wifi driver for MTK 11ac cores. >>>- New mwlwifi mac80211 based wifi driver for the Marvell 88W8864 >>>- New bcm53xx target for Broadcom ARM BCM47xx/53xx devices >>>- New mxs target for Freescale i.MX23/28 family and various boards >>>- New sunxi target for AllWinner A10/A13/A20 family and various boards >>>- brcm2708: support for Raspberry Pi 2 >>>- brcm63xx: support for BCM6318 and BCM63268 family >>>- brcm63xx: improved fallback sprom support with bcma support >>>- New ipq806x target for QCA IPQ806x SoC family >>> >>> * Known Issues >>>- KALLSYMS is active causing some devices to fail >>> >>> And lots and lots of other advancements... >>> As always a big thank you goes to all our active package maintainers, >>> testers, supporters and documenters. >>> >>> >>> Have fun! >>>The OpenWrt developer team >>> ___ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> >> >> ___ >> openwrt-devel mailing list >
Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ?
On Sep 9, 2015, at 15:20 , Hannu Nyman wrote:
> I repeat my earlier wish that trunk should be renamed as soon as possible.
>
> There has been several changes during the summer that have made trunk to
> significantly deviate from the CC branch. Some of the changes are under the
> hood (like musl vs. uClibc),
We ran into this issue recently, where the switch to musl subtly
changed the regexp behavior of grep, and where it took a while to realize that
the reporter was on musl while all other testing machines where not. Having had
a "DD rNN” version string somewhere early in the report might have helped
figuring out the root cause faster… ("Chaos Chalmer Bleeding Edge" in
retrospect should have been signal enough, but it was not).
> but especially the recent telnet removal is rather prominent change for
> users. From documentation / advice / forum discussion perspective it is
> rather frustrating that both trunk and 15.05 are still referenced as "Chaos
> Calmer".
>
> Having trunk renamed to something Dxxx Dxxx would clarify things.
+1
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
Hi David, On May 16, 2016 10:46:25 AM GMT+02:00, David Lang wrote: >On Mon, 16 May 2016, Roman Yeryomin wrote: > >> On 16 May 2016 at 11:12, David Lang wrote: >>> On Mon, 16 May 2016, Roman Yeryomin wrote: >>> On 6 May 2016 at 22:43, Dave Taht wrote: > > On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin > > wrote: >> >> On 6 May 2016 at 21:43, Roman Yeryomin >wrote: >>> >>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer > >>> wrote: > That is too low a limit, also, for normal use. And: > for the purpose of this particular UDP test, flows 16 is ok, but >not > ideal. I played with different combinations, it doesn't make any (significant) difference: 20-30Mbps, not more. What numbers would you propose? >>> >>> >>> How many different flows did you have going at once? I believe that >the >>> reason for higher numbers isn't for throughput, but to allow for >more flows >>> to be isolated from each other. If you have too few buckets, >different flows >>> will end up being combined into one bucket so that one will affect >the other >>> more. >> >> I'm testing with one flow, I never saw bigger performance with more >> flows (e.g. -P8 to iperf3). > >The issue isn't performance, it's isolating a DNS request from a VoIP >flow >from a streaming video flow from a DVD image download. > >The question is how many buckets do you need to have to isolate these >in >practice? it depends how many flows you have. The default was 1024 >buckets, but >got changed to 128 for low memory devices, and that lower value got >made into >the default, even for devices with lots of memory. And I believe that the reduction was suboptimal, we need the Hash buckets to spread the glows around to avoid shared fate due to shared buckets... So the 1024 glows make a lot of sense even if the number of real concurrent flows is lower think birthday paradoxon. The change came because at full saturation our reduced packet limit only allowed one packet per bucket which is too low for decent performance... also less hash buckets make searching faster. Since we now can specify a memory limit in addition to the packet limit, we should set the packet limit back to its default of 10240 and instead set the memory limit to something same for each platform. This will effectively have the same consequences as setting a packet limit, except it becomes clearer why performance degrades and I at least take a performance hit gladly over a forced oom reboot > >I'm wondering if instead of trying to size this based on device memory, >can it >be resizable on the fly and grow if too many flows/collisions are >detected? > >David Lang >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.01 plans
Dear Jérôme, > On Sep 29, 2018, at 10:53, Jérôme Benoit wrote: > > Le 28/09/2018 à 18:55, Rosen Penev a écrit : >> >> So in kernel 4.17 I believe landed flow offloading support. This >> accomplishes something similar to SFE while being a proper upstream >> solution. This is already implemented in OpenWrt. > > flow offloading for NAT is different from SFE : > > In the first case, you offload the NATing algorithm work to the hardware > that support it, which narrow a lot the supported targets. > In the second case, you optimize the NATing algorithm Linux kernel > implementation for all targets, it's a software and generic optimization. As far as I can tell, SFE ans friends gain their speed advantage mainly by being less generic that the main kernel, so speaking of an optimization seems problematic. Because the reached better routing/NATing/whatever typically is quite fickle and might for example not be compatible with traffic shaping... Best Regards Sebastian > > -- > Jérôme Benoit aka fraggle > Piment Noir - https://piment-noir.org > OpenPGP Key ID : 27B535D3 > Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Is printf considered to be guaranteed?
Dear Developers, for a function for sqm-scripts I would very much like to use printf from inside a shell script. I would also like for sqm-scripts to keep working on all "compliant" openwrt builds. So here is my question, can I rely on the printf binary (or a link to the busybox fprintf) to be part of a standard build? Thank you very much in advance and... ... best regards Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is printf considered to be guaranteed?
Dear Luiz, thank you very much for this information. By now I have realized that printf evaluated locale (specifically LC_NUMERIC) at least on non-openwrt unices, which makes it unfortunately unusable for my purpose. Best Regards Sebastian > On Oct 11, 2018, at 19:58, Luiz Angelo Daros de Luca > wrote: > > I think so. It is compiled by default: > > $ grep PRINTF -A2 package/utils/busybox/Config-defaults.in > config BUSYBOX_DEFAULT_PRINTF > bool > default y > -- > config BUSYBOX_DEFAULT_ASH_PRINTF > bool > default y > -- > config BUSYBOX_DEFAULT_HUSH_PRINTF > bool > default n > > Regards, > -- > Luiz Angelo Daros de Luca > luizl...@gmail.com > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is printf considered to be guaranteed?
Dear mhei,
> On Oct 12, 2018, at 20:53, Michael Heimpold wrote:
>
> Am Donnerstag, 11. Oktober 2018, 22:44:53 CEST schrieb Sebastian Moeller:
>> Dear Luiz,
>>
>> thank you very much for this information. By now I have realized that printf
>> evaluated locale (specifically LC_NUMERIC) at least on non-openwrt unices,
>> which makes it unfortunately unusable for my purpose.
>
> forcing local, e.g.
> LANG=C printf "%0.3f" 47.11
> does not help?
That might actually work, I tried LC_NUMERIC which did not work on
openwrt.
> Maybe you could elaborate on your purpose?
Well I wanted to have a shell variable for configuring a buffer by the
time in milliseconds required to empty that buffer (at a given bandwidth), but
wanted to actually allow values down to microseconds.
So I tried to use the following to effectively convert a value in (fractional)
milliseconds into microseconds for use by the actual consumer like:
TMP=1.015 ; printf %.0f\n "${TMP}e3"
Shell only operates on integers so doing it in shell did not give the desired
results, and the printf trick seemed like a acceptable work-around. But due to
the locale sensitivity I simply switched the configuration parameter from
milliseconds to microseconds side stepping the whole problem. (The reason I
wanted milliseconds to begin with is that my hypothesis is that single digit
milliseconds are reasonable and sane values, but for exceptional cases it might
be nice to go down to microseconds). I hope this clarifies the issue.
Best Regards
Sebastian
>
> Regards,
> mhei
>
>>
>> Best Regards
>> Sebastian
>>
>>> On Oct 11, 2018, at 19:58, Luiz Angelo Daros de Luca
>>> wrote:
>>>
>>> I think so. It is compiled by default:
>>>
>>> $ grep PRINTF -A2 package/utils/busybox/Config-defaults.in
>>> config BUSYBOX_DEFAULT_PRINTF
>>>
>>>bool
>>>default y
>>>
>>> --
>>> config BUSYBOX_DEFAULT_ASH_PRINTF
>>>
>>>bool
>>>default y
>>>
>>> --
>>> config BUSYBOX_DEFAULT_HUSH_PRINTF
>>>
>>>bool
>>>default n
>>>
>>> Regards,
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
> On Dec 7, 2018, at 08:29, Shaleen Jain wrote: > > Hi, > > [...] > The point about these boards requiring a lot of modification to be useful is > simply not true. > I have a TP-Link tl-wr841n-v11 running the master branch with kernel 4.14 > with luci > and sqm-scripts + miniupnpd with no problem at all. > > The only change I had to do was disable IPv6 and the opkg package from the > build image > resulting in the final image size of 3.8M [...] Jettisoning IPv6 seems like a size-reduction method that is not generally applicable, how is say ds-lite going to work on such a device? This is fine for the use case of an experienced (of well coached novice) user who understands the consequences, but it does not seem like a generic way to produce smaller images sizes for all users, no? - Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Typo: sysupgarde
Please see https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4bd9d331e5854e8325fd3b7a5f14e355a6a3c66d for why the typo disappeared from master > On Jan 12, 2019, at 21:56, Petr Štetiar wrote: > > Thomas Endt [2019-01-12 09:32:43]: > > Hi, > >> FYI: There is a typo in 3 files: "upgarde" instead of "upgrade" >> >> target/linux/octeon/base-files/lib/upgrade/platform.sh >> 91 echo "The upgarde image is corrupt." >> tools/firmware-utils/src/mkdapimg.c >> 15 // e.g.: mkdapimg -s RT3052-AP-DAP1350-3 -i sysupgarde.bin -o >> factory.bin >> tools/firmware-utils/src/mkdapimg2.c >> 51 // -k 917504 -i sysupgarde.bin -o factory.bin > > thanks for reporting, but I can't find those typos in the current master. > > -- ynezz > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Notes on (dangerous ?) sysupgrade
Mmmh, I have a hunch a recent observation of mine might be related (unfortunately I have no log data): Within a set of recent master builds, sysupgrade from a system running for a few days resulted in the expected behavior in that sysupgrade disconnected the current ssh connection and the LED pattern on the router looked as if the device was updating itself but after the automatic reboot the router came back up still with the previous firmware. Redoing the sussupgrade on that just booted system so far always worked as expected. I think I only started to see this with builds from end of last year on. So far I brushed this off as signs that my trusty old wndr3700v2 might be reaching the end of its life, but with this report I am not so sure and will try to log things better the next time this happens. > On Jan 13, 2019, at 11:08, Reiner Karlsberg wrote: > > I am an unhappy user of sysupgrade for remote installed devices. > (Besides these ones: > https://forum.openwrt.org/t/sysupgrade-return-code-in-18-06-vs-17-01/22316/9) > > After having several unpleasant encounters using sysupgrade, I had a quick > glance at the code, after more or less successfully implementing workarounds > for incomplete sysupgrades, resulting in inconsistent systems. > My questions are: > - Is it safe, simply to kill running processes during sysupgrade ? As there > might be services, restarted automatically (by procd ?). > - What about a killed process, simply taking some time to shut down ? > (example: squid closing lot of open files on block-device; having internal > shutdown timer 30s by default) > - What about open swap file on block-device ? > - What about mounted block-device for mass storage ? > - What about (slow) wwan connection, managed by pppd. When killed by > sysupgrade, will netifd restart pppd ? > > As a workaround, before calling sysupgrade I > - explicitly use /etc/init.d/most_services stop > - explicitly kill squid and wait for termination > - explicitly disable swap > - explicitly dismount mounted block-device > - ifdown wwan > > Before I had several cases, that > sysupgrade -n -v -f /tmp/newfiles.tar.gz /tmp/new_fw.bin > updated all files from /tmp/newfiles.tar.gz, but did not do the flash of > new_fw.bin > Resulting in inconsistent system. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi Gui, On Jul 16, 2014, at 20:10 , Gui Iribarren wrote: > On 16/07/14 12:09, Gert Doering wrote: >> Hi, >> >> On Wed, Jul 16, 2014 at 08:41:50AM -0300, Gui Iribarren wrote: >>> then, what happens when those devices are deployed in a myriad of >>> real-world scenarios? hackers rejoice! >> >> This actually is a somewhat moot arguments. Devices travel today, and >> while your home network and office network might be behind a firewall, >> the hotspot you're using while waiting for your train might not be. >> >> So with todays devices, every device needs to be able to protect itself >> (i.e.: host firewall, services only accepting connection from "local >> network", etc. - windows 7 doing a fairly good job with this today). >> >> The old model "strong firewall, weak devices behind it" is just a thing >> not matching reality anymore... > > Ah, sorry if irony blurred my position: > your point, Gert, is exactly my point :) > > in other words, we're both on the same side: my arguments are in favour > of openwrt having an open ipv6 firewall by default, so to put the policy > back into end-devices hands (where it always should have been) ??? The part in parenthesis is debatable... > > Benjamin is giving some great examples of real-world scenarios where an > default-open firewall simplifies administration, > and where a default-closed firewall would be not only unnecessary > (provides no benefits), but would indeed complicate setting up things. My interpretation of his examples is that putting the MAC/IPv6-addresses into a router-managed whitelist would have not significantly increased the amount of work involved... > > proprietary-software personal devices are a special case - granted. > putting that aside, i think it's insightful to consider that a person > that has admin access to all her mobile devices config (which carries > every day), so to publish (or restrict) services at her own will, > if and only if the network devices upstream (to which might have no > control over) have a default-open firewall. But in your home you have control over the router’s setting, so explicitly managing the access rights is an easy way deal with the quite common case you just put aside? Or what is your idea about the proprietary-software personal devices. I could envision two “networks” a secured default-closed and on optimistic default-open network managed by the same router (sort of like a guest network with default-open, while the main network is default-closed or vice versa). > > in ipv4 world, there was no discussion: a default-open inbound policy in > routers that would let end-hosts decide, was simply not possible. ? The default could have been to direct everything to one internal host (say lowest MAC or first discovered device). > why carry that legacy restriction into the wonderful ipv6 world? What is so wonderful about IPv6? Maleware surely will evolve quickly to take advantage of a dropped layer of defense… For experts as you and Benjamin the default does not really matter that much you can easily change it to your liking; but think about non-experts. I for one would be quite startled if the switch to IPv6 would expose parts of my device zoo that was never configured with that problem in mind…. Best Regards Sebastian > > chee::rs! > > gui > >> >> gert >> > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hello Benjamin, On July 17, 2014 7:45:10 PM CEST, Benjamin Cama wrote: >Le mercredi 16 juillet 2014 à 21:12 +0200, Sebastian Moeller a écrit : >> What is so wonderful about IPv6? Maleware surely will evolve quickly >> to take advantage of a dropped layer of defense… > >“Layer of defense”? To most, it will just translate to a brick wall >that >will have to be worked around by some other mean because nobody except >advanced user can configure their firewall. I argue that people unable to change the router settings are better of with all unsolicited inbound traffic disabled. > >> For experts as you and Benjamin the default does not really matter >> that much you can easily change it to your liking; but think about >> non-experts. > >I totally do this for non-experts: non-experts won't ever touch their >default configuration. So, basically, they will have no inbound >connection possible, so manufacturer will find other mean to do >whatever >they can to allow for that to happen (as they are doing today with >IPv4). It will just be even less controllable by yourself (custom >protocols, etc). Even if PCP comes: imagine then that device configured >with PCP will be accessible from outside, and… will they be magically >immune to anything this way? They will have to be secured anyway. Note that I argue for a per device white list especially since I do not think that an automatic port opening method has the security guarantees I hope for. But note that with your proposal ALL devices need expert configuration. There is no magic immunity by ports closed by default' just a reduced attack surface... > >> I for one would be quite startled if the switch to IPv6 would expose >> parts of my device zoo that was never configured with that problem in >> mind…. > >Please, cite me any device today that can be dangerously exposed by an >IPv6 connectivity. While not from today: http://www.kb.cert.org/vuls/id/986425 looks pretty bad... Actually googling for IPv6 cve does seem to find quite a lot. At least enough to make port open by default look like a risky proposition. Now you could argue that all Linux CVEs will also affect the router... But assuming all ipv6 devices will stay safe and secure forever seems a bit to optimistic... > >A printer, for example, should be bound (to me) to a link-local address >by default. I don't know any manufacturer who does so (well, they don't >support IPv6 anyway…). > >-- >benjamin -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi Karl, On July 17, 2014 11:40:52 PM CEST, Karl P wrote: > > >On 07/17/2014 08:26 PM, Sebastian Moeller wrote: >> >>I argue that people unable to change the router settings are >better of with all unsolicited inbound traffic disabled. > >I've tried to avoid weighing in on this, but I'd argue that you're >wrong :) >Making sure that people can _never_ have services in the future, just >because >they never had them in the past is a terrible way to live. It seems I was not clear enough: what I meant is: if one can not be added to expose a host IP and port range in one's router than maybe one does not really need the inbound connection to begin with. All that "people" in my statement need to do is google how to open the ports, not exactly rocket science, is it? People incompetent enough to not being able to open the ports on the router are unlikely to keep all their devices perfectly safe and updated (as if that is enough, given zero-day exploits, but I digress). Really, I do wonder how easy we want to make an attacker's job here ;) Best Regards Sebastian > >Sincerely, >Karl Palsson >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi Gui, hi list, Gesendet: Freitag, 18. Juli 2014 um 05:56 Uhr Von: "Gui Iribarren" An: openwrt-devel@lists.openwrt.org Betreff: Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1) On 17/07/14 21:59, Fernando Frediani wrote: > > Perfect and well said. > > > > Really don't see why people still think leaving firewalls opened is a > > good idea. > > leaving *hosts* firewalls opened is a really bad idea. Agreed. > > But openwrt doesn't run on hosts, it runs on network equipment > I.e. the building blocks of Internet. > Carriers don't block traffic, > ISP don't block traffic, > and back in the day, CPE equipment didn't block traffic either (think of > dialup, or dumb cablemodems which would simply act as a bridge) > "firewall" was a software installed in the computer connected to the > cablemodem > > Then, with the ever increasing quantity of devices vs the evident > shortage of IPv4, people started to use NAT, or ISPs started to ship > CPEs that would do NAT, which made two-way transparent communication > impossible. Well, with the growth of the internet also the profitability grew, so malware grew along with the internet. So the need for NAT and the need for more secure home setups co-developed, I would say. > I find it difficult to argue that NAT success was driven by a security > concern, rather than by IP scarcity. :P [1] > > Fast-forward a few years, we have a new Internet Protocol being widely > deployed that solves the address scarcity, and thus makes NAT unnecessary. Sure, NAT can easily go the way of the Dodo, as long as we keep dropping unsolicited inbound traffic in the router's firewall ;) > > Now CPEs can work again like transparent devices. > > ps. RFCs that argue that NAT resulted in a *reduction in security*... Yes, but we are talking not about having openwrt default to ipv6 NAT but what to do with unsolicited inbound traffic, not exactly what is dicussed in the cited rfc... > > [0]: http://tools.ietf.org/rfc/rfc6092.txt , january/2011 > > Security Considerations > The IPv6 stateful filtering behavior described in this document is > intended to be similar in function to the filtering behavior of > commonly used IPv4/NAT gateways, which have been widely sold as a > security tool for residential and small-office/home-office networks. > As noted in the Security Considerations section of [RFC2993], the > true impact of these tools may be a reduction in security. It may be > generally assumed that the impacts discussed in that document related > to filtering (and not translation) are to be expected with the simple > IPv6 security mechanisms described here. > > In particular, it is worth noting that stateful filters create the > illusion of a security barrier, but without the managed intent of a > firewall. Appropriate security mechanisms implemented in the end What exactly is "managed intent of a firewall"? > nodes, in conjunction with the [RFC4864] local network protection > methods, function without reliance on network layer hacks and > transport filters that may change over time. Also, defined security > barriers assume that threats originate in the exterior, which may > lead to practices that result in applications being fully exposed to > interior attack and which therefore make breaches much easier. > > [1]: > http://tools.ietf.org/rfc/rfc2993.txt[http://tools.ietf.org/rfc/rfc2993.txt] > , november/2000, > 11. Summary > NAT advantages - no item about security Did you read the last bullet point on opage 8 of rfc 2993? Where NAT is likened with port filtering firewalls in regard to inbound connections, that does not use the word security, but implies it nevertheless. So the RFC explicitly recommends to close all ports by default! And there is a tacked on rant about the 'illusion of security' by an unmanaged firewall is quite funny in thid threads context, as people who can/will not keep the firewall well-configured, surely will manage to keep all their local endpoint machines fully patched, upgraded and securely configured. Your proposal will expose exactly the internaol network nodes of thiose that already have shown not to be too interested in securing their setup... (with the main justification, IIRC, how nice it would be to run open server's on other people's networks). Best Regards Sebastian > At the end it will bring more problems than solutions for those using > OpenWRT and play against its good reputation. > > As mentioned before adjusting firewall for specific needs or using UPnP > isn't the end of the world. > > Regards, > > Fernando > > On 18/07/2014 01:03, David Lang wrote: >> I know that IPv6 designers pine for the "good old days" of the >> Internet when no security was needed. >> >> But the reality is that hackers and worms have shown that leaving >> systems exposed to the Internet is just a Bad Idea. >> >> As such, the idea that IPv6 would "restore" the "everyone ca
Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Hi Weedy, On Oct 2, 2014, at 05:46 , Alpha Sparc wrote: > How good is the throughput on CeroWrt compared to OpenWrt ? I assume you are talking about the pure routing performance with no firewall/NAT and traffic-shaping involved? I think they pretty much are equal (pretty much the same kernel and most of the cerowrt guts are from openwrt bb trunk). But I have not tested that (I have only one cerowrt/openwrt capable router and that pretty much is my main router). If you are talking about comparing QOS-scripts with SQM-scripts, they also seem to top out at roughly 50-60 Mbps (down- and uplink combined), it seems hfsc (qos-scripts) and HTB (sam-scripts) are equally expensive on MIPS. Now if you are setup to do tests yourself I would love to hear the results. I would be happy to help you getting SQM-scripts to work (so far all people interested disappeared before or just after sharing initial test results). Best Regards Sebastian > > On Oct 2, 2014 9:55 AM, "Dave Taht" wrote: > On Wed, Oct 01, 2014 at 12:10:46PM -0400, Weedy wrote: > > On 30/03/14 06:29 PM, Dave Taht wrote: > > > On Sun, Mar 30, 2014 at 02:24:44PM -0400, Weedy wrote: > > >> On Sat, Mar 29, 2014 at 2:56 PM, Dave Täht > > >> wrote: > > >> > > >>> From: Dave Taht > > >>> > > >>> This adds support for the bufferbloat project's "Smart Queue Management" > > >>> (SQM) system, which improves over openwrt's qos-scripts in the following > > >>> ways > > >>> > > >>> + Uses HTB with two models for managing traffic > > >>> a simplest one that merely uses fq_codel, and a three tier one that > > >>> does > > >>> some basic and tunable packet prioritization. > > >>> > > >>> + Works with ipv6 and ipv4 correctly (unlike qos-scripts) > > >>> + extensive support for fixing ADSL and PPOe framing problems > > >>> + Partial support for key diffserv markings > > >>> + highly tuned fq_codel implementation especially for low bandwidths > > >>> + Tested heavily on cable modems and on dsl devices > > >>> > > >>> It is a disimprovement in that: > > >>> > > >>> - There are no built-in tricks for doing l7 classification, > > >>> or other forms of packet inspection. > > >>> > > >>> - We haven't explored hfsc all that much, prefering to rely > > >>> on the predictable behavior of htb + fq_codel for everything > > >>> > > >>> - And there is support for a few qdiscs that are not in the linux > > >>> kernel mainline that remain experimental. > > >>> --- > > >>> net/sqm-scripts/Makefile | 48 +++ > > >>> net/sqm-scripts/files/etc/config/sqm | 11 + > > >>> net/sqm-scripts/files/etc/init.d/sqm | 23 ++ > > >>> net/sqm-scripts/files/usr/lib/sqm/functions.sh | 335 > > >>> > > >>> net/sqm-scripts/files/usr/lib/sqm/run.sh | 67 > > >>> net/sqm-scripts/files/usr/lib/sqm/simple.qos | 187 +++ > > >>> net/sqm-scripts/files/usr/lib/sqm/simple.qos.help |1 + > > >>> net/sqm-scripts/files/usr/lib/sqm/simplest.qos | 84 + > > >>> .../files/usr/lib/sqm/simplest.qos.help|1 + > > >>> net/sqm-scripts/files/usr/lib/sqm/stop.sh | 22 ++ > > >>> 10 files changed, 779 insertions(+) > > >>> create mode 100644 net/sqm-scripts/Makefile > > >>> create mode 100644 net/sqm-scripts/files/etc/config/sqm > > >>> create mode 100755 net/sqm-scripts/files/etc/init.d/sqm > > >>> create mode 100644 net/sqm-scripts/files/usr/lib/sqm/functions.sh > > >>> create mode 100755 net/sqm-scripts/files/usr/lib/sqm/run.sh > > >>> create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simple.qos > > >>> create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simple.qos.help > > >>> create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simplest.qos > > >>> create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simplest.qos.help > > >>> create mode 100755 net/sqm-scripts/files/usr/lib/sqm/stop.sh > > >>> > > >>> diff --git a/net/sqm-scripts/files/etc/config/sqm > > >>> b/net/sqm-scripts/files/etc/config/sqm > > >>> new file mode 100644 > > >>> index 000..547d321 > > >>> --- /dev/null > > >>> +++ b/net/sqm-scripts/files/etc/config/sqm > > >>> @@ -0,0 +1,11 @@ > > >>> + > > >>> +config queue 'ge00' > > >>> +option enabled '0' > > >>> +option interface 'ge00' > > >>> +option download '2' > > >>> +option upload '4000' > > >>> +option qdisc 'fq_codel' > > >>> +option script 'simple.qos' > > >>> +option qdisc_advanced '0' > > >>> +option linklayer 'none' > > >>> + > > >>> > > >> > > >> How hard is this to config from the command line/vim? > > > > > > There are a few more options than this (for DSL compensation, ecn > > > and advanced configuration), the above would work if you changed > > > enabled to '1' and the device from ge00 to your wan device. (not > > > the "wan" firewall rule, presently. ) > > > > > > It does help to have a sane long ter
Re: [OpenWrt-Devel] [Cerowrt-devel] better ingress shaping somehow
Hi Dave, On Oct 3, 2014, at 01:07 , Dave Taht wrote: [cut a lot...] > But: the real killer, on ingress shaping, is the call to skb_clone in > sch_ingress->act_mirred path, I think. So I thought that we basically have around 50Mbps “shaping-capability” on the wndrs which hew can distribute between egress and ingress, but if your analysis is correct wouldn’t that mean that shaping egress is cheaper? (Not that this has much relevance in the real world due uplink << downlink asymmetry the ISPs push onto us endusers) > > If it were possible to have sch_cake replace sch_ingress, that would > be a huge win, but following the call path for why that must be cloned > has thus far resisted my archeological expertise. An network ninja > is needed here […] ;) Best Regards Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Cerowrt-devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Hi Richard, On Oct 6, 2014, at 18:02 , Richard A. Smith wrote: > On 10/02/2014 10:05 AM, Sebastian Moeller wrote: > >> I assume you are talking about the pure routing performance with no >> firewall/NAT and traffic-shaping involved? I think they pretty much are >> equal (pretty much the same kernel and most of the cerowrt guts are from >> openwrt bb trunk). But I have not tested that (I have only one >> cerowrt/openwrt capable router and that pretty much is my main router). >> If you are talking about comparing QOS-scripts with SQM-scripts, they >> also seem to top out at roughly 50-60 Mbps (down- and uplink combined), it >> seems hfsc (qos-scripts) and HTB (sam-scripts) are equally expensive on MIPS. >> Now if you are setup to do tests yourself I would love to hear the >> results. I would be happy to help you getting SQM-scripts to work (so far >> all people interested disappeared before or just after sharing initial test >> results). > > Do you still need testers? I have a bit of an interest here. Oh, sure every little bit of testing is helpful (especially on openwrt, as I am not setup to test openwrt at all). I might be that SQM-scripts will explode spectacularly, but I hope that there is only a little “impedance-mismatch” ;) > > I have spare routers that I can run OpenWRT or CeroWRt on and I'm setup to > test with netperf, netperf-wrapper on my local network > ( desktop -> router -> laptop ) it's Gbit so I can easily saturate the > router. That sounds great. I think the first test should be to run SQM under cerowrt, so you get a feel of how things should look. I typically run netperf-wrapper rrul tests (for ipv4 and if available for ipv6) through cerowrt with different settings for SQM. A second step then is to instal SQM-scripts under openwrt and check whether the same settings produce the same results ;) > > What I don't have is a lot of time but I can do a few runs in the evenings or > on weekends. I think all that is needed is testing a few relevant shaping bandwidth combinations (always Downlink/Uplink, 3000Kbps/512Kbps, 16000Kbps/1000Kbps, 5Kbps/1Kbps, 10Kbps/4Kbps, and 0/5Kbps, with a setting of 0 disabling shaping in a particular direction, 0/5Kbps with the ethernet interface set 100Mbps, and with SQM disabled: pick the test set most relevant to your planned deployment to save time) And finally it would be great to test whether the ATM link layer encapsulation also works… Basically that is the set of things to test, but the most important is just testing one of them to see hw SQM-scripts (and luci-app-sqm works under stock openwrt) > I also am very out of touch with the latest and greatest QoS vs SQM > development and configuration so you will have to feed me test recipes. Oh, happy to help out with this, thanks to Toke’s netperf-wrapper my tests typically look like (for say 3000Kbps/512Kbps): date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv4 -l 300 -s 0.4 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t IPv4_test_D3000Kbps-U512Kbps followed by: date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv6 -l 300 -s 0.4 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t IPv6_test_D3000Kbps-U512Kbps for links faster than ~5Mbps or so you can skip the -s 0.4 line and for links slower than 2Mbps you probably need rouse -s 0.8 or even -s 1.0, running for 5 minutes (-l 300) makes sure you can also judge the robustness/stability of the shaping... And then simply load the resulting output files in netperf-wrapper’s GUI to simplify comparison between the different SQM settings (and since these tests work independent of the used shaper you could also run the relevant shaper settings for your own situation through QOS. So you can compare how these two stack up against each other…) It might be a good idea to capture the output of: logread and: tc -d qdisc and tc class show dev ge00 (for cerowrt, “tc class show dev wan” for openwrt, I believe) before each test run on the router (this allows to confirm whether the selected shaper settings actually were applied properly) I also, very unscientifically, ssh into the router while the tests are running and start “top -d 1” and visually monitor the %idle and %sirq (softinterrupts), the first goes to 0% and the second to >90% once you reached the your router’s shaping limit. So just let me know what you are willing/ready to test and we will take it from there okay? (I would already be a happy camper if you could just install the current SQM-scripts on openwrt and just send me the output of “logread” after installing and activating SQM, as well as the output from “tc -d qdisc” before and after enabling
Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Hello Stephan, On Oct 9, 2014, at 01:01 , Stephan Günther wrote: > Hi, > > On Wed, Oct 8, 2014 at 10:10 PM, Hannu Nyman wrote: >> Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014: >>> So I don't know where to go. Certainly I'd like to see the battle hardened >>> sqm scripts (which are more flexible than the C code above) get more widely >>> used and in BB. >> >> SQM seems to work ok with the current Chaos Calmer trunk. > > Works for mee too, and performs much better than the old luci-app-qos. > I would love to see this as part of OpenWrt. > > I did some RRUL test using netperf-wrapper on my ADSL 15/1Mbps PPPoE > link and it looks good in the graphs. I also have an 6in4 tunnel > inside PPPoE and IIRC fq_codel should detect these ipv6 flows. RRUL > looks good at IPv6. Had this running at home for some days now, with > moderate traffic and no issues so far. > > But I was wondering which interface to select luci-app-sqm, as no > tunnel intefaces are shown here. So i used the ethernet interface > instead of the PPPoE link. Is this fine? So with using the ethernet link I see that the classification on egress does not seem to work anymore (and I loose some uplink bandwidth) but latency under load stays reasonable (all tested with netperf-wrapper’s RRUL test), Using pppoe-ge00 (I changed luci-app-sqm to show all devices except lo) I also notice the issue that this device can go away temporarily (while renegotiating the connection with the BRAS I assume) and that can lead to a half-baked SQM system where either the up or downlink (do not remember which, and test files are not accessible) ends up withe no shaping applied. Note that the kernel assumes different default per packet overheads for the ethernet interface (kernel automatically adds 14 bytes) and the pppoe-ethernet interface (where it looks like the kernel does not add any overhead), so I found on cerowrt I need to change the overhead number in SQM’s link layer tab to get similar results. I think shaping on the ethernet interface is what we should do (and try to figure out why classification does not seem to work) > Minutes ago, I did a quick > test and applied SQM to the PPPoE link by fixing luci-base to return > also the virtual interfaces in net:get_interfaces(). But i didn't > notice any difference or my test was too sloppy. Could you send me the json.gz file from both a run with SQM on the ethernet interfere and on the pppoe interface, please, so I can compare with my own tests? Best Regards Sebastian > > -- > Stephan > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Cerowrt-devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Hi Richard, On Oct 9, 2014, at 18:42 , Richard Smith wrote: > On 10/06/2014 03:41 PM, Sebastian Moeller wrote: > >>> >>> I have spare routers that I can run OpenWRT or CeroWRt on and I'm >>> setup to test with netperf, netperf-wrapper on my local network ( >>> desktop -> router -> laptop ) it's Gbit so I can easily saturate >>> the router. >> >> That sounds great. I think the first test should be to run SQM under >> cerowrt, so you get a feel of how things should look. I typically run >> netperf-wrapper rrul tests (for ipv4 and if available for ipv6) >> through cerowrt with different settings for SQM. A second step then >> is to instal SQM-scripts under openwrt and check whether the same >> settings produce the same results ;) > > Ok. I'll get my spare WNDR3700v2 up running the latest cerowrt. Should be > in the next few days. I'm a bit strapped for time right now. No hurry, I really appreciate your help and there is no time pressure (rather the other way around, I do this for a hobby, and real life leaves almost no time for that ;) ) > >> So just let me know what you are willing/ready to test and we will >> take it from there okay? (I would already be a happy camper if you >> could just install the current SQM-scripts on openwrt and just send >> me the output of “logread” after installing and activating SQM, as >> well as the output from “tc -d qdisc” before and after enabling SQM, >> and finally the output of running “/etc/init.d/sqm stop ; >> /etc/init.d/sqm start” on the router’s console; that hopefully works >> or at least gives some indication what might be off. If you could >> throw in a quick netperf-wrapper RRUL test through the router I will >> be most delighted ;)) > > Ok. That sounds like a good starter step. First question: Where are the > current SQM scripts located and what's the process for installing them? Are > they packages or stuff that I scp over and manually install? So the repository lives on: https://github.com/dtaht/ceropackages-3.10 I just followed Dave’s advice and used: git clone g...@github.com:dtaht/ceropackages-3.3.git to get my own version to play around with. Oh, SQM basically is the work of Dave (who wrote the scripts doing the actual AQM&QOS work) and Toke you packaged all this nicely and created the GUI for it (all I ever did was shuffling the GUI around a bit). I just started hacking around the files from sqm-scripts and luck-app-sqm on my cerowrt (so I could immediately do some testing), so I never got around building actual packages (I assume you need to be setup to build whole openwrt/cerowrt images and that is outside the scope of my recreational coding), But that said if you copy the files from ceropackages-3.10/net/sqm-scripts/files to the matching directory on your router you should have a working sqm-script. Or just use a cerowrt built as SQM is standard and potentially hnyman’s build ( https://forum.openwrt.org/viewtopic.php?id=28392 ) that also includes SQM. Best Regards Sebastian > > I'll let you know when I've taken a stab at getting that working. > > > Richard A. Smith > > Former One Laptop per Child > > Just FYI: I'm slowly switching my list subs over from my previous @laptop.org > address to my personal address. Just switched this one over thus the email > address change. > > -- > Richard A. Smith ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Cerowrt-devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Ooops, On Oct 9, 2014, at 20:13 , Dave Taht wrote: > 3.3 is obsolete, use 3.10. What Dave says, I should have actually looked at the copied link… Sorry Sebastian > > On Thu, Oct 9, 2014 at 10:57 AM, Sebastian Moeller wrote: >> Hi Richard, >> >> On Oct 9, 2014, at 18:42 , Richard Smith wrote: >> >>> On 10/06/2014 03:41 PM, Sebastian Moeller wrote: >>> >>>>> >>>>> I have spare routers that I can run OpenWRT or CeroWRt on and I'm >>>>> setup to test with netperf, netperf-wrapper on my local network ( >>>>> desktop -> router -> laptop ) it's Gbit so I can easily saturate >>>>> the router. >>>> >>>> That sounds great. I think the first test should be to run SQM under >>>> cerowrt, so you get a feel of how things should look. I typically run >>>> netperf-wrapper rrul tests (for ipv4 and if available for ipv6) >>>> through cerowrt with different settings for SQM. A second step then >>>> is to instal SQM-scripts under openwrt and check whether the same >>>> settings produce the same results ;) >>> >>> Ok. I'll get my spare WNDR3700v2 up running the latest cerowrt. Should be >>> in the next few days. I'm a bit strapped for time right now. >> >>No hurry, I really appreciate your help and there is no time pressure >> (rather the other way around, I do this for a hobby, and real life leaves >> almost no time for that ;) ) >> >>> >>>> So just let me know what you are willing/ready to test and we will >>>> take it from there okay? (I would already be a happy camper if you >>>> could just install the current SQM-scripts on openwrt and just send >>>> me the output of “logread” after installing and activating SQM, as >>>> well as the output from “tc -d qdisc” before and after enabling SQM, >>>> and finally the output of running “/etc/init.d/sqm stop ; >>>> /etc/init.d/sqm start” on the router’s console; that hopefully works >>>> or at least gives some indication what might be off. If you could >>>> throw in a quick netperf-wrapper RRUL test through the router I will >>>> be most delighted ;)) >>> >>> Ok. That sounds like a good starter step. First question: Where are the >>> current SQM scripts located and what's the process for installing them? >>> Are they packages or stuff that I scp over and manually install? >> >>So the repository lives on: >> https://github.com/dtaht/ceropackages-3.10 >> I just followed Dave’s advice and used: >> git clone g...@github.com:dtaht/ceropackages-3.3.git >> to get my own version to play around with. Oh, SQM basically is the work of >> Dave (who wrote the scripts doing the actual AQM&QOS work) and Toke you >> packaged all this nicely and created the GUI for it (all I ever did was >> shuffling the GUI around a bit). I just started hacking around the files >> from sqm-scripts and luck-app-sqm on my cerowrt (so I could immediately do >> some testing), so I never got around building actual packages (I assume you >> need to be setup to build whole openwrt/cerowrt images and that is outside >> the scope of my recreational coding), But that said if you copy the files >> from ceropackages-3.10/net/sqm-scripts/files to the matching directory on >> your router you should have a working sqm-script. Or just use a cerowrt >> built as SQM is standard and potentially hnyman’s build ( >> https://forum.openwrt.org/viewtopic.php?id=28392 ) that also includes SQM. >> >> Best Regards >>Sebastian >> >>> >>> I'll let you know when I've taken a stab at getting that working. >>> >>>> Richard A. Smith >>>> Former One Laptop per Child >>> >>> Just FYI: I'm slowly switching my list subs over from my previous >>> @laptop.org address to my personal address. Just switched this one over >>> thus the email address change. >>> >>> -- >>> Richard A. Smith >> >> ___ >> Cerowrt-devel mailing list >> cerowrt-de...@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Dave Täht > > https://www.bufferbloat.net/projects/make-wifi-fast ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Cerowrt-devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Hi Luis, On Oct 9, 2014, at 20:05 , Luis E. Garcia wrote: > Please excuse my dumb question or just point me to the right documentation. > But is there an easy way to run AQM/Codel on BB 14.07 ?? I'm running BB on a > MyNETN750 that looks like it meets the HW requirements. There probably is, I assume you need to install ip-full from the BB repository, and then copy http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.50-1/packages/luci-app-sqm_3-1_all.ipk and http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.50-1/packages/sqm-scripts_6-1_all.ipk onto your router and try: opkg install sqm-scripts_6-1_all.ipk and: opkg install luci-app-sqm_3-1_all.ipk You might need to play with opkg options, but in theory it should work… There probably also is a nicer way like adding a stanza similar to: src/gz toronto http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.50-1/packages to /etc/opkg.conf but I do not know the exact incantation of that, maybe hnyman, or Dave know the correct answer to this.. Best Regards Sebastian > > Regards, > Luis Garcia > > On Thu, Oct 9, 2014 at 12:57 PM, Sebastian Moeller wrote: > Hi Richard, > > On Oct 9, 2014, at 18:42 , Richard Smith wrote: > > > On 10/06/2014 03:41 PM, Sebastian Moeller wrote: > > > >>> > >>> I have spare routers that I can run OpenWRT or CeroWRt on and I'm > >>> setup to test with netperf, netperf-wrapper on my local network ( > >>> desktop -> router -> laptop ) it's Gbit so I can easily saturate > >>> the router. > >> > >> That sounds great. I think the first test should be to run SQM under > >> cerowrt, so you get a feel of how things should look. I typically run > >> netperf-wrapper rrul tests (for ipv4 and if available for ipv6) > >> through cerowrt with different settings for SQM. A second step then > >> is to instal SQM-scripts under openwrt and check whether the same > >> settings produce the same results ;) > > > > Ok. I'll get my spare WNDR3700v2 up running the latest cerowrt. Should be > > in the next few days. I'm a bit strapped for time right now. > > No hurry, I really appreciate your help and there is no time pressure > (rather the other way around, I do this for a hobby, and real life leaves > almost no time for that ;) ) > > > > >> So just let me know what you are willing/ready to test and we will > >> take it from there okay? (I would already be a happy camper if you > >> could just install the current SQM-scripts on openwrt and just send > >> me the output of “logread” after installing and activating SQM, as > >> well as the output from “tc -d qdisc” before and after enabling SQM, > >> and finally the output of running “/etc/init.d/sqm stop ; > >> /etc/init.d/sqm start” on the router’s console; that hopefully works > >> or at least gives some indication what might be off. If you could > >> throw in a quick netperf-wrapper RRUL test through the router I will > >> be most delighted ;)) > > > > Ok. That sounds like a good starter step. First question: Where are the > > current SQM scripts located and what's the process for installing them? > > Are they packages or stuff that I scp over and manually install? > > So the repository lives on: > https://github.com/dtaht/ceropackages-3.10 > I just followed Dave’s advice and used: > git clone g...@github.com:dtaht/ceropackages-3.3.git > to get my own version to play around with. Oh, SQM basically is the work of > Dave (who wrote the scripts doing the actual AQM&QOS work) and Toke you > packaged all this nicely and created the GUI for it (all I ever did was > shuffling the GUI around a bit). I just started hacking around the files from > sqm-scripts and luck-app-sqm on my cerowrt (so I could immediately do some > testing), so I never got around building actual packages (I assume you need > to be setup to build whole openwrt/cerowrt images and that is outside the > scope of my recreational coding), But that said if you copy the files from > ceropackages-3.10/net/sqm-scripts/files to the matching directory on your > router you should have a working sqm-script. Or just use a cerowrt built as > SQM is standard and potentially hnyman’s build ( > https://forum.openwrt.org/viewtopic.php?id=28392 ) that also includes SQM. > > Best Regards > Sebastian > > > > > I'll let you know when I've taken a stab at getting that working. > > > > > Richard A. Smith > > > Former One Laptop per Child > > > > Just FYI: I'm slowly swit
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi Jaime, maybe you should also look at the rror counters. Especially the CRC and HEC errors short before the connection drops might be interesting. Best Regards Sebastian On Nov 16, 2014, at 15:43 , Jaime T wrote: > On 15 November 2014 20:46, Michael Richardson wrote: >> How do you know it's not the DSLAM being unstable? > > Erm... I don't? I'm not sure what that means. Is there some way that I > can find out "from just my end" (the consumer end) of the connection? > I've called my ISP regarding the disconnections, and their response is > "Put our (supported) router back on, and we'll monitor the situation" > - I do that, and obviously the problem then disappears. I put my > Openwrt'd BTHOMEHUBV2B, and the problem starts again. Rinse, repeat... > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi Richard, hi Jaime On Nov 17, 2014, at 12:33 , Richard Mortimer wrote: > Hi, > > On 15/11/2014 10:40, Jaime T wrote: >> Hi all. >> >> I'm running "barrier breaker" (r42625) on a BTHOMEHUBV2B and it's >> great apart from frequent adsl disconnections (approx 40 per day). My >> adsl-type is POTS so the relevant part of /etc/config/network is: >> >> config adsl 'dsl' >>option annex 'a2p' >>option firmware '/lib/firmware/adsl.bin' >> >> Each disconnection puts approximately the following into the syslog: >> >> Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: No response to 5 >> echo-requests > > I think I saw something similar when I was using an ADSL connection. > > When the connection was under full load (I don't remember whether it was > upstream, downstream or both) the LCP echo requests that PPPD does seem > to get dropped somewhere in the ADSL infrastructure. The link is however > working fine passing "real" traffic. > > You can test this fairly easily by generating a lot of traffic that > lasts over 5 seconds and it will cause the connection to drop. Then try > increasing the lcp-echo-failure value in /etc/ppp/options and observing > whether the download continues after 5 seconds. After changing the pop values have a look at the output of “ps w” on the router, when I tried to p;ay with these from the luci GUI I noticed that pppd was called with lcp-echo-failure 5 while the GUI reported 0 (meaning unlimited), so something might be off in parsing/passing the arguments from the GUI. (Then again with my testing I nave managed to get pop session timeout even though packet captures indicated that under load some lcl echo requests went missing…) Best Regards Sebastian > > Gentoo have a patch that adds a lcp-echo-adaptive option to pppd. This > treats traffic receipt as equivalent to receiving an lcp echo-reply. > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/ppp/2.4.5/34_all_lcp-echo-adaptive.patch > > I did very briefly test with that patch and it seemed to work but I > moved onto another connection before I'd convinced myself that it really > was appropriate. > > Regards > > Richard > >> Fri Nov 14 09:33:41 2014 daemon.notice pppd[1218]: Serial link appears >> to be disconnected. >> Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: Connect time 28.9 minutes. >> Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: Sent 554487 bytes, >> received 6119357 bytes. >> Fri Nov 14 09:33:41 2014 daemon.notice netifd: Network device >> 'pppoa-wan' link is down >> Fri Nov 14 09:33:41 2014 daemon.notice netifd: Interface 'wan' has >> lost the connection >> Fri Nov 14 09:33:47 2014 daemon.notice pppd[1218]: Connection terminated. >> Fri Nov 14 09:33:47 2014 daemon.notice pppd[1218]: Modem hangup >> Fri Nov 14 09:33:58 2014 kern.warn kernel: [ 1832.784000] leave showtime >> Fri Nov 14 09:33:59 2014 daemon.info pppd[1218]: Terminating on signal 15 >> Fri Nov 14 09:33:59 2014 daemon.info pppd[1218]: Exit. >> Fri Nov 14 09:33:59 2014 daemon.notice netifd: Interface 'wan' is now down >> Fri Nov 14 09:34:27 2014 kern.err kernel: [ 1861.796000] >> [DSL_BSP_Showtime 894]: Datarate US intl = 924903, fast = 0 >> Fri Nov 14 09:34:27 2014 kern.warn kernel: [ 1861.80] enter >> showtime, cell rate: 0 - 2181, 1 - 2181, xdata addr: 0x82b0 >> Fri Nov 14 09:34:29 2014 daemon.notice netifd: Interface 'wan' is setting up >> now >> >> My line stats are: >> >> # /etc/init.d/dsl_control status >> Chipset:Ifx-Danube 1.3 >> Line State: UP [0x801: showtime_tc_sync] >> Data Rate: 7.040 Mb/s / 924 Kb/s >> Line Attenuation: 37.4dB / 21.2dB >> Noise Margin: 7.1dB / 10.0dB >> Line Uptime:25m 39s >> >> The disconnections happen more frequently at night time. I have >> several of these boxes, and they all exhibit the same behaviour so I >> do not believe that it is a hardware problem specific to 1 router. I >> also have the original "sky"-supplied router which does not suffer >> from these disconnections. >> >> The dsl connection appears to be a bit of a "black-box" - I can find >> very little documentation discussing it, although 1 or 2 people have >> mentioned XTU bits, which I don't understand. >> >> Is there anything that I can modify to try to stop these >> disconnections from happening? Would lowering the connection speed >> help, and if so, can this be done? >> >> All info/suggestions would be gratefully received. With kind regards, >> >> Jaime >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-d
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi Michael, On Nov 17, 2014, at 18:39 , Michael Richardson wrote: > > Richard Mortimer wrote: >> I think I saw something similar when I was using an ADSL connection. > >> When the connection was under full load (I don't remember whether it >> was upstream, downstream or both) the LCP echo requests that PPPD does >> seem to get dropped somewhere in the ADSL infrastructure. The link is >> however working fine passing "real" traffic. > > Sounds like the something a proper BQL limit on the etherne/ATM part of the > PPPoE coud fix. For PPPoE, traffic shapping should occur on the PPP > interface Note SQM does not care too much where you put the shaper,but if you shape one the pppoe device the pop maintenance packets are never seen by SQM so they will not be dropped. Shaping on the raw ATM device (in your case) should also work (never tested this myself as I have no open dsl-router), but almost all packets will end up in the default queue (I think) as the packet classification can not see through the pop encapsulation. Also if you want to go that route you shold make sure the PPP maintenance packets get their own highest priority queue… (as dropping enough of those will most likely drop your connection, luckily they do not cost a lot of bandwidth...) > and should probably run at no more than 99% of the real link > capacity (if you can determine it...sigh), In my limited experience the link speed as reported by the modem was always the correct brute link speed that SQM’s link layer adjustments could work with, so maybe just taking the values the modem part of your router reports and subtract say 3% on egress and 10% on ingress should be a decent starting point. > the LCP messages should bypass that part. Unless you shape on the ATM device ;) > DSL with the modem built-in ought to auto-adjust the bandwdth viaBQL > perfectly… For egress/upstream (I really hope we will get something like that in the future); bit for ingress/downlink you still need a properly configured shaper until the DSLAMs/MSANs/BRASs learn BQL fq_codel (which might take a while) Best Regards Sebastian > > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works| network architect > [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi Jaime, not an expert on adel modem errors, let alone lantiq, here is my attempt at helping out: On Nov 20, 2014, at 17:26 , Jaime T wrote: > On 17 November 2014 18:36, Sebastian Moeller wrote: >> Hi Jaime, >> maybe you should also look at the rror counters. Especially the CRC and HEC >> errors short before the connection drops might be interesting. >> Best Regards >>Sebastian > > Hi everyone. > > I've set lcp-echo-failure to "10" and lcp-echo-interval to "3" and I'm > still getting the disconnections. The logs fill with the following > now: > > Thu Nov 20 15:29:55 2014 kern.warn kernel: [15746.372000] leave showtime Ooops, the modem somehow lost ist DSL connection to the DSLAM > Thu Nov 20 15:29:56 2014 daemon.info pppd[7651]: Terminating on signal 15 > Thu Nov 20 15:29:56 2014 daemon.info pppd[7651]: Connect time 6.0 minutes. > Thu Nov 20 15:29:56 2014 daemon.info pppd[7651]: Sent 89186 bytes, > received 46470 bytes. > Thu Nov 20 15:29:56 2014 daemon.notice netifd: Network device > 'pppoa-wan' link is down > Thu Nov 20 15:30:01 2014 daemon.notice netifd: Interface 'wan' is now down > Thu Nov 20 15:30:11 2014 daemon.warn dnsmasq[1503]: no servers found > in /tmp/resolv.conf.auto, will retry > Thu Nov 20 15:30:24 2014 kern.err kernel: [15775.136000] > [DSL_BSP_Showtime 894]: Datarate US intl = 924903, fast = 0 > Thu Nov 20 15:30:24 2014 kern.warn kernel: [15775.14] enter > showtime, cell rate: 0 - 2181, 1 - 2181, xdata addr: 0x82e9 This looks like the modem just entered showtime (basically you can only transfer data in showtime, so the was a loss of the DSL link as well as the PPP link that sits on top of it) I would guess the DSL link went away from under the PPP connection so PPPD was forced to exit as well. > Thu Nov 20 15:30:26 2014 daemon.notice netifd: Interface 'wan' is setting up > now > Thu Nov 20 15:30:26 2014 daemon.info pppd[7835]: Plugin pppoatm.so loaded. > Thu Nov 20 15:30:26 2014 daemon.info pppd[7835]: PPPoATM plugin_init > Thu Nov 20 15:30:26 2014 daemon.info pppd[7835]: PPPoATM > setdevname_pppoatm - SUCCESS:0.38 > Thu Nov 20 15:30:26 2014 daemon.notice pppd[7835]: pppd 2.4.7 started > by root, uid 0 > Thu Nov 20 15:30:26 2014 daemon.info pppd[7835]: Using interface pppoa-wan > > Perhaps the "lcp echo request" thing just be a red herring caused by > the dsl link losing sync? I agree with that interpretation. > > I've also tried to find some info on how to get the error counters out > for the lantiq dsl connection (using dsl_cpe_control), and the best > info I can get hold of is: > > pmcctg 0 0 > nReturn=15 nChannel=0 nDirection=0 nElapsedTime=18031 bValid=1 > nCodeViolations=14662 nFEC=5910810 code violations are caused by CRC errors of transmitted packets, these require retransmission from sender to receiver (these are bad as they cost bandwidth). FEC is forward error correction (basically reed salomon code with potential interleaving of cells to spread out error bursts). The elapsed time I assume to be in seconds so ~5 hours … and 14662/18031 = 0.81 errors per second, quite a lot... > > pmdpctg 0 0 > nReturn=15 nChannel=0 nDirection=0 nElapsedTime=18058 bValid=1 > nHEC=10735 nTotalCells=256128475 nUserTotalCells=1896600 nIBE=0 > nTxUserTotalCells=0 nTxIBE=0 > > pmlsc1dg 0 0 > nReturn=15 nDirection=0 nHistoryInterval=0 nElapsedTime=58145 bValid=1 > nES=432 These are errored seconds a count of the seconds with CRC errors (multiple CRCs per second will just increase ES by one so it removes bursty errors to some degree from the statistics), if elapsed time is in seconds the ES accumulated inside of ~16 hours. > nSES=256 nLOSS=22 nUAS=2433 nLOFS=1868 SES means severely errored seconds (not sure how they are counted, but they typically increase way slower than ES), • UAS: Unavailable Seconds - Seconds where you had no sync (from http://en.wikipedia.org/wiki/G.992.1) this most likely is the culprit for your pop to go away. I do not know whether you can make pop wait long enough for your line to resync so your pppd disconnects would go away, but I also do not know whether your ISP would allow that since their PPPD also sees you go and might not allow to reconnect but enforce a new connection (I have no clue at all). Also I think you should try to improve the quality of the DSL link to make the PPP issue rare enough o just ignore it. > > The problem I now have is that I don't know how to interpret these > results: are they good, or bad? (And do they explain why I'm getting > dozens of disconnections every day?) I think they record your disconnects, but not necessarily tell you what caused the del link
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi Jaime,
On Nov 21, 2014, at 12:49 , Jaime T wrote:
> On 20 November 2014 20:49, Sebastian Moeller wrote:
>> Hi Jaime,
>> not an expert on adel modem errors, let alone lantiq, here is my attempt at
>> helping out:
>
> Hi Sebastien. Thank you for trying to help me - I appreciate it.
>
>>Maybe https://forum.openwrt.org/viewtopic.php?pid=222065 works for
>> you? Increasing the SNR ,arhin should make your link more resilient...
>
> Ok, I've just tried that, but I think that it's only returning an error code.
>
> locs 0 -20
> nReturn=-11
>
> The corresponding "getter" command ("locg") shows the following:
>
> locg
> Long Form: LineOptionsConfigGet
> Short Form: locg
>
> Input Parameter
> - DSL_LineOptionsSelector_t nConfigSelector (dec)
> DSL_OPT_NOISE_MARGIN_DELTA_DS = 0
> DSL_ERASURE_DECODING_TYPE_DS = 1
> DSL_TRUST_ME_BIT = 2
> DSL_INBAND_SPECTRAL_SHAPING_US = 3
>
> Output Parameter
> - DSL_Error_t nReturn
> - DSL_int32_t nConfigValue (dec)
>
> The other option selectors appear to work ok:
>
> locs 1 0
> nReturn=0
>
> locs 2 0
> nReturn=0
>
> locs 3 0
> nReturn=0
>
> I've also just found (in
> http://svn.dd-wrt.com/browser/src/router/dsl_cpe_control/include/drv_dsl_cpe_api.h)
> the following:
>
> /**
> 2782 Configuration of a target noise margin delta at the CPE, which
> is added to
> 2783 the target noise margin value configured atand received from the CO.
> 2784 The resulting value is then taken as target noise margin, e.g. for bit
> 2785 loading.
> 2786 The target noise margin delta ranges from -5 dB to +5 dB with
> 0.1 dB steps.
> 2787 \note API value -50 corresponds to -5 dB, 50 to 5 dB.
> 2788 \note This configuration option is only valid for Vinax. */
> 2789 DSL_OPT_NOISE_MARGIN_DELTA_DS = 0,
> 2790 /**
>
> so I guess this means that this option will never work. :-( All the
> other lantiq dsl commands which have the characters "snr" in them
> (such as
> g997dsnrg, g997sang and g997sansg) are all "getter" commands which
> return large blocks of data.
Too bad, would have been nice. Now I think that some of AVM’s fritzbox
routers are based on non-vinax lantiq SOCs and support setting SNR margin, but
the tool might be proprietary. But since I have o lantiq system available I can
not be of any help… sorry.
Best Regards
Sebastian
>
>>> If
>>> not, I'm going to have to buy a dsl modem with a broadcom chipset and
>>> use that instead…
>>
>>If you could buy such a modem you could test whether it really
>> improves things? If there is a massive source of RF ingress on your link
>> maybe another odem might not help much?
>
> I'm still confused by the fact that when I put the "Sky-supplied"
> SR102 router on the line, I don't get these disconnections. I think my
> only option now is to try a different modem...
>
> Thank you for all your help! With kind regards, Jaime
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SQM QOS Feedback and configuration questions
Hello Derek, Thanks for trying SQM. On Dec 28, 2014, at 03:29 , Derek & Vicky wrote: > I've installed and configured the SQM QOS module for my Bleeding Edge, r43718 > access point. The access point runs on the sunxi A20 processor with 1 > Ethernet and 1 USB powered Wifi adapter. A 5 port switch with VLAN 802.1q > support is connected to the 1 Ethernet port to give the access point extra > wired network ports. > > I was looking for configuration documentation for this module that would > guide the basic configuration options. So for the basic setup http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310 should be interesting. This was written for cerowrt, but with the exception of the interface names this should also apply to openwrt. It should explain some of the options a bit better. > The module has advanced options too, but I assume that they are for specific > setups to get the extra bit of performance. The idea/hope for SQM scripts was to get a default that works for everybody; I am not sure whether we fully reached that goal. > Particular documentation for what interface to enable the SQM QOS for? (Wifi? > Ethernet connected to the WAN?) Will this still work if the broadband > provider equipment is not in bridge mode? So, SQM scripts can be configured on multiple interfaces concurrently, so it depends on your specific topology; in general one would configure & active SQM for the interface connected to the upstream (typically the ISP). Bridged or not bridged should not make a big difference, though I have not tested that myself (cerowrt routes all interfaces instead of bridging them). But most people configure SQM for their internet access on the WAN port of the “first” router (better the router that feeds all other network nodes). Now as far as I can tell even openwrt does not bridge the “WAN” port with the rest. > > > Lastly for the Download speeds and Upload speeds what is the recommended way > to calculate the values to enter? 90% of DSL connection speed? Or 95% of > real observed/tested speeds(like tested with iperf)? That depends on how much time you want to invest here, many people are quite happy with setting the uplink/egress to 95% of the line rate and downlink/ingress to 90% of line rate; but you should definitively measure the effect of the selected shaping rates on the latency under load: https://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat has some pointers on how to measure this, personally I would recommend the netperf-wrapper suite (which also works great with internal nerserver instances). NOTE on a ADSL link you really should fill out the “Link Layer Adaptation” tab with the proper values (select ATM for “Which link layer to account for:"). (The wist case for the overhead in theory seems to be 48 bytes and in real life 44 bytes). If you are unsure whether your link runs ATM let me know I have a quite time consuming method to detect ATM framing (and overhead) if you can not get the relevant information from your ISP. The link layer adjustments are critical for ATM-based links as the link rates the modem reports are net rates and ATM drags in a lot of overhead (partly depending on the size of the current packet) that will need to fit into the net rate (ATM's 48 in 53 encapsulation alone eats up ~9% of the net link rates), so if you you do not use the link layer adjustments starting values are 85% and 80% of link rates. If you have enough time the bet approach is then to measure the performance of your link under load, for netperf-wrapper I use: date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv4 -l 300 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t your_fancy_name_for_plots_and_files_replace_this And then I use “netperf-wrapper —gui” to look at the results (the icmp_cdf, ping_cdf, all_scaled, and box_totals plots are quite helpful in my experience). > > My initial test results indicate that the QOS does work, not sure how well. > My test case was a huge upload over about 4 hours, most likely over https. > The DSL upload speed is 1Mbps, download 9Mbps. Ah, for that upload speed it should help to set “Latency target for egress, e.g. 5ms [units: s, ms, or us]; leave empty for default, or auto for automatic selection.” to “auto” in the “Show Dangerous Configuration” subsection of the “Show Advanced Configuration” subsection of the "Queue Discipline” tab. Rationale: fq_codel typically considers a flow not “congested” if in an interval of 100ms no packet is longer held in the queue than 5ms (called target) but at speeds < 3 Mbps a single packet takes longer than 5ms and hence fq_codel will keep dropping packets from flows even though they are not really experiencing congestion but just a slow link ;). “Auto” will basically look at the configured shaped rate and set targe
Re: [OpenWrt-Devel] [Cerowrt-devel] [sqm-scripts] not started at boot?
Hi Toke,
On Feb 15, 2015, at 16:00 , Toke Høiland-Jørgensen wrote:
> Alan Jenkins writes:
>
>> It's very effective, but I notice SQM isn't applied at boot time. The
>> system log complains about pppoe-wan interface not existing, when the
>> sqm init script is started.
>
> Ah, that makes sense I suppose: PPPOE is probably brought up too late
> for the SQM init script to pick it up.
>
>> qos-scripts has a hotplug script, so I copied it for sqm and the
>> problem is "fixed". Though my stupid script re-runs the sqm as every
>> single network interface comes up, so it spams the log and probably
>> slows things down a bit. (Maybe sqm script also wants to not be so
>> noisy in the log)
>
> I'm attaching an updated version of the run.sh script which should
> detect when it is run from hotplug and only apply the SQM config to the
> hotplugged interface. Could you verify that this works for you? If so,
> I'll push an update with the revision and include a hotplug script. :)
I am not sure that this works as intended. The first thing run.sh does
is take down all running SQM instances:
PROTO_STATE_FILE_LIST=$( ls ${ACTIVE_STATE_FILE_DIR}/${ACTIVE_STATE_PREFIX}* 2>
/dev/null )
for STATE_FILE in ${PROTO_STATE_FILE_LIST} ; do
if [ -f ${STATE_FILE} ] ;
then
STATE_FILE_BASE_NAME=$( basename ${STATE_FILE} )
CURRENT_INTERFACE=${STATE_FILE_BASE_NAME:${#ACTIVE_STATE_PREFIX}:$((
${#STATE_FILE_BASE_NAME} - ${#ACTIVE_STATE_PREFIX} ))}
logger -t SQM -s "${0} Stopping SQM on interface: ${CURRENT_INTERFACE}"
/usr/lib/sqm/stop.sh ${CURRENT_INTERFACE}
rm ${STATE_FILE}# well, we stop it so it is not running anymore
and hence no active state file needed...
fi
done
before diving into the individual coin fig sections. And all instances that
were stopped better be restarted unless their configuration changed. (The
current SQM scripts allow multiple concurrent active instances,it would be nice
to keep that capability).
Best Regards
Sebastian
>
> -Toke
>
#!/bin/sh
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# Copyright (C) 2012-4 Michael D. Taht, Toke Høiland-Jørgensen, Sebastian Moeller
. /lib/functions.sh
STOP=$1
ACTIVE_STATE_PREFIX="SQM_active_on_"
ACTIVE_STATE_FILE_DIR="/var/run/SQM"
mkdir -p ${ACTIVE_STATE_FILE_DIR}
# the current uci config file does not necessarily contain sections for all interfaces with active
# SQM instances, so use the ACTIVE_STATE_FILES to detect the interfaces on which to stop SQM.
# Currently the .qos scripts start with stopping any existing traffic shaping so this should not
# effectively change anything...
PROTO_STATE_FILE_LIST=$( ls ${ACTIVE_STATE_FILE_DIR}/${ACTIVE_STATE_PREFIX}* 2> /dev/null )
for STATE_FILE in ${PROTO_STATE_FILE_LIST} ; do
if [ -f ${STATE_FILE} ] ;
then
STATE_FILE_BASE_NAME=$( basename ${STATE_FILE} )
CURRENT_INTERFACE=${STATE_FILE_BASE_NAME:${#ACTIVE_STATE_PREFIX}:$(( ${#STATE_FILE_BASE_NAME} - ${#ACTIVE_STATE_PREFIX} ))}
logger -t SQM -s "${0} Stopping SQM on interface: ${CURRENT_INTERFACE}"
/usr/lib/sqm/stop.sh ${CURRENT_INTERFACE}
rm ${STATE_FILE} # well, we stop it so it is not running anymore and hence no active state file needed...
fi
done
config_load sqm
run_simple_qos() {
local section="$1"
export IFACE=$(config_get "$section" interface)
# If called from hotplug, $DEVICE will be the interface that got hotplugged, so ignore anything else
[ -n "$DEVICE" -a "$DEVICE" != "$IFACE" ] && return
ACTIVE_STATE_FILE_FQN="${ACTIVE_STATE_FILE_DIR}/${ACTIVE_STATE_PREFIX}${IFACE}" # this marks interfaces as active with SQM
[ -f "${ACTIVE_STATE_FILE_FQN}" ] && logger -t SQM -s "Uh, oh, ${ACTIVE_STATE_FILE_FQN} should already be stopped." # Not supposed to happen
if [ $(config_get "$section" enabled) -ne 1 ];
then
if [ -f "${ACTIVE_STATE_FILE_FQN}" ];
then
# this should not be possible, delete after testing
local SECTION_STOP="stop" # it seems the user just de-selected enable, so stop the active SQM
else
logger -t SQM -s "${0} SQM for interface ${IFACE} is not enabled, skipping over..."
return 0 # since SQM is not active on the current interface nothing to do here
fi
fi
export UPLINK=$(config_get "$section" upload)
export DOWNLINK=$(config_get "$section" download)
export LLAM=$(config_get "$section" linklayer_adaptation_mechanism)
export LINKLAYER=$(config_get "$section" linklayer)
export OVERHEAD=$(config_get "$section&qu
Re: [OpenWrt-Devel] [Cerowrt-devel] [sqm-scripts] not started at boot?
Hi Toke,
On Feb 15, 2015, at 16:56 , Toke Høiland-Jørgensen wrote:
> Sebastian Moeller writes:
>
>> I am not sure that this works as intended. The first thing
>> run.sh does is take down all running SQM instances:
>
> Ah yes, seems I was a bit too trigger-happy there ;)
>
> Here's a version of run.sh that should also short-circuit the 'down'
> part if called from hotplug.
>
> The alternative is, of course, to have logic in the hotplug script to
> only call run.sh for interfaces that are enabled, but that would require
> parsing /etc/config/sqm from there. My initial thought was that
> short-circuiting the logic in run.sh was 'cleaner'; but I'm not entirely
> sure about that... Thoughts?
Not that I have shown great taste in the past, but I think it would be
somewhat cleaner to put the logic into the hot plug script and keep run.sh
“simple” (in the past I had introduced a large number of leakage, especially of
IFBs by not properly removing/stopping old instances and was quite happy to
have the take all active interfaces down loop as a last defense against
accidental leaks).
But I am now also running pppoe directly from cerowrt and see the same
issue, sqm is confused when the pppoe interface temporarily goes away, so at
least I can now test this issue ;)
Best Regards
Sebastian
>
> -Toke
>
#!/bin/sh
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# Copyright (C) 2012-4 Michael D. Taht, Toke Høiland-Jørgensen, Sebastian Moeller
. /lib/functions.sh
STOP=$1
ACTIVE_STATE_PREFIX="SQM_active_on_"
ACTIVE_STATE_FILE_DIR="/var/run/SQM"
mkdir -p ${ACTIVE_STATE_FILE_DIR}
# the current uci config file does not necessarily contain sections for all interfaces with active
# SQM instances, so use the ACTIVE_STATE_FILES to detect the interfaces on which to stop SQM.
# Currently the .qos scripts start with stopping any existing traffic shaping so this should not
# effectively change anything...
PROTO_STATE_FILE_LIST=$( ls ${ACTIVE_STATE_FILE_DIR}/${ACTIVE_STATE_PREFIX}* 2> /dev/null )
for STATE_FILE in ${PROTO_STATE_FILE_LIST} ; do
if [ -f ${STATE_FILE} ] ;
then
STATE_FILE_BASE_NAME=$( basename ${STATE_FILE} )
CURRENT_INTERFACE=${STATE_FILE_BASE_NAME:${#ACTIVE_STATE_PREFIX}:$(( ${#STATE_FILE_BASE_NAME} - ${#ACTIVE_STATE_PREFIX} ))}
# If called from hotplug, $DEVICE will be the interface that got hotplugged, so ignore anything else
if [ -z "$DEVICE" -o "$DEVICE" == "$CURRENT_INTERFACE" ]; then
logger -t SQM -s "${0} Stopping SQM on interface: ${CURRENT_INTERFACE}"
/usr/lib/sqm/stop.sh ${CURRENT_INTERFACE}
rm ${STATE_FILE} # well, we stop it so it is not running anymore and hence no active state file needed...
fi
fi
done
config_load sqm
run_simple_qos() {
local section="$1"
export IFACE=$(config_get "$section" interface)
# If called from hotplug, $DEVICE will be the interface that got hotplugged, so ignore anything else
[ -n "$DEVICE" -a "$DEVICE" != "$IFACE" ] && return
ACTIVE_STATE_FILE_FQN="${ACTIVE_STATE_FILE_DIR}/${ACTIVE_STATE_PREFIX}${IFACE}" # this marks interfaces as active with SQM
[ -f "${ACTIVE_STATE_FILE_FQN}" ] && logger -t SQM -s "Uh, oh, ${ACTIVE_STATE_FILE_FQN} should already be stopped." # Not supposed to happen
if [ $(config_get "$section" enabled) -ne 1 ];
then
if [ -f "${ACTIVE_STATE_FILE_FQN}" ];
then
# this should not be possible, delete after testing
local SECTION_STOP="stop" # it seems the user just de-selected enable, so stop the active SQM
else
logger -t SQM -s "${0} SQM for interface ${IFACE} is not enabled, skipping over..."
return 0 # since SQM is not active on the current interface nothing to do here
fi
fi
export UPLINK=$(config_get "$section" upload)
export DOWNLINK=$(config_get "$section" download)
export LLAM=$(config_get "$section" linklayer_adaptation_mechanism)
export LINKLAYER=$(config_get "$section" linklayer)
export OVERHEAD=$(config_get "$section" overhead)
export STAB_MTU=$(config_get "$section" tcMTU)
export STAB_TSIZE=$(config_get "$section" tcTSIZE)
export STAB_MPU=$(config_get "$section" tcMPU)
export ILIMIT=$(config_get "$section" ilimit)
export ELIMIT=$(config_get "$section" elimit)
export ITARGET=$(config_get "$section" itarget)
export ETARGET=$(config_get "$section" etarget)
export IECN=$(config_get "$section" ingress_ecn)
export EECN=$(config_get "$section" egress_ecn)
Re: [OpenWrt-Devel] [Cerowrt-devel] [sqm-scripts] not started at boot?
Hi Alan, On Feb 15, 2015, at 15:39 , Alan Jenkins wrote: > Hi Toke > > I tried installing sqm-scripts from trunk, on Barrier Breaker on my wndr3800. > > It's very effective, but I notice SQM isn't applied at boot time. The system > log complains about pppoe-wan interface not existing, when the sqm init > script is started. > > My guess is it'd be the same even if my WNDR was running the base system from > trunk. Because the sqm scripts don't have nice integration like the qos > scripts package. > > Is that useful enough as a bug report? Do you need me to work on a proper > patch? > > qos-scripts has a hotplug script, so I copied it for sqm and the problem is > "fixed". Though my stupid script re-runs the sqm as every single network > interface comes up, so it spams the log and probably slows things down a bit. > I will see how it looks if the hot plug script decides more intelligently whether to call sqm or not, but I will need a few days due to unrelated deadlines... > (Maybe sqm script also wants to not be so noisy in the log) As far as I am concerned SQM is still on probation (in the openwrt repository) and has not seen sufficient testing, so the output is verbose to facilitate debugging of remote issues. I might be wrong though and all is well, and it can be toned down a lot... > > cat < /etc/hotplug.d/iface/10-sqm > #!/bin/sh > > # my sqm isn't being enabled on boot > # cargo-cult this hotplug script from qos-scripts > > [ "$ACTION" = ifup ] && /etc/init.d/sqm enabled && /usr/lib/sqm/run.sh > EOF I will, if you do not mind take this as starting point for a slightly more selective hot plug script… Best Regards Sebastian > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Cerowrt-devel] [sqm-scripts] not started at boot?
Hi Toke, hi Alan, On Feb 15, 2015, at 17:18 , Toke Høiland-Jørgensen wrote: > Sebastian Moeller writes: > >> Not that I have shown great taste in the past, but I think it >> would be somewhat cleaner to put the logic into the hot plug script >> and keep run.sh “simple” (in the past I had introduced a large number >> of leakage, especially of IFBs by not properly removing/stopping old >> instances and was quite happy to have the take all active interfaces >> down loop as a last defense against accidental leaks). > > Well, the biggest issue I can see with not having any logic in run.sh is > that in that case, *all* interfaces will be reconfigured when the > hotplug event happens. However, I'm not sure exactly how common it is to > have more than one interface configured for SQM, and if so, whether or > not reconfiguring everything on every hotplug event (well, only for for > SQM-enabled interfaces I suppose) is an issue. > > The modifications to run.sh should keep it functioning the way it does > currently if run 'manually' the shell or LUCI. Unless the $DEVICE > env-var is set for some other reason... > > >> But I am now also running pppoe directly from cerowrt and see >> the same issue, sqm is confused when the pppoe interface >> temporarily goes away, so at least I can now test this issue ;) > > Well, a first pass could be to see if the modified run.sh I sent last > time around actually works... ;) While I just had enough time to test this, and on my cerowrt 3.10.50-1 this (in addition to Alan’s hotplug script) does not seem to properly restart SQM over a pppoe reconnect. I will need to find a bit more time to figure out where I misconfigured my system as I expect I should be able to recreate Alan’s success. But this means it will take me even longer to try to improve SQM’s smarts about what to restart… Best Regards Sebastian > > -Toke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is PPPoE broken in Barrier Breaker?
Hi Valent, On Mar 25, 2015, at 15:54 , valent.turko...@gmail.com wrote: > Hahahaha, I'm so embarrassed :) And thank you very, very much! Don’t be embarrassed! But, please, post the resolution of your issue to the openwrt forum topic as well, so the solution is well documented for Google. A quick question, xdid you edit /etc/config/network by hand or did you use the luck GUI? Best Regards Sebastian > > On 25 March 2015 at 12:23, Yousong Zhou wrote: > Here is a link to this issue on the forum (it is not only me): > https://forum.openwrt.org/viewtopic.php?pid=269850 > > It looks like pppd after sending request for IP address instead > getting response with IP data instead package to terminate LCP is > received. Does somebody have ideas why is this happening? > I think the following line in that post more relevant here. rcvd [LCP ConfReq id=0x1 ] No auth is possible You may want to know the arguments passed to pppd on the command line with `ps ww | grep pppd`. Cheers, yousong >>> >>> >>> Thanks, I didn't mention but current ppp options are: >>> >>> # cat /etc/ppp/options >>> debug >>> logfile /tmp/ppp >>> noipdefault >>> defaultroute >>> noaccomp >>> nopcomp >>> nocrtscts >>> lock >>> maxfail 0 >>> lcp-echo-failure 15 >>> lcp-echo-interval 30 >>> lcp-restart 25 >>> pap-restart 25 >>> >>> and pppd starts with: >>> /usr/sbin/pppd nodetach ipparam ppp0 ifname pppoe-ppp0 nodefaultroute >>> usepeerdns persist maxfail 1 ip-up-script /lib/netifd/ppp-up >>> ipv6-up-script /lib/netifd/ppp-up ip-down-script /lib/netifd/ppp-dow >> >> No username or password is present on the command line. I Just saw >> your update on the forum post. You need to specify username with the >> option "username", not "user". That should be it. >> >> Cheers. >> >>yousong > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?
Thanks for the update. On October 11, 2019 12:59:04 PM GMT+02:00, Jo-Philipp Wich wrote: >Hi Bjørn, > >> Or: Start discussing the release blockers here and now. Thanks. > >1) Blocker: LuCI master needs to be backported to 19.07 > Time estimate: 2-3 weeks > >2) Blocker: All relevant sub-components for WPA-3 + GUI support, such >as > hostapd, iwinfo etc. need to be backported to 19.07 > Time estimate: 2 weeks > >3) Blocker: Some weaknesses in libustream-ssl client certificate > handling need to be addressed, which can only be solved by an API > redesign. Band-aid fixes available but not merged, nobody worked > on API redesign yet > Time estimate: 1 week > >4) Blocker: Need to assert the state of the Dragonblood WPA3 > vulnerabilities in 19.07's hostapd > Time estimate: a few days I guess Question: How long would it take to stabilize/test a fresh fork from today's Master branch instead? I assume none of these issues apply to master or need to be solved in master as well? Best Regards Sebastian > >~ Jo > >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?
> On Oct 16, 2019, at 21:54, Jo-Philipp Wich wrote: > > Hi, > >> Does it impact OpenWrt ? or just some OpenWrt based distributions ? >> (might influence who need to fix this ;) ) > > it impacts the usage of the kmod compatibility repositories - apparently > they're completely ignored by opkg. > > This problem was reported in the forum by a user who was unable to > install openvpn-openssl on a 19.07 snapshot, due to the dependency on > kmod-tun. > > I was able to confirm the problem locally here as well. > While this might not strictly affect tagged builds, I still wouldn't > like to ship 19.07 with a known broken version of opkg. Silly question, does 18.6 have the same issue or is this a regression in relation to 18.6? Best Regards Sebastian > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Question regarding default qos_map_set (a5e3def1822431ef6436cb493df77006dbacafd6)
Dear Felix, with great joy did I notice that you enabled the qos_map_set feature of hostapd and supply a new default map that aligns OpenWrt's DSCP-2-AC mapping with RFC8325 Cimmit: a5e3def1822431ef6436cb493df77006dbacafd6 hostapd: add wmm qos map set by default This implements the mapping recommendations from RFC8325, with an update from RFC8622. This ensures that DSCP marked packets are properly sorted into WMM classes. The map can be disabled by setting iw_qos_map_set to something invalid like 'none' Signed-off-by: Felix Fietkau Which sets: set_default iw_qos_map_set 0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56 unraveling this gets us to (0 is coded as DSCP Exception, the rest as DSCP ranges): UP DSCPAC PHBs(decDSCP) Ex0 BE BE(0) BE/CS0(0) Range0 2-16BE CS1(8)**, AF11(10), AF12(12), AF13(14), CS2(16) Range1 1-1 BK LE(1) Range2 - Range3 18-22 BE AF21(18), AF22(20), AF23(22) Range4 24-38 VI CS3(24), AF31(26), AF32(28), AF33(30), CS4(32), AF41(34), AF42(36), AF43(38) Range5 40-40 VI CS5(40) Range6 44-46 VO EF(46) Range7 48-56 VO CS6(48), VA(54), CS7(56) **) This used to be in AC_BK but LE is the new CS1 ;) (I think this changes is justified, as in the past Comcast was reported to inject lots of CS1 marked packets into leaf networks without CS1 actually denoting background/lower effort). My questions for this map now are: a) why the incomplete coverage of the 6bit DSCP value range? This mapping leaves out DSCPs 17, 23, 39, 41-43, 47, 57-63 completely, which is odd (I assume these will map to UP_0 but am not sure). RFC8325 recommends to map all not explicitly mentioned DSCPs to UP0, which might allow a conceptually simpler qos_map_set setting all DSCPs to UP_0 and leveraging the up to 21 exceptions (see * below) for the relevant mappings of the named PHBs: 1,1,18,3,20,3,22,3,24,4,26,4,28,4,30,4,32,4,34,4,36,4,38,4,40,5,46,6,48,7,54,7,56,7,0,63,255,255,255,255,255,255,255,255,255,255,255,255,255,255 Which has 3 potentially desirable properties: 1) it makes the mappings of anything not AC_BE explicit 2)has no unexplained gaps and 3) follows RFC8325 recommendation to only map the enumerated PHBs. On the other hand it clearly is longer and untested (my router is still on too old an OpenWrt version for qos_map_set to be supported I think) and it assumes that exceptions will get evaluated and honored even if the UP range is set to 255/255. What do you think? Best Regards Sebastian P.S.: I am 100% certain that RFC8325's recommendations were actually tested under mildly adverse real life conditions (I would guess that was tested in clean enterprise WiFi environments with appropriate admission control), EF markings are not super rare and putting these in AC_VO can pummel throughput in lower ACs to some degree (if there is more than the occasional EF packet). *) ### hostapd/wpad qos_map # QoS Map Set configuration # # Comma delimited QoS Map Set in decimal values # (see IEEE Std 802.11-2012, 8.4.2.97) # # format: # [,],... # # There can be up to 21 optional DSCP Exceptions which are pairs of DSCP Value # (0..63 or 255) and User Priority (0..7). This is followed by eight DSCP Range # descriptions with DSCP Low Value and DSCP High Value pairs (0..63 or 255) for # each UP starting from 0. If both low and high value are set to 255, the # corresponding UP is not used. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Query regd. rw rootfs
Not that I would know, being a user not a developer > On Jun 16, 2022, at 13:33, Ravi Paluri (QUIC) > wrote: > > Hi jo, > >>> it is not the same. There is no special handling for specific overlay file >>> paths in procd. > If the behavior is not same, can you let me know how "below" is > handled/taken care in OpenWRT? > "changes made to sensitive files for e.g. /etc/passwd (deleting a line. > Deleting passwd file etc.) will have adverse impact on security and some init > scripts may not start etc." How can you implement user-changeable passwords without actually changing /etc/passwd in a way that "survives" a reboot? And similar for all other configuration changes that are expected by the user to be persistent... Yes, this probably means a user with root and or physical access to a router will likely be able to brick it and compromise its security (e.g. by unfortunate configuration changes or installation of insecure software packages). I guess what I am asking what is your threat model here? Regards Sebastian > > Thanks, > Ravi > > -Original Message- > From: openwrt-devel On Behalf Of > Jo-Philipp Wich > Sent: Thursday, June 16, 2022 3:54 PM > To: openwrt-devel@lists.openwrt.org > Subject: Re: Query regd. rw rootfs > > WARNING: This email originated from outside of Qualcomm. Please be wary of > any links or attachments, and do not enable macros. > > Hi, > >> [...] >> Is this behavior the same with procd? > > it is not the same. There is no special handling for specific overlay file > paths in procd. > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? Regards Sebastian *) Not sure where I got that impression from > On Sep 7, 2022, at 23:48, Jo-Philipp Wich wrote: > > Hi Rich, > > that tutorial is good ground work imho. One thing I repeatedly noticed (not in > the document, but in forum and irc chatter) is that over the time, DSA and > bridge VLAN filtering became conflated into one concept while they're actually > different pieces; one can do bridge VLAN filtering without DSA and one can > utilize DSA without doing bridge VLAN filtering. > > Bluntly speaking, DSA is the thing that gives you one Linux network device per > switch port and bridge VLAN filtering is the stuff that allows you declaring > swconfig-esque VLAN port groups on top of an arbitrary bridge interface. > > I think this is something we should try to better convey in the documentation. > > For example simple common use cases like: > > - Making each switch port it's own independent interface with own subnet > > or > > - Break out one switch port to turn it into some kind of restricted IoT or > guest network access port > > or > > - Bridge each ethernet port to another SSID > > don't require bridge VLAN filtering or touching VLANs in general at all (in > contrast to former swconfig). The per-port net devices just have to be taken > out of the br-lan bridge and either be put into another bridge or configured > as independent network devices. > > Bridge VLAN filtering on the other hand is only actually needed if you want to > deal with VLAN tagged traffic inside the bridge. And even then there's > sometimes alternative ways, for example the following two scenarios should be > functionally equivalent: > > - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" > - VLAN filtering disabled > > vs. > > - Bridge device "br-lan" containing "lan1 lan2 lan3" > - VLAN filtering enabled > - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged > - VLAN device br-lan.10 on top of br-lan > > > In the former case you would put your IP address settings onto the dedicated > "br-vlan10" bridge device while in the latter case you would configure the IP > addressing on the "br-lan.10" subinterface of the "br-lan" bridge. > > So maybe it makes sense to focus on the "with DSA, your switch just becomes a > linux bridge over a bunch of netdevs" aspect in the mini tutorial and break > out any bridge-VLAN related information into a separate advanced VLAN > tutorial. > > Another conceptual issue I see is that people came to expect a dedicated > "switch" configuration ui which is something that does not really work with > DSA devices anymore since there is no dedicated switch hardware entity to > interact with anymore (DSA takes care of completely abstracting this away from > the user point of view) and that bridge-vlans just happen to be a > configuration detail of a bridge, and that there happens to be a bridge > "br-lan" by default, but a system could have multiple bridges, or none at all. > > So we should also explain why there is no central "switch configuration" > anymore and that this does not translate into a loss of functionality, but > that the former semi opague swconfig switch configuration entity was dissolved > into a bunch of ethernet devices inside a bridge... > > > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Help untangling CAKE settings for FTTH
HI T. > On Nov 16, 2022, at 11:22, Thibaut wrote: > > Hi, > > A few questions for the CAKE experts here: Quick note, this is not necessarily the best place to get advice on cake, both the cake mailing list and the OpenWrt forum tend to be directer paths to the "bakers". > > I’m trying to untangle the information available in the openwrt wiki: > https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm > https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details > and for the latter especially the part here: > https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#sqmlink_layer_adaptation_tab > > For ADSL/VDSL, I believe the instructions are clear and the Luci interface is > too. However for ethernet/fiber, I’m confused: > > In the first list of this paragraph it is first suggested to use « Ethernet > with overhead » and set the per-packet overhead to 44 for FFTH (which seems > like a large value for this use case), That is the point here, 44 is a value that in all likelihood is >= any realistic true overhead. Gently over-estimating the true overhead has a relative small cost in potential throughput, underestimating the overhead however can result in noticeable degradation of responsiveness under working conditions, so the recommendation is to rather err on the side of too large an overhead and not too small an overhead. Why not simply recommend the worst case scenario `overhead 44 atm` to be on the safe side on all links? Because the ATM/AAL5 encapsulation is only used on ADSL links (so is getting rarer and rarer and the ATM encapsulation results in a >=9% throughput reduction on non-ATM links, which is IMHO too steep a price... plus the ATM/AAL5 encapsulation size in addition also depends on the packet size so not a reasonable default in a world where ATM-usage is on the way out. > then later in the second list (« the details »), it is suggested to use « > None », directly contradicting the above. Are you referring to: • None: Fiber, and direct Ethernet connections generally do not need any kind of link layer adaptation. Well, I am kidding, all shaping below the physical gross-rate requires correct per-packet overhead accounting, but for fiber and ethernet it is much harder to figure out the exact overhead to specify… (the question is typically how is the ISP's upstream traffic shaper configured). For true ethernet shaping without VLANs specify 38 bytes (mpu 84). I was under the impression that the "Well, I am kiddung" part was clear enough, no? > The 44 byte overhead for ethernet/FTTH is also mentioned here: > https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm > > More specifically, there are two (increasingly common I think) use cases I > would like to document with your help: > > - FTTH with plain DHCP, no VLAN > - FTTH with PPPoE, no VLAN > (And adding a footnote for the extra overhead to consider if the above > include a VLAN tag) I am with you, I would like to have these settled as well, but alas FTTH is not terribly well defined as a technology. For active optical networks the encapsulation is likely ethernet framing, but for PONs like GPON and XGS-PON it is far less clear what needs to be accounted for. Yes with PON large parts of the ethernet framing overhead are replaced by a smaller GEM header, but how to account for the request-grant traffic and stuff... The good thing is that gently over-estimating the per-packet overhead only leads to a relative small reduction in maximal theoretical throughput, so `overhead 44` is still a decent recommendation even for FTTH. > In the latter case (FTTH with PPPoE), another point that needs to be > clarified is: do we apply CAKE to the ethernet interface, or to the PPP > interface? That is your choice... > (and I assume that depending on the answer, the overhead settings will have > to be adjusted). It used to yes, but cake is smart enough to get the size of the IP packet and add the overhead on top of that, so the overhead will not depend on whether you instantiate cake on say eth0 or on pppoe-wan (assuming pppoe-wan uses eth0). HOWEVER for simple.qos and simplest.qos it again matters... > Also in that case, what about ISPs that allow sending a full 1500 frame over > PPPoE (using 1508 MTU on the underlying ethernet interface)? SQM with cake does not care about that, it sees the IP packet size and adds the configured overhead. That wat cake also has no issue with GRO/GSO meta packets which can be up to 64KB in size abd still get accounted for correctly. Baby-jumbo frames from that perspective simply result in IP packet sizes > 1492. > > Thanks for your input, > T > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _
Re: Help untangling CAKE settings for FTTH
Hi T. > On Nov 16, 2022, at 12:46, Thibaut wrote: > > Hi Sebastian, > > Thanks for your reply. > >> Le 16 nov. 2022 à 11:49, Sebastian Moeller a écrit : >> >> HI T. >> >> >> >>> On Nov 16, 2022, at 11:22, Thibaut wrote: >>> >>> Hi, >>> >>> A few questions for the CAKE experts here: >> >> Quick note, this is not necessarily the best place to get advice on >> cake, both the cake mailing list and the OpenWrt forum tend to be directer >> paths to the "bakers". > > Well since this looked to me like an openwrt-specific question (with links to > openwrt wiki), it felt more adequate to ask here, but thanks for redirecting. Fair enough, however the OpenWrt wiki articles are often not written by the core developers (that use the devel mailing list) but by volunteer forum members. > >>> I’m trying to untangle the information available in the openwrt wiki: >>> https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm >>> https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details >>> and for the latter especially the part here: >>> https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#sqmlink_layer_adaptation_tab >>> >>> For ADSL/VDSL, I believe the instructions are clear and the Luci interface >>> is too. However for ethernet/fiber, I’m confused: >>> >>> In the first list of this paragraph it is first suggested to use « Ethernet >>> with overhead » and set the per-packet overhead to 44 for FFTH (which seems >>> like a large value for this use case), >> >> That is the point here, 44 is a value that in all likelihood is >= any >> realistic true overhead. Gently over-estimating the true overhead has a >> relative small cost in potential throughput, underestimating the overhead >> however can result in noticeable degradation of responsiveness under working >> conditions, so the recommendation is to rather err on the side of too large >> an overhead and not too small an overhead. >> Why not simply recommend the worst case scenario `overhead 44 atm` to be on >> the safe side on all links? Because the ATM/AAL5 encapsulation is only used >> on ADSL links (so is getting rarer and rarer and the ATM encapsulation >> results in a >=9% throughput reduction on non-ATM links, which is IMHO too >> steep a price... plus the ATM/AAL5 encapsulation size in addition also >> depends on the packet size so not a reasonable default in a world where >> ATM-usage is on the way out. > > I hear your argument, however the point here is that either we offer a « > single click » solution, As I tried to explain, we can not really do this as the only generally save configuration is too ugly. > and then we shouldn’t even bother allowing to tweak the 44 setting by default, Erm, one idea behind SQM was/is to configure sensible defaults, but allow users to override/change these. I take it you would like to see "overhead 44" as hard default? > or we allow customizing this value and then it seems logical to offer precise > guidance on how to do so, especially in the « detailed » section of the wiki. Well, it is a wiki, if you have robust and reliable information about a specific encapsulation feel free to add it to the respective page. > Currently we achieve neither IMHO, hence my initial email :) Again I respectfully disagree, https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm is pretty clear in its recommendations. I expect that people following the link to the details page will actually read that page before jumping to conclusions ;) Then again the details page has seen many small additions and changes and apparently is in need for a full editorial pass again. > >>> then later in the second list (« the details »), it is suggested to use « >>> None », directly contradicting the above. >> >> Are you referring to: >> >> • None: Fiber, and direct Ethernet connections generally do not need >> any kind of link layer adaptation. Well, I am kidding, all shaping below the >> physical gross-rate requires correct per-packet overhead accounting, but for >> fiber and ethernet it is much harder to figure out the exact overhead to >> specify… (the question is typically how is the ISP's upstream traffic shaper >> configured). For true ethernet shaping without VLANs specify 38 bytes (mpu >> 84). >> >> I was under the impression that the "Well, I am kiddung" part was clear >> enough, no? > > It wasn’t to me. A
Re: Help untangling CAKE settings for FTTH
Hi T. so taking your proposa under consideration I canged the section that threw you off course to read: • Ethernet with Overhead: SQM can also account for the overhead imposed by VDSL2 links - add 22 bytes of overhead (mpu 68). Cable Modems (DOCSIS) set both up- and downstream overhead to 18 bytes (6 bytes source MAC, 6 bytes destination MAC, 2 bytes ether-type, 4 bytes FCS), to allow for a possible 4 byte VLAN tag it is recommended to set the overhead to 18 + 4 = 22 (mpu 64). For FTTH the answer is less clear cut, since different underlaying technologies have different relevant per-packet-overheads; however underestimating the per-packet-overhead is considerably worse for responsiveness than (gently) overestimating it, so for FTTH set the overhead to 44 (mpu 84) unless there is more detailed information about the true overhead on a link available. • None: All shaping below the physical gross-rate of a link requires correct per-packet overhead accounting to be precise, so None is only useful if approximate shaping is sufficient, say if you want to clamp a guest network to at best ~50% of the available capacity or similar tasks, but even then configuring an approximate correct per-packet-overhead is recommended (overhead 44 (mpu 84) is a decent default to pick). I hope this is explicit enough. Regards Sebastian > On Nov 16, 2022, at 12:46, Thibaut wrote: > > Hi Sebastian, > > Thanks for your reply. > >> Le 16 nov. 2022 à 11:49, Sebastian Moeller a écrit : >> >> HI T. >> >> >> >>> On Nov 16, 2022, at 11:22, Thibaut wrote: >>> >>> Hi, >>> >>> A few questions for the CAKE experts here: >> >> Quick note, this is not necessarily the best place to get advice on >> cake, both the cake mailing list and the OpenWrt forum tend to be directer >> paths to the "bakers". > > Well since this looked to me like an openwrt-specific question (with links to > openwrt wiki), it felt more adequate to ask here, but thanks for redirecting. > >>> I’m trying to untangle the information available in the openwrt wiki: >>> https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm >>> https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details >>> and for the latter especially the part here: >>> https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#sqmlink_layer_adaptation_tab >>> >>> For ADSL/VDSL, I believe the instructions are clear and the Luci interface >>> is too. However for ethernet/fiber, I’m confused: >>> >>> In the first list of this paragraph it is first suggested to use « Ethernet >>> with overhead » and set the per-packet overhead to 44 for FFTH (which seems >>> like a large value for this use case), >> >> That is the point here, 44 is a value that in all likelihood is >= any >> realistic true overhead. Gently over-estimating the true overhead has a >> relative small cost in potential throughput, underestimating the overhead >> however can result in noticeable degradation of responsiveness under working >> conditions, so the recommendation is to rather err on the side of too large >> an overhead and not too small an overhead. >> Why not simply recommend the worst case scenario `overhead 44 atm` to be on >> the safe side on all links? Because the ATM/AAL5 encapsulation is only used >> on ADSL links (so is getting rarer and rarer and the ATM encapsulation >> results in a >=9% throughput reduction on non-ATM links, which is IMHO too >> steep a price... plus the ATM/AAL5 encapsulation size in addition also >> depends on the packet size so not a reasonable default in a world where >> ATM-usage is on the way out. > > I hear your argument, however the point here is that either we offer a « > single click » solution, and then we shouldn’t even bother allowing to tweak > the 44 setting by default, or we allow customizing this value and then it > seems logical to offer precise guidance on how to do so, especially in the « > detailed » section of the wiki. > > Currently we achieve neither IMHO, hence my initial email :) > >>> then later in the second list (« the details »), it is suggested to use « >>> None », directly contradicting the above. >> >> Are you referring to: >> >> • None: Fiber, and direct Ethernet connections generally do not need >> any kind of link layer adaptation. Well, I am kidding, all shaping below the >> physical gross-rate requires correct per-packet overhead accounting, but for >> fiber and ethernet it is much harder to figure out the exac
Re: Help untangling CAKE settings for FTTH
Hi Thibaut, > On Nov 17, 2022, at 15:22, Thibaut wrote: > > Hi Sebastian, > >> Le 17 nov. 2022 à 10:50, Sebastian Moeller a écrit : >> >> Hi T. >> >> >> so taking your proposa under consideration I canged the section that threw >> you off course to read: >> >> >> • Ethernet with Overhead: SQM can also account for the overhead imposed >> by VDSL2 links - add 22 bytes of overhead (mpu 68). Cable Modems (DOCSIS) >> set both up- and downstream overhead to 18 bytes (6 bytes source MAC, 6 >> bytes destination MAC, 2 bytes ether-type, 4 bytes FCS), to allow for a >> possible 4 byte VLAN tag it is recommended to set the overhead to 18 + 4 = >> 22 (mpu 64). For FTTH the answer is less clear cut, since different >> underlaying technologies have different relevant per-packet-overheads; >> however underestimating the per-packet-overhead is considerably worse for >> responsiveness than (gently) overestimating it, so for FTTH set the overhead >> to 44 (mpu 84) unless there is more detailed information about the true >> overhead on a link available. >> • None: All shaping below the physical gross-rate of a link requires >> correct per-packet overhead accounting to be precise, so None is only useful >> if approximate shaping is sufficient, say if you want to clamp a guest >> network to at best ~50% of the available capacity or similar tasks, but even >> then configuring an approximate correct per-packet-overhead is recommended >> (overhead 44 (mpu 84) is a decent default to pick). >> >> >> I hope this is explicit enough. > > Yes this looks a lot better, thank you. > > Although I must confess that it certainly feels counter-intuitive that for > ethernet (and FTTH) we suggest a higher overhead than e.g. VDSL2/cable (which > themselves run off an ethernet interface). That is simply because for (ADSL) DOCSIS VDSL2 we have a much clear picture about what we need to account for. And AON can be essentially using true ethernet encapsulation so we can expect an unspecified "FTTH" class to encompass a broad set of different encapsulations, if we want to recommend a single number that should also cover AON (the PONs are much less clear*). Why do you assume that FTTH necessarily would have a smaller per-packet-overhead than other link technologies? Now, if you have reliable information for say GPON-overhead, by all means add it (but to be useful this also should contain an easy identifier for other users to figure out whether they use GPON in the first place). The bigger point however is IMHO, from the perspective of minimizing bufferbloat/latency-under-load-increase using a slightly too large per-packet-overhead is fully benign, while specifying to small an overhead can easily result in measurable bufferbloat increase. So IMHO it is fine to err on the side of too large when estimating the per-packet-overhead. *) The core problem is that we have no straight forward way to empirically deduce the effective per-packet-overhead over an arbitrary network path, so if a link technology defines/documents the overhead well and conclusively (like docsis) we are in luck, but if the details a vague or leave many options to the ISP we have to make an educated guess. > I would also like to see some info about ppp vs ethernet interface in there > (matching your previous email): unless you beat me to it I will add it. I will not beat you to it, because for users of cake it does not matter and we do recommend to use cake in the first place... heck even for folks wanting to use HTB+fq_codel I would recommend to start with cake and then look at the output of `tc -s qdisc` to figure out the overhead that is already accounted for on an interface. > I also think the « details » page needs to be reformatted a bit, it’s very > dense and relevant info is all over the place and not very well organized. Might well be true (the page evolved over time and might need a full editorial pass), but it covers quite some territory and hence always will be a bit unwieldy. > I’ll try to get around improving that. Please try to keep all correct information around in the document. Good luck > > Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Help untangling CAKE settings for FTTH
Hi Thibaut, > On Nov 17, 2022, at 16:00, Thibaut wrote: > > > >> Le 17 nov. 2022 à 15:42, Sebastian Moeller a écrit : >> >> Hi Thibaut, >> >>> On Nov 17, 2022, at 15:22, Thibaut wrote: >>> >>> Hi Sebastian, >>> >>>> Le 17 nov. 2022 à 10:50, Sebastian Moeller a écrit : >>>> >>>> Hi T. >>>> >>>> >>>> so taking your proposa under consideration I canged the section that threw >>>> you off course to read: >>>> >>>> >>>>• Ethernet with Overhead: SQM can also account for the overhead imposed >>>> by VDSL2 links - add 22 bytes of overhead (mpu 68). Cable Modems (DOCSIS) >>>> set both up- and downstream overhead to 18 bytes (6 bytes source MAC, 6 >>>> bytes destination MAC, 2 bytes ether-type, 4 bytes FCS), to allow for a >>>> possible 4 byte VLAN tag it is recommended to set the overhead to 18 + 4 = >>>> 22 (mpu 64). For FTTH the answer is less clear cut, since different >>>> underlaying technologies have different relevant per-packet-overheads; >>>> however underestimating the per-packet-overhead is considerably worse for >>>> responsiveness than (gently) overestimating it, so for FTTH set the >>>> overhead to 44 (mpu 84) unless there is more detailed information about >>>> the true overhead on a link available. >>>>• None: All shaping below the physical gross-rate of a link requires >>>> correct per-packet overhead accounting to be precise, so None is only >>>> useful if approximate shaping is sufficient, say if you want to clamp a >>>> guest network to at best ~50% of the available capacity or similar tasks, >>>> but even then configuring an approximate correct per-packet-overhead is >>>> recommended (overhead 44 (mpu 84) is a decent default to pick). >>>> >>>> >>>> I hope this is explicit enough. >>> >>> Yes this looks a lot better, thank you. >>> >>> Although I must confess that it certainly feels counter-intuitive that for >>> ethernet (and FTTH) we suggest a higher overhead than e.g. VDSL2/cable >>> (which themselves run off an ethernet interface). >> >> That is simply because for (ADSL) DOCSIS VDSL2 we have a much clear >> picture about what we need to account for. And AON can be essentially using >> true ethernet encapsulation so we can expect an unspecified "FTTH" class to >> encompass a broad set of different encapsulations, if we want to recommend a >> single number that should also cover AON (the PONs are much less clear*). >> Why do you assume that FTTH necessarily would have a smaller >> per-packet-overhead than other link technologies? > > I’m not (necessarily) making that assumption for FTTH (although I would > expect it to be the case, from my limited understanding of FTTH technologies), Well, all I can say about encapsulations and per-packet-overhead is: it's complicated. > I am however certainly making that assumption for plain ethernet, which is > included in the 44-byte documentation case. I think it’s a reasonable one? Yes, the goal is to give one number that works everywhere so 44 is what we recommend. As I said overestimating the overhead is benign, underestimating it is not. True ethernet has an effective* per-packet-overhead of: 7 Byte Preamble + 1 Byte start of frame delimiter (SFD) + 12 Byte inter frame gap (IFG) + 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) 7 + 1 + 12 + 4 + 6 + 6 + 2 = 38 bytes Now if a VLAN tag is added you end up with 38+4 = 42 so both pure ethernet and ethernet+VLAN have a er-packet-overhead close to 44 bytes. *) The IFG is not real bytes, but transmission silence for the time it would take to transmit 12 octets. > >> Now, if you have reliable information for say GPON-overhead, by all >> means add it (but to be useful this also should contain an easy identifier >> for other users to figure out whether they use GPON in the first place). >> >> The bigger point however is IMHO, from the perspective of minimizing >> bufferbloat/latency-under-load-increase using a slightly too large >> per-packet-overhead is fully benign, while specifying to small an overhead >> can easily result in measurable bufferbloat increase. So IMHO it is fine to >> err on the side of too large when estimating the per-packet-overhead. > > OK. Although I would think people reading the detailed explanation are > looking for precise info and
Re: Help untangling CAKE settings for FTTH
Hi Thibaut, > On Nov 17, 2022, at 16:53, Thibaut wrote: > > Hi Sebastian, > >> Le 17 nov. 2022 à 16:19, Sebastian Moeller a écrit : >> >> Hi Thibaut, > > [...] >>>>> Although I must confess that it certainly feels counter-intuitive that >>>>> for ethernet (and FTTH) we suggest a higher overhead than e.g. >>>>> VDSL2/cable (which themselves run off an ethernet interface). >>>> >>>>That is simply because for (ADSL) DOCSIS VDSL2 we have a much clear >>>> picture about what we need to account for. And AON can be essentially >>>> using true ethernet encapsulation so we can expect an unspecified "FTTH" >>>> class to encompass a broad set of different encapsulations, if we want to >>>> recommend a single number that should also cover AON (the PONs are much >>>> less clear*). Why do you assume that FTTH necessarily would have a smaller >>>> per-packet-overhead than other link technologies? >>> >>> I’m not (necessarily) making that assumption for FTTH (although I would >>> expect it to be the case, from my limited understanding of FTTH >>> technologies), >> >> Well, all I can say about encapsulations and per-packet-overhead is: >> it's complicated. > > I can see that now :) > >>> I am however certainly making that assumption for plain ethernet, which is >>> included in the 44-byte documentation case. I think it’s a reasonable one? >> >> Yes, the goal is to give one number that works everywhere so 44 is what >> we recommend. As I said overestimating the overhead is benign, >> underestimating it is not. True ethernet has an effective* >> per-packet-overhead of: >> 7 Byte Preamble + 1 Byte start of frame delimiter (SFD) + 12 Byte inter >> frame gap (IFG) + 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src >> MAC) + 2 (ethertype) >> 7 + 1 + 12 + 4 + 6 + 6 + 2 = 38 bytes > > And now I’m even more confused: why do we suggest an overhead of 34/26 for > VDSL or 22 for docsis cable then? I assume the respective modems are > connected via ethernet, aren’t they? For DOCSIS you will be correct as there are no DOCSIS modem-routers that run OpenWrt, for DSL we do have some devices (older xrx200 and in development newer vrx518 lantiq/maxlinear SoCs) that actually have DSL interfaces. This is a bit of a judgement call, we only need to account for those overheads that actually happen on the bottleneck link of a path. For DSL/PTM the dsl overhead is smaller than the full ethernet overhead as some parts of ethernet encapsulation are not transmitted via the DSL link. So let's run the numbers for a router with gigabit ethernet port connected to a DSL modem with gigabit ethernet port. At what DSL rate will the added ethernet overhead actually matter and to save some time let's only look at the worst case of small packets (as there the relative overhead cost is larger): Ethernet max payload rate for minimal packet size: 1000 * ((64-18)/(64+20)) = 547.619047619 Mbps (true ethernet adds 20 bytes equivalent on top of the L2 ethernet frame) DOCSIS: (1000 * ((64-18)/(64+20))) * ((64)/(64-18)) = 761.904761905 Mbps Now use this payload rate to see how much raw DSL rate we would need to meet/exceed that rate: (1000 * ((64-18)/(64+20))) * (65/64) * ((64+4)/(64-18)) = 822.172619048 Mbps (PTM adds 4 bytes on top of the L2 ethernet frame https://en.wikipedia.org/wiki/Ethernet_frame) Currently VDSL2 is limited to ~250 Mbps, so we are far off from the true ethernet overhead becoming relevant for our traffic shaper. HOWEVER, if the link between router and modem is only 100 Mbps ethernet the picture changes, and indeed when using a 100 Mbps modem with a 100Mbps VDSL2 link I used `rate 95 overhead 50` (why 50 and not 34+20=54 you might ask? because on the link between modem and router I did not use a VLAN tag, but had the modem add this tag later). As I said, it's complicated. It is similar for DOCSIS, except there rates in the >= 1 Gbps range are a thing since some time already and unless rputer and modem use a 2.5/5/10/... Gbps connection the full ethernet overhead becomes relevant. Time to change the docsis recommendations for say rates > 500 Mbps. ADSL/ATM/AAL5 is essentially only used for speeds below 25 Mbps with devices with at least 100Mbps ethernet ports so let's ignore this for now: > > Another confusing point in the current detailed doc (and possibly the one > that got me started): > " • Link Layer Adaptation calculates the proper overheads for WAN links > such as DSL and ADSL. If you use any kind of DSL link, you should review this > section."
Re: [OpenWrt-Devel] [PATCH] lantiq: add dsl line_state mapping
Hi Florian, > On Jun 16, 2020, at 14:18, Florian Eckert wrote: > > Hi Adrian, > > thanks for your comment > >>> - "0xd00")s="resync" ;; >>> - "0x3c0")s="short init entry" ;; >>> - "") s="not running daemon"; ls="0xfff" ;; >>> - *) s="unknown" ;; >>> + "0x0") s="not initialized" >>> + n=1 ;; >> Wouldn't it be more user-friendly to just use the decimal number >> equivalent of the hex code? > > I've been thinking the same thing. > But then I have a problem when I want to display the values over time > (collectd/gravana). > From my point of view the distances are then too small or too large it does > not give equal gradations. I guess lantiq (or rather maxlinear nowadays) might introduce new hex codes into existing gaps which will cause a distruption of the nice monotonic order oc the enumerating decimals you went for. Is there no other data type in graphana that is ordered yet not scaled? Best Regards Sebastian > >>> - "0x100")s="test" ;; > > Especially the test value jumps out of line there. I think this is unlikely > and could be neglected, > but I would like to have a linear gradation. > > >>> - "") s="not running daemon"; ls="0xfff" ;; >>> - *) s="unknown" ;; >> Empty and error could be modelled with negative numbers then. > > We can still do that. So we have for "" and * the value -1 and -2. > > Best regards > > Florian > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 22.03.3 for mvebu (Turris Omnia)
MVEBU devices are not supported in kernel 5.10 based OpenWrt22.03.3 due to a bug. The fix is already in 5.15, but seems to intrusive to backport. Current snapshot builds are on kernel 5.15 already and the issue does not exist anymore. So the easy ways forward are: 1) stick to 22.03.2 2) switch (back) to turrisOS 6 (based on OpenWrt21, but with the fixed kernel 5.15) 3) simply use the typically pretty stable snapshots Regards Sebastian > On Feb 3, 2023, at 21:53, Mark Thurston wrote: > > The latest image available for Turris Omnia (mvebu) is 22.03.2 > (https://openwrt.org/toh/turris/turris_omnia). I was surprised to see 22.03.3 > is not available for this target. Is there anything that I can do to help > make a built 22.03.3 image available for general download? > > I'm happy to put in some legwork, if someone can point me in the right > direction (I'm new here). > > Bw > > Mark > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OT] Re: Additional container registry mirror [Was: Re: Sunsetting the Docker `openwrtorg` org (not `openwrt` org)]
> On Apr 15, 2023, at 10:19, Petr Štetiar wrote: > > Paul Spooren [2023-04-15 02:02:24]: > > Hi, > >> I’d simply disable it instead of no longer updating it, any other opinions? > > fine with me, thanks for taking care. I would simply announce it in several > places, that there is a plan to sunset that namespace in 3-6 months, thus > being nice and giving everyone some time to adjust their workflows. > > BTW I've recently experienced following from Hetzner.de ephemeral VPS in their > Helsinki DC with IP address within AS24940: > > WARNING: Failed to pull image with policy "if-not-present": Error response > from daemon: error parsing HTTP 403 response body: invalid character '<' > looking for beginning of value: "403 Forbidden\nSince > Docker is a US company, we must comply with US export control regulations. In > an effort to comply with these, we now block all IP addresses that are located > in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria. If you are > not in one of these cities, countries, or regions and are blocked, please > reach out to https://hub.docker.com/support/contact/\n\n" > (manager.go:237:1s) > > From docker.com support I've got a response, that they're using maxmind.com > service for this purpose and that Hetzner.de should fix that, but they don't > fully understand the situation and/or don't care. [SM] Given the known relatively high false-localisation rates of geoIP providers it is pretty concerning (to me) that these are now used to apparently trying to enforce the law. Mind you docker has to follow the laws and regulations, so my concern is to outsource the critical decision to a known imprecise entity. > > Anyway, I'm seeing more and more such issues recently with Cloudflare/GCP/AWS > as well, probably using similar IP flagging service, so perhaps we should > consider using some additional container registry as a backup/mirror? So if > the pull from one registry doesn't work, then folks could try a different one. > > I've not done any prior research about all viable options yet, but quay.io > looks so far as my favorite option. Any objections/ideas? > > Cheers, > > Petr > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: packet captures of sony's new 80Mbit service?
Hi Mark, > On Oct 11, 2023, at 21:05, Mark Thurston wrote: > > On Wed, 11 Oct 2023 18:04:41 +0100 Dave Taht wrote --- >> Anyone got a ps4 or ps5 and can take a packet capture at their router? >> Dying to know if it is cubic or bbr in particular >> > > Sorry if this is a silly comment but will all traffic not be encrypted? [SM] Yes, likely it will be. > Unless you've changed the certs on the PS, surely it won't be easy to do MITM > packet analysis of the content, only analysis of the approximate size? [SM] I guess the first question really is, is the data rate going to be constant or variable and what rate will be measurable on average... and will the quality be noticeably better. After all few users will pick an 80 Mbps service unless that is noticeably better than a 25 mbps service... I can hardly notice the difference between 1K and 4K resolution (on a 43inch display at 2-3 meter distance) so I would likely not notice or care, but I am not the core audience anyway ;) Regards Sebatian > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/8] Reduce skb truesize on common qdiscs under load
Hi Felix, On Oct 1, 2012, at 10:26 , Felix Fietkau wrote: > On 2012-10-01 6:49 PM, Dave Täht wrote: >> From: Dave Taht >> >> After queue lengths start getting out of hand, try to preserve memory >> by shortening skbs to their truesize on the common pfifo, codel, and >> fq_codel qdiscs. >> >> Arguably (128) should be a configureable param > I think this is a bad idea, at least on routers. 'Preserving memory' > here involves copying buffer data, which is really horrible for > performance. The memory bus is a tough bottleneck when routing at high > speed… But the in severe situations the alternative is OOM -> watchdog based reboot; under these circumstances limping along and recover later once the memory pressure is over sounds better than rebooting? (At least in cerowrt the OOM reboot cycle could be easily initiated by a simple UDP flood through the router. Now, while this is abusive, it is way better if the router survives this and recovers with out a reboot, IMHO). This change along with a few others Dave made turned cerowrt robust against UDP flooding which I think is the right thing to do. Since this only triggers once memory gets scarce, think of this as a defense mechanism in a situation where performance will suffer anyway... best Sebastian > > - Felix > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Evenly distribute bandwidth for users?
Hi there, On Jan 11, 2013, at 05:16 , Brian J. Murrell wrote: > On 13-01-11 07:29 AM, etienne.champet...@free.fr wrote: >> Hi >> >> http://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler > > Note that OP described wanting to distribute "download" bandwidth for > users. The document you posted above is about shaping "upload" bandwidth. > > As the above document states, one cannot really "shape" download > bandwidth but can only "police" it by dropping packets as they come in, > and then, that only works for TCP and not UDP. I wonder about whether that is actually right. Looking at the definitions of shaping and policing it is quite clear that in the real world any shaper will also police (and if only by virtue of limited buffers at one point packets will be dropped, turning a shaper into a policer). Adding a shaper to san ingress policer offers the following advantage: the developing queue, especially if the queueing is per flow or close to per flow (as in a number of different queueing disciplines available) will give the policing component more information to pick which packets to fro or mark. Thus in the real world shaping can be considered, as a fancy way of policing, so any shaper will fall back being a policer (worst case scenario all buffers are filled and a new packet arrives). Neither shapeing nor only policeing will be able to help against an inelastic UDP flood on the downstream. Especially if said flood consumes all link's bandwidth so even if the receiver drops all UDP packages no real traffic will make it through the bottleneck. This can only be solved on the head-end of the downstream; but inelastic UDP traffic is quite uncommon outside of DOS attacks, so this has nothing to do with the question of to shape or not to shape. Where shaping will help is if several (longer-running) TCP flows compete the downlink, then shaping can help to distribute the speeds of these individual flows to "fairly" share the downstream bandwidth (depending on your shaper setup and definition of fair). All of these facts (if actually) true seem to make the argument for using a shaper not a policer even on the remote end of a "bottle-neck" link like a typical cable/dsl/lte connection. Now, I could be just full of it, so please show me where my reasoning is off, and why policing is better than shaping. best Sebastian > > b. > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] tmpfs /tmp size how to change.
HI Pawel, On Dec 12, 2013, at 21:47 , Pawel Pastuszak wrote: > Hi, > > I am using pretty much the trunk version of openwrt and i want to adjust the > tmpfs /tmp size? I recall in old version of openwrt it was in > 10_essential_fs but the new version i cannot find it. > > Can someone point me to the correct direction. Probably not the canonical way, but I just added: # minimize the too large tmpfs (to avoid OOM), this is better handled by adding swap mount tmpfs /tmp -t tmpfs -o remount,size=16000k,nosuid,nodev to my /etc/rc.local to change size. Just replace the 16000k with your preference. This most likely is only effective after booting to to the stage of processing rc.local, but for my purposes that was enough… Best Sebastian > > Thanks, > Pawel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] report of sysupgrade incompatibility with mount-utils
Dear Developers,
I am a quite happy user of the cerowrt "fork" of openwrt. Cerowrt users noticed
some time ago that sysupgrade from the command line did not work anymore. We
found the root cause mount-utils. It turns out busy box's /bin/mount has
slightly different calling arguments than mount-utils /usr/bin/mount due to
which
Here is an example of the failure:
root@nacktmulle:~# sysupgrade -d 60 -n -v /tmp/3.10.21-1-sysupgrade.bin
killall: watchdog: no process killed
Sending TERM to remaining processes ... udhcpc lighttpd crond lighttpd snmpd
xinetd dbus-daemon odhcp6c zebra babeld watchquagga avahi-daemon rngd ntpd pimd
minissdpd dnsmasq sh ubusd askfirst netifd
Sending KILL to remaining processes ... ubusd askfirst
Switching to ramdisk...
mount: /proc is not a block device
umount: /tmp/root: not mounted
Failed to switch over to ramfs. Please reboot.
root@nacktmulle:~#
As you can see this did not work. After a reboot I removed the mount-utils
packet:
root@nacktmulle:~# sysupgrade -d 60 -n -v /tmp3.10.21-1-sysupgrade.bin
killall: watchdog: no process killed
Sending TERM to remaining processes ... udhcpc lighttpd crond lighttpd snmpd
xinetd dbus-daemon odhcp6c zebra babeld watchquagga avahi-daemon rngd ntpd pimd
minissdpd dnsmasq ubusd askfirst netifd
Sending KILL to remaining processes ... ubusd askfirst
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...
Writing from to firmware ...
Upgrade completed
So this works…
It turns out that /lib/upgrade/common.sh contains:
supivot() { #
mount | grep "on $1 type" 2>&- 1>&- || mount -o bind $1 $1
mkdir -p $1$2 $1/proc $1/sys $1/dev $1/tmp $1/overlay && \
mount -o noatime,move /proc $1/proc && \
pivot_root $1 $1$2 || {
umount -l $1 $1
return 1
}
mount -o noatime,move $2/sys /sys
mount -o noatime,move $2/dev /dev
mount -o noatime,move $2/tmp /tmp
mount -o noatime,move $2/overlay /overlay 2>&-
return 0
}
And this fails to mount /proc if /usr/bin/mount precedes /usr/bin/mount in the
path. So the workaround is to remove mount-utils before running sysupgrade, but
a better fix would be to make sysupgrade more robust, by simply replacing all
invocations of "mount" with "/usr/mount" or "busy box mount", unless
mount-utils is deprecated.
Best Regards
Sebastian Moeller
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] report of sysupgrade incompatibility with mount-utils
Hi John, On Dec 17, 2013, at 12:51 , John Crispin wrote: > On 17/12/13 12:49, Sebastian Moeller wrote: >> replacing all invocations of "mount" with "/usr/mount" > > > i think this would be the correct approach. So, should I send a patch? Against what version, or should I contact the maintainer (do you happen to know who that would be?) Best Regards Sebastian > > John > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] report of sysupgrade incompatibility with mount-utils
Hi John, On Dec 18, 2013, at 11:42 , John Crispin wrote: > On 18/12/13 11:41, Sebastian Moeller wrote: >> So, should I send a patch? Against what version, or should I contact >> the maintainer (do you happen to know who that would be?) > > Hi, > > that would be me, i will fix it after i had lunch Thank you very much! Best Regards Sebastian > > John > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v6] Add sysfixtime init script, replacement of luci_fixtime
Hi Etienne,
On Jan 6, 2014, at 13:01 , Etienne CHAMPETIER
wrote:
> Simply scan for the most recent file in /etc and set
> system time to this file modification time if it's in the future
> It allow some time dependent program to work immediatly
> without waiting for ntpd to sync
>
> v1: v2: bad approach
> v3: simply scan /etc, thanks to Bastian Bittorf for the idea
> v4: use sort -n, thanks to Catalin Patulea
> v5: use [] instead of [[]], thanks to Andreas Mohr
> v6: use openwrt style, thanks to Bastian Bittorf
>
> Signed-off-by: Etienne CHAMPETIER
> ---
> package/base-files/files/etc/init.d/sysfixtime | 13 +
> 1 file changed, 13 insertions(+)
> create mode 100755 package/base-files/files/etc/init.d/sysfixtime
>
> diff --git a/package/base-files/files/etc/init.d/sysfixtime
> b/package/base-files/files/etc/init.d/sysfixtime
> new file mode 100755
> index 000..525d765
> --- /dev/null
> +++ b/package/base-files/files/etc/init.d/sysfixtime
> @@ -0,0 +1,13 @@
> +#!/bin/sh /etc/rc.common
> +# Copyright (C) 2013-2014 OpenWrt.org
> +
> +START=00
> +
> +boot() {
> + local curtime="$(date +%s)"
> + local maxtime="$(find /etc -type f -exec date +%s -r {} \; | sort -nr |
> head -n1)"
I am probably way off, but if you would use /overlay/etc you would
avoid "stating" files not changed since install time?
best regards
Sebastian
> + [ $curtime -lt $maxtime ] && \
> + date -s @$maxtime && \
> + logger -t sysfixtime -p daemon.notice "Time fixed"
> +}
> +
> --
> 1.8.4.2
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v6] Add sysfixtime init script, replacement of luci_fixtime
Hi Stefan,
On Jan 6, 2014, at 15:06 , Stefan Hellermann wrote:
> Hi Sebastian,
>
> this would work only in case you're using squashfs, but there are others like
> jffs, ubifs and ext4 without overlay.
Ah, thanks for the explanation.
Best
Sebastian
>
> best regards,
> Stefan
>
>
> 2014/1/6 Sebastian Moeller
> Hi Etienne,
>
>
> On Jan 6, 2014, at 13:01 , Etienne CHAMPETIER
> wrote:
>
> > Simply scan for the most recent file in /etc and set
> > system time to this file modification time if it's in the future
> > It allow some time dependent program to work immediatly
> > without waiting for ntpd to sync
> >
> > v1: v2: bad approach
> > v3: simply scan /etc, thanks to Bastian Bittorf for the idea
> > v4: use sort -n, thanks to Catalin Patulea
> > v5: use [] instead of [[]], thanks to Andreas Mohr
> > v6: use openwrt style, thanks to Bastian Bittorf
> >
> > Signed-off-by: Etienne CHAMPETIER
> > ---
> > package/base-files/files/etc/init.d/sysfixtime | 13 +
> > 1 file changed, 13 insertions(+)
> > create mode 100755 package/base-files/files/etc/init.d/sysfixtime
> >
> > diff --git a/package/base-files/files/etc/init.d/sysfixtime
> > b/package/base-files/files/etc/init.d/sysfixtime
> > new file mode 100755
> > index 000..525d765
> > --- /dev/null
> > +++ b/package/base-files/files/etc/init.d/sysfixtime
> > @@ -0,0 +1,13 @@
> > +#!/bin/sh /etc/rc.common
> > +# Copyright (C) 2013-2014 OpenWrt.org
> > +
> > +START=00
> > +
> > +boot() {
> > + local curtime="$(date +%s)"
> > + local maxtime="$(find /etc -type f -exec date +%s -r {} \; | sort -nr
> > | head -n1)"
>
> I am probably way off, but if you would use /overlay/etc you would
> avoid "stating" files not changed since install time?
>
> best regards
> Sebastian
>
> > + [ $curtime -lt $maxtime ] && \
> > + date -s @$maxtime && \
> > + logger -t sysfixtime -p daemon.notice "Time fixed"
> > +}
> > +
> > --
> > 1.8.4.2
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
Hi John, On Jan 21, 2014, at 21:41 , John Crispin wrote: > > On 21/01/2014 21:35, James Cloos wrote: >>> "JC" == John Crispin writes: >> JC> * unit most likely runs on a ghz arm soc made by marvell >> >> IIRC, semiaccurate reported that it uses an atom processor. That truly was reported on semiaccurate.com as an atom part: http://semiaccurate.com/2014/01/06/linksys-wrt1900ac-spritual-successor-wrt54g/ (but later updated with a correction) >> >> -JimC >> -- >> James Cloos OpenPGP: 1024D/ED7DAEA6 > i beg to differ, please get your facts right :) Well, his facts were that semi accurate reported it as an atom, and they did. :) ahoy SM > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: ULA prefix lifetime
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Michael,
> On 20. Nov 2024, at 19:33, Michael Richardson wrote:
>
>
> chriss wrote:
>> I happens that I have to reconnect my VDSL (update of router, tripped over
>> cable, whatever) - with that I get a new IPv6 prefix delegated. Now my
>> clients have 2 prefixes/addresses. The old one (before the router
>
> :-(
> {Your ISP should avoid that kind of thing; IPv6 being plentiful there is no
> reason not to just statically allocate them all into the (radius) database,
> and just renumber people when there are major re-balancing.}
[SM] Some users actually desire an easy way to gain a new prefix, to make
tracking/being receiver of a DOS slightly harder. Like it or not, that is a use
case end customers demand and ISPs deliver... (ISPs also use this to
differentiate business type contracts that contain stable prefixes...)
>
>> Now my ULA addresses have also a lifetime of 5min - which is bad because
>> after 5 min of router downtime (update) I lose my local delivery between
>> clients.
>
>> My solution (to this very specific and edge case problem) would be to set a
>> large lifetime for ULA prefixes and use a short one for WAN delegated.
>
> That sounds like a good idea
> I'd also say that netifd/dnsmasq ought to automatically deprecate GUAs that
> go away when they are not renewed after a network outage.
[SM] I might be confused, but the issue is, OpenWrt not saving state
persistently the router has no idea which prefixes and GUAs are in use... I
guess (and I mean that this is pure speculation) the router could trap on GUAs
it has no upstream path for and serve a deprecation request to the GUA (not
even sure that is possible).
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: openwrt ONE: not getting enough PoE power
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi David, > On 15. Mar 2025, at 14:27, David Lang wrote: > > I think the concern being raised is why didn't it power itself via the USB > port even if the PoE was low. [SM] Thanks! Yes on re-reading the initial post, that is the (or at least one of the) issue(s). I have unfortunately nothing meaningful to add, except that indeed that is sub-optimal. > > Also, I don't have mine handy, but is the PoE module plugged in or soldered > in? I thought it was a plugin [SM] I believe these looked soldered, but I can not open mine right now... Regards & thanks again Sebastian > > David Lang > > On Sat, 15 Mar 2025, Sebastian Moeller via openwrt-devel wrote: > >> Date: Sat, 15 Mar 2025 10:15:37 +0100 >> From: Sebastian Moeller via openwrt-devel >> Reply-To: Sebastian Moeller >> To: openwrt-devel@lists.openwrt.org, Michael Richardson , >>openwrt-de...@openwrt.org >> Subject: Re: openwrt ONE: not getting enough PoE power >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: openwrt ONE: not getting enough PoE power
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi David, > On 15. Mar 2025, at 14:27, David Lang wrote: > > I think the concern being raised is why didn't it power itself via the USB > port even if the PoE was low. [SM] Thanks! Yes on re-reading the initial post, that is the (or at least one of the) issue(s). I have unfortunately nothing meaningful to add, except that indeed that is sub-optimal. > > Also, I don't have mine handy, but is the PoE module plugged in or soldered > in? I thought it was a plugin [SM] I believe these looked soldered, but I can not open mine right now... Regards & thanks again Sebastian > > David Lang > > On Sat, 15 Mar 2025, Sebastian Moeller via openwrt-devel wrote: > >> Date: Sat, 15 Mar 2025 10:15:37 +0100 >> From: Sebastian Moeller via openwrt-devel >> Reply-To: Sebastian Moeller >> To: openwrt-devel@lists.openwrt.org, Michael Richardson , >>openwrt-de...@openwrt.org >> Subject: Re: openwrt ONE: not getting enough PoE power >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: openwrt ONE: not getting enough PoE power
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Michael, my oldish zyxel PoE switch allows to limit the maximum current per port, maybe the Cisco in question does as well and is set for a borderline low value? Regards Sebastian On 15 March 2025 04:54:15 CET, Michael Richardson wrote: > >I brought an OpenWRT One to IETF122 Hackathon. > >I plugged the 2.5Gb/s port into the IETF hackathon network, and the switch >apparently has PoE (which I didn't care about). I hooked up the rest of the >cables, >including the USB power, but didn't turn it on yet. I was surprised when I >opened the console that the system was running kinda. > >With the cable in the PoE port, the device was in a reboot cycle. Getting to >just before the console shell starts, and then restarting. I can post a log >if that's useful to someone. >I guess because there wasn't enough amperage on the PoE port. I unpluged, >turned on the USB adapter and things were fine... so I reconnected the PoE >cable, and >the system crashed... back to reboot cycle! Oh. That's bad. > >I "solved" the problem by inserting a my non-PoE switch in between. >I could have also swapped ports, it now occured to me. > >I'm just mentioning this for the benefit for someone searching! > >I suppose this is a hardware problem, and probably not solveable. >Maybe I could cut a trace, or maybe there is a zero-ohm resister I could >unsolder to disable PoE. > >Maybe fixable in Two: prefer USB power if it's present. >But of course, when I started, it wasn't present, as I wanted the system to >be off until I was ready: I wanted to finish getting serial console alive >before I powered on. > >The switch in question: > >LLDP neighbors: >--- >Interface:enxd43a650cda24, via: LLDP, RID: 2, Time: 0 day, 00:25:46 > Chassis: >ChassisID:mac cc:98:91:86:53:80 >SysName: sw-128.meeting.ietf.org >SysDescr: Cisco IOS Software, C3560CX Software > (C3560CX-UNIVERSALK9-M), Version 15.2(7)E11, RELEASE SOFTWARE (fc3) > Technical Support: http://www.cisco.com/techsupport > Copyright (c) 1986-2024 by Cisco Systems, Inc. > Compiled Fri 23-Aug-24 13:34 by mcpre > >-- >] Never tell me the odds! | ipv6 mesh networks [ >] Michael Richardson, Sandelman Software Works| network architect [ >] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: openwrt ONE: not getting enough PoE power
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Michael, my oldish zyxel PoE switch allows to limit the maximum current per port, maybe the Cisco in question does as well and is set for a borderline low value? Regards Sebastian On 15 March 2025 04:54:15 CET, Michael Richardson wrote: > >I brought an OpenWRT One to IETF122 Hackathon. > >I plugged the 2.5Gb/s port into the IETF hackathon network, and the switch >apparently has PoE (which I didn't care about). I hooked up the rest of the >cables, >including the USB power, but didn't turn it on yet. I was surprised when I >opened the console that the system was running kinda. > >With the cable in the PoE port, the device was in a reboot cycle. Getting to >just before the console shell starts, and then restarting. I can post a log >if that's useful to someone. >I guess because there wasn't enough amperage on the PoE port. I unpluged, >turned on the USB adapter and things were fine... so I reconnected the PoE >cable, and >the system crashed... back to reboot cycle! Oh. That's bad. > >I "solved" the problem by inserting a my non-PoE switch in between. >I could have also swapped ports, it now occured to me. > >I'm just mentioning this for the benefit for someone searching! > >I suppose this is a hardware problem, and probably not solveable. >Maybe I could cut a trace, or maybe there is a zero-ohm resister I could >unsolder to disable PoE. > >Maybe fixable in Two: prefer USB power if it's present. >But of course, when I started, it wasn't present, as I wanted the system to >be off until I was ready: I wanted to finish getting serial console alive >before I powered on. > >The switch in question: > >LLDP neighbors: >--- >Interface:enxd43a650cda24, via: LLDP, RID: 2, Time: 0 day, 00:25:46 > Chassis: >ChassisID:mac cc:98:91:86:53:80 >SysName: sw-128.meeting.ietf.org >SysDescr: Cisco IOS Software, C3560CX Software > (C3560CX-UNIVERSALK9-M), Version 15.2(7)E11, RELEASE SOFTWARE (fc3) > Technical Support: http://www.cisco.com/techsupport > Copyright (c) 1986-2024 by Cisco Systems, Inc. > Compiled Fri 23-Aug-24 13:34 by mcpre > >-- >] Never tell me the odds! | ipv6 mesh networks [ >] Michael Richardson, Sandelman Software Works| network architect [ >] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
