[OpenWrt-Devel] ddns default config values broken?
Hi, i recently switched from using a wget-cronjob to ddns-scripts and luci-app-ddns. A couple of days ago i unplugged my router for a couple of minutes and today i found that my ddns entries where outdated. What happened was that the default 5 retries failed and the whole ddns service just died without my knowledge. I think the default number of retries should be infinite. With the current defaults a 5min connection loss will just make the script give up forever. One will have to log in and restart the service every time that happens. And even worse you might have to realize the problem the hard way, being away from home and not being able to figure out your IP. That default behaviour is probably not what most users would expect. My suggestion is to change the default of retry_count to 0. If that is not a good idea i would like to understand why. In case the reason are concerns about traffic/load or getting blocked by the provider, i would suggest exponential backoff instead of a fixed retry frequency. Let me know what you guys think. I will provide patches should we agree on changing that. Henning ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ddns default config values broken?
Hi Christian. Cool, let me know when your patch can be pulled. I also suggest to update the docs and luci to tell people about the risk of retry_count. Henning On Thu, 07 May 2015 22:16:52 +0200 Christian Schoenebeck christian.schoeneb...@gmail.com wrote: Hi Henning, thanks for you suggestions. I had to prepare a patch the next days anyway, so I will implement it. Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 2015-05-07 08:01, Wojciech Dubowik wrote: Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on readdir. As far as I remember with this patch it went through but I don't know anymore whether I have changed sth in config. Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for spi nor flash. Even with this patch I got some possible dead lock warnings so it might be just a partial cure. BTW it's a bit scary for future use. Looks like jffs2 doesn't get enough care... I believe the locking issues are an overlayfs regression, maybe even the same one as this one (which I fixed years ago): http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged I believe this is the cause of the regression: commit 49c21e1cacd74a8c83407c70ad860c994e606e25 Author: Miklos Szeredi mszer...@suse.cz Date: Sat Dec 13 00:59:42 2014 +0100 ovl: check whiteout while reading directory Don't make a separate pass for checking whiteouts, since we can do it while reading the upper directory. This will make it easier to handle multiple layers. Signed-off-by: Miklos Szeredi mszer...@suse.cz It probably happens like this: overlayfs does a readdir, in which jffs2 takes a lock. From within the readdir fill callback, it calls lookup_one_len, which ends up back in jffs2 and tries to take the same lock again. = deadlock. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 07/05/15 14:26, Heiner Kallweit wrote: [snip] Even with this patch I got some possible dead lock warnings so it might be just a partial cure. BTW it's a bit scary for future use. Looks like jffs2 doesn't get enough care... Regards, Wojtek Heiner Thanks for the hints! Because you mentioned that you have lots of problems with gianfar under 4.0: what kind of problems? I have got locking problems when using multiqueue on gianfar. I have no problems on 3.18. There is also reset issue on SGMII interface but if you are using TL-WDR4900 you have RGMII, so no problem. Wojtek Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ddns default config values broken?
Hi Henning, thanks for you suggestions. I had to prepare a patch the next days anyway, so I will implement it. Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] wrong configured spam-filter for openwrt-dev
AFAIK in kernel they make spam filter by forbidding html emails (just plaintext), wouldn't it be better to have it like that? On Fri, May 1, 2015 at 11:44 AM, edgar.sol...@web.de wrote: On 30.04.2015 12:48, Bastian Bittorf wrote: while sending a mail to openwrt-dev, i got this answer, which doesnt make any sense, because the list only accepts registered users anyway: openwrt-devel@lists.openwrt.org: host mail.openwrt.org[78.24.191.176] said: 554 5.7.1 Service unavailable; Client host [176.9.57.138] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?176.9.57.138 (in reply to RCPT TO command) so: first check, if the user is 'registered', if not ask do spamchecking. who feels responsible for that? inconvenient, true. but comprehensible as email has no sender verification, so anybody could write an email to the list and use your address in the FROM: field. ..ede ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Javier Domingo Cansino ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] xl2tpd in squash not recognized in Luci
Hello, please what can I do to recognize this package if it is in built in fw? I continuously have built images for tplink 842n, 1043nd, wdr3500 since half 2014 with package xl2tpd, but it was never recognized. Luci says install xl2tpd so I must remove package and install package again on every device. Thanks. -- S pozdravom Jakub Janco ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/4] kernel: mips jump only works with memory less then 256mb. when enable HIGHMEM use long jump
On 2015-05-07 04:25, wengbj wrote: Signed-off-by: wengbj fl.serv...@t-firefly.com This will make the code less efficient, I don't like that. Can't we just change the kernel code in the mips_module_reloc patch to enforce allocation within the lowmem memory space? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 06/05/15 21:23, Heiner Kallweit wrote:
Am 05.05.2015 um 22:17 schrieb Heiner Kallweit:
Am 05.05.2015 um 08:29 schrieb Wojciech Dubowik:
On 04/05/15 22:45, Heiner Kallweit wrote:
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
Gpio controller is now at fc00. See latest commit for
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi.
Regards,
Wojtek
PS. I have been also trying 4.0 but I have ran into so many problems with
gianfar that I have given it up.
For now...
Thanks. I face issues with the network as well and had to attach a serial
console + tftpboot to make it work again.
Back to 3.19.0 now ..
Heiner
I gave it one more try and replaced the gianfar driver from 4.0.1 with the one
from 3.19.0. Results:
- When rebooting first time after flashing the system (4.0.1) came up properly
and was reachable via network.
- After next reboot: system hangs
Booting the failing system with a serial console attached shows that after procd
-init- nothing happens.
I can log in via serial console. ps -ef showed that /etc/rc.d/S00sysfixtime was
hanging.
Checking the commands in this script manually I figured out that each access to
/etc/uci-default blocks the console.
Seems like the first start after flashing the system does something bad with
/etc/uci-defaults.
Or for whatever reason something can't deal properly with the empty
/etc/uci-defaults after the second boot.
No clue whom to blame ..
Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on
readdir. As far as I remember
with this patch it went through but I don't know anymore whether I have
changed sth in config.
Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for
spi nor flash.
Even with this patch I got some possible dead lock warnings so it might
be just a partial cure. BTW it's
a bit scary for future use. Looks like jffs2 doesn't get enough care...
Regards,
Wojtek
Heiner
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH procd] hotplug: support for interval commands
This allows executing code with a given interval. As every command, it
can be triggered by any uevent.
Intervals may be useful for counting elapsed time since some action. It
allows e.g. indicating that button has been pressed for some time and
can be already released.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
Example usage:
[ if,
[ and,
[ eq, SUBSYSTEM, button ],
[ eq, BUTTON, wps ],
[ eq, ACTION, pressed ],
],
[ set-interval, wpsbutton, 1000,
/etc/rc.button/%BUTTON% ]
],
[ if,
[ and,
[ eq, SUBSYSTEM, button ],
[ eq, BUTTON, wps ],
[ eq, ACTION, released ],
],
[ clear-interval, wpsbutton ]
],
Result from /etc/rc.button/wps script:
SUBSYSTEM:button BUTTON:wps ACTION:pressed SEEN:34 ELAPSED:
SUBSYSTEM:button BUTTON:wps ACTION:interval SEEN: ELAPSED:1
SUBSYSTEM:button BUTTON:wps ACTION:interval SEEN: ELAPSED:2
SUBSYSTEM:button BUTTON:wps ACTION:interval SEEN: ELAPSED:3
SUBSYSTEM:button BUTTON:wps ACTION:released SEEN:3 ELAPSED:
---
plug/hotplug.c | 143 +
1 file changed, 143 insertions(+)
diff --git a/plug/hotplug.c b/plug/hotplug.c
index 1a98e8b..0b183fb 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -43,7 +43,19 @@ struct cmd_queue {
void (*handler)(struct blob_attr *msg, struct blob_attr *data);
};
+struct cmd_interval {
+ char *name;
+ struct list_head list;
+
+ struct timespec start;
+ struct uloop_timeout timeout;
+
+ struct blob_attr *msg;
+ struct blob_attr *data;
+};
+
static LIST_HEAD(cmd_queue);
+static LIST_HEAD(cmd_intervals);
static struct uloop_process queue_proc;
static struct uloop_timeout last_event;
static struct blob_buf b;
@@ -157,6 +169,129 @@ static void handle_exec(struct blob_attr *msg, struct
blob_attr *data)
exit(-1);
}
+static void handle_set_interval_timeout(struct uloop_timeout *timeout)
+{
+ struct cmd_interval *interval = container_of(timeout, struct
cmd_interval, timeout);
+ struct blob_attr *cur;
+ char *argv[8];
+ int rem, fd, pid;
+ int msecs = 0;
+ int i = 0;
+
+ blobmsg_for_each_attr(cur, interval-data, rem) {
+ switch (i) {
+ case 0:
+ break;
+ case 1:
+ msecs = strtol(blobmsg_get_string(cur), NULL, 0);
+ break;
+ default:
+ argv[i - 2] = blobmsg_data(cur);
+ }
+ i++;
+ if (i - 2 == 7)
+ break;
+ }
+
+ pid = fork();
+ if (pid 0) {
+ perror(fork);
+ } else if (pid == 0) {
+ struct timespec now;
+ char elapsed[6];
+
+ if (i - 2 = 0)
+ return;
+
+ clock_gettime(CLOCK_MONOTONIC, now);
+ snprintf(elapsed, sizeof(elapsed), %ld, now.tv_sec -
interval-start.tv_sec);
+
+ blobmsg_for_each_attr(cur, interval-msg, rem)
+ setenv(blobmsg_name(cur), blobmsg_data(cur), 1);
+ setenv(ACTION, interval, 1);
+ setenv(ELAPSED, elapsed, 1);
+ unsetenv(SEEN);
+
+ if (debug 3) {
+ fd = open(/dev/null, O_RDWR);
+ if (fd -1) {
+ dup2(fd, STDIN_FILENO);
+ dup2(fd, STDOUT_FILENO);
+ dup2(fd, STDERR_FILENO);
+ if (fd STDERR_FILENO)
+ close(fd);
+ }
+ }
+
+ argv[i - 2] = NULL;
+ execvp(argv[0], argv[0]);
+ exit(-1);
+ } else {
+ uloop_timeout_set(interval-timeout, msecs);
+ }
+}
+
+static void handle_set_interval(struct blob_attr *msg, struct blob_attr *data)
+{
+ static struct blobmsg_policy set_interval_policy[2] = {
+ { .type = BLOBMSG_TYPE_STRING },
+ { .type = BLOBMSG_TYPE_STRING },
+ };
+ struct blob_attr *tb[2];
+ struct cmd_interval *interval;
+ struct blob_attr *_msg, *_data;
+ int msecs;
+
+ blobmsg_parse_array(set_interval_policy, 2, tb, blobmsg_data(data),
blobmsg_data_len(data));
+ if (!tb[0] || !tb[1])
+ return;
+ msecs = strtol(blobmsg_get_string(tb[1]), NULL, 0);
+
+ interval = calloc_a(sizeof(struct cmd_interval),
+ _msg, blob_pad_len(msg),
+ _data, blob_pad_len(data),
+ NULL);
+ if (!interval)
+ return;
+
+ interval-name =
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On Thu, May 7, 2015 at 8:01 AM, Wojciech Dubowik
wojciech.dubo...@neratec.com wrote:
On 06/05/15 21:23, Heiner Kallweit wrote:
Am 05.05.2015 um 22:17 schrieb Heiner Kallweit:
Am 05.05.2015 um 08:29 schrieb Wojciech Dubowik:
On 04/05/15 22:45, Heiner Kallweit wrote:
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system
boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
Gpio controller is now at fc00. See latest commit for
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi.
Regards,
Wojtek
PS. I have been also trying 4.0 but I have ran into so many problems
with gianfar that I have given it up.
For now...
Thanks. I face issues with the network as well and had to attach a serial
console + tftpboot to make it work again.
Back to 3.19.0 now ..
Heiner
I gave it one more try and replaced the gianfar driver from 4.0.1 with the
one from 3.19.0. Results:
- When rebooting first time after flashing the system (4.0.1) came up
properly and was reachable via network.
- After next reboot: system hangs
Booting the failing system with a serial console attached shows that after
procd -init- nothing happens.
I can log in via serial console. ps -ef showed that
/etc/rc.d/S00sysfixtime was hanging.
Checking the commands in this script manually I figured out that each
access to /etc/uci-default blocks the console.
Seems like the first start after flashing the system does something bad
with /etc/uci-defaults.
Or for whatever reason something can't deal properly with the empty
/etc/uci-defaults after the second boot.
No clue whom to blame ..
Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on
readdir. As far as I remember
with this patch it went through but I don't know anymore whether I have
changed sth in config.
Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for spi
nor flash.
Even with this patch I got some possible dead lock warnings so it might be
just a partial cure. BTW it's
a bit scary for future use. Looks like jffs2 doesn't get enough care...
Regards,
Wojtek
Heiner
Thanks for the hints!
Because you mentioned that you have lots of problems with gianfar
under 4.0: what kind of problems?
Heiner
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 07/05/15 14:49, Felix Fietkau wrote: On 2015-05-07 08:01, Wojciech Dubowik wrote: Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on readdir. As far as I remember with this patch it went through but I don't know anymore whether I have changed sth in config. Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for spi nor flash. Even with this patch I got some possible dead lock warnings so it might be just a partial cure. BTW it's a bit scary for future use. Looks like jffs2 doesn't get enough care... I believe the locking issues are an overlayfs regression, maybe even the same one as this one (which I fixed years ago): http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged I believe this is the cause of the regression: commit 49c21e1cacd74a8c83407c70ad860c994e606e25 Author: Miklos Szeredi mszer...@suse.cz Date: Sat Dec 13 00:59:42 2014 +0100 ovl: check whiteout while reading directory Don't make a separate pass for checking whiteouts, since we can do it while reading the upper directory. This will make it easier to handle multiple layers. Signed-off-by: Miklos Szeredi mszer...@suse.cz It probably happens like this: overlayfs does a readdir, in which jffs2 takes a lock. From within the readdir fill callback, it calls lookup_one_len, which ends up back in jffs2 and tries to take the same lock again. = deadlock. This is exactly what I have seen. I have got deadlocks on readdir. Unfortunately I don't have any logs saved... Wojtek - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
