[OpenWrt-Devel] r38914 breaks multiple WiFi interfaces
Since r38914 I can no longer have a AP and STA interface simultaneously on a WRT160NL. The STA will work fine but the AP SSID is not broadcasted. I'm not sure if this needs to be solved upstream on hostapd or needs to be patched. Regards, Nuno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/1] Add sysfixtime init script, replacement of luci_fixtime
Introduce save_time_interval config (in seconds) to set a
max on how often time is saved to flash (default 30 days)
Introduce save_time_file config, default to
/etc/config/sysfixtime, so it's included in backups
(time is saved by touching save_time_file)
Use busybox ntpd -S option so time is saved regularly
and not only on clean shutdown/reboot
Fix time on startup if system time is inferior to
stored time
Signed-off-by: Etienne CHAMPETIER
---
package/utils/busybox/Makefile | 8 +
package/utils/busybox/files/sysfixtime | 45 +
package/utils/busybox/files/sysfixtime.conf | 3 ++
package/utils/busybox/files/sysntpd | 3 +-
4 files changed, 58 insertions(+), 1 deletion(-)
create mode 100755 package/utils/busybox/files/sysfixtime
create mode 100644 package/utils/busybox/files/sysfixtime.conf
diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile
index cf4f1f2..86a359f 100644
--- a/package/utils/busybox/Makefile
+++ b/package/utils/busybox/Makefile
@@ -50,6 +50,10 @@ define Package/busybox/config
source "$(SOURCE)/Config.in"
endef
+define Package/busybox/conffiles
+/etc/config/sysfixtime
+endef
+
CONFIG_TEMPLATE:=./config/default
LDLIBS:=m crypt
@@ -114,6 +118,10 @@ define Package/busybox/install
$(INSTALL_BIN) ./files/cron $(1)/etc/init.d/cron
$(INSTALL_BIN) ./files/telnet $(1)/etc/init.d/telnet
$(INSTALL_BIN) ./files/sysntpd $(1)/etc/init.d/sysntpd
+ $(INSTALL_BIN) ./files/sysfixtime $(1)/etc/init.d/sysfixtime
+ $(INSTALL_DIR) $(1)/etc/config
+ $(INSTALL_CONF) ./files/sysfixtime.conf $(1)/etc/config/sysfixtime
+ touch $(1)/etc/config/sysfixtime
-rm -rf $(1)/lib64
endef
diff --git a/package/utils/busybox/files/sysfixtime
b/package/utils/busybox/files/sysfixtime
new file mode 100755
index 000..15d0a36
--- /dev/null
+++ b/package/utils/busybox/files/sysfixtime
@@ -0,0 +1,45 @@
+#!/bin/sh /etc/rc.common
+# Copyright (C) 2013-2014 OpenWrt.org
+
+START=05
+STOP=95
+
+config_load sysfixtime
+config_get save_time_file sysfixtime save_time_file "/etc/config/sysfixtime"
+config_get save_time_interval sysfixtime save_time_interval 2592000
+
+EXTRA_COMMANDS="save save2 step stratum periodic unsync"
+EXTRA_HELP=" savesave time to flash by touching $save_time_file
+ save2 save time to flash by touching $save_time_file
+ if not saved in the last $save_time_interval seconds
+ disabled if save_time_interval = 0"
+
+start() {
+ CURTIME=`date '+%Y%m%d%H%M'`
+ SAVEDTIME=`date '+%Y%m%d%H%M' -r $save_time_file`
+ [[ $CURTIME -lt $SAVEDTIME ]] && \
+ date -s $SAVEDTIME && \
+ /usr/bin/logger -t sysfixtime -p daemon.notice "Time fixed"
+}
+
+save2() {
+ [[ $save_time_interval -eq 0 ]] && exit
+ CURTIME=`date +%s`
+ SAVEDTIME=`date +%s -r $save_time_file`
+
+ [[ $((CURTIME - SAVEDTIME)) -gt $save_time_interval ]] && save
+}
+
+save() {
+ cat /dev/null >> $save_time_file && \
+ touch $save_time_file && \
+ /usr/bin/logger -t sysfixtime -p daemon.notice "Time saved to
flash"
+}
+
+stop() { save2; }
+
+step() { save2; }
+stratum() { save2; }
+periodic() { save2; }
+unsync() { exit; }
+
diff --git a/package/utils/busybox/files/sysfixtime.conf
b/package/utils/busybox/files/sysfixtime.conf
new file mode 100644
index 000..6e0fc3f
--- /dev/null
+++ b/package/utils/busybox/files/sysfixtime.conf
@@ -0,0 +1,3 @@
+config sysfixtime sysfixtime
+ option save_time_file "/etc/config/sysfixtime"
+ option save_time_interval 2592000
diff --git a/package/utils/busybox/files/sysntpd
b/package/utils/busybox/files/sysntpd
index add7762..2612bc6 100755
--- a/package/utils/busybox/files/sysntpd
+++ b/package/utils/busybox/files/sysntpd
@@ -1,5 +1,5 @@
#!/bin/sh /etc/rc.common
-# Copyright (C) 2011 OpenWrt.org
+# Copyright (C) 2011-2014 OpenWrt.org
START=98
@@ -24,6 +24,7 @@ start_service() {
procd_open_instance
procd_set_param command "$PROG" -n
[ "$enable_server" = "1" ] && procd_append_param command -l
+ procd_append_param command -S /etc/init.d/sysfixtime
for peer in "$server"; do
procd_append_param command -p $peer
done
--
1.8.4.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 0/1] Add sysfixtime init script, replacement of luci_fixtime
Here is a v2 of sysfixtime, you can now disable auto-saving, choose an other file to save time (on an usb stick?), and save_time_interval is now in seconds, to be able to save more often I don't know how to use s,min,h,d,m,... (for weedy) Etienne CHAMPETIER (1): Add sysfixtime init script, replacement of luci_fixtime package/utils/busybox/Makefile | 8 + package/utils/busybox/files/sysfixtime | 45 + package/utils/busybox/files/sysfixtime.conf | 3 ++ package/utils/busybox/files/sysntpd | 3 +- 4 files changed, 58 insertions(+), 1 deletion(-) create mode 100755 package/utils/busybox/files/sysfixtime create mode 100644 package/utils/busybox/files/sysfixtime.conf -- 1.8.4.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Happy New Year
I hope you won't mind me wishing everybody a happy and productive 2014. Thanks for all your collective work on OpenWrt -- it is really a very impressive achievement from my perspective as a user and occasional contributor. Best wishes Mike Brady ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add sysfixtime init script, replacement of luci_fixtime
Hi - Mail original - > De: "Bastian Bittorf" > À: "OpenWrt Development List" > Envoyé: Jeudi 2 Janvier 2014 10:35:51 > Objet: Re: [OpenWrt-Devel] [PATCH] Add sysfixtime init script, replacement of > luci_fixtime > > * etienne.champet...@free.fr [02.01.2014 > 10:25]: > > When you do a fresh (re)start, openvpn complains because > > "certificate is not yet valid". > > so simply set the system-time to the filedate of your cert + X > seconds. > It seems much more complicated (where is the cert, also it need openssl-util to decode the cert, ...) and would only work for openvpn. Other (vpn) software relying on certs still need this. > bye, bastian bye, etienne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] polling port status changes with the swconfig kernel module
Running OpenFlow on OpenWrt is a well known use-case. Of‐ softswitch is a user space implementation of OF software switch. If you want to use fast failover mechanisms with it, you have to provide port status information to ofsoftwitch. Polling via swconfig and swconfig API could be used in this case, but they are bloated, because they use context switch for each port status request. Lowering this overhead is important, because ofsoftswitch utilizes the whole CPU. To minimize the context switches I implemented the port status polling in kernel mode using the swconfig kernel module. With my patch the swconfig kernel module is able to modify the carrier state on predefined interfaces from &init_net according to a port status change in the switch. As a consequence, netlink messages notify user space programs about status changes of ports / interfaces. This was useful for us to test fast failover mechanisms of an OpenFlow switch. We believe this patch is generally useful beyond our routing soft‐ ware use‐case. More information can be found on this web page: http://centaur.sch.bme.hu/~leait/projects/openwrt/ If you are looking only for the patch: http://centaur.sch.bme.hu/~leait/projects/openwrt/patches/swconfig_poll.patch Tamas Levai Tested by: * Tamas Levai * Felician Nemeth ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HTTPS for binaries
Hi to all, I see that there is nice discussion about HTTPS, SSL and systime. This is nice place to interact :) Even if it sounds like more issues, in fact, there is big issue to increase security in openwrt. We are building BESIP images, based on OpenWrt. And we are trying to solve more problems by our patches: - DNSSEC support - HTTPS support - Certificates support/deploy - Time synchrinization - UCI provisioning using secure url All problems are connected together and security is not achieved, if one of this item fails. I think that there should be some possibility to embed enhanced security into OpenWrt. In other case, anybody will use its own scipts/patches for his scenario. Everything is possible even with today trunk packages/libraries. But there is not "glue". Maybe we should focus on it and try to solve it in trunk. Main questions: - Is it too much code/RAM/CPU/??? to embed all of this things into base system? (cleanest way) - Would it break many boxes because of HW requirements? - Is it possible to make some package like "openwrt-security" which would install all of this things? - If somebody wants security, it is enough to use "openwrt-security" package (embeded or opkg) "openwrt-security" should: - take care about systime at right time (very good solution is to use file time of CAs if system time is not available) - take care about basic CA setup (yes, this is probably most complicated part. Which CA? How to deploy them secure?) - take care about required libraries and applications to be secure and to use this technologies Maybe we do not need DNSSEC if we use HTTPS (we use unbound-host for queries in script), but it would be very nice to use it too. It would be great to make some discussion about this and find some solution. I know that we should look into security from OpenWrt side (opkg over https, sysupgrade over https,..) and client security (DNSSEC support, DNSSEC proxy support,..). Did I miss something? Thank you, Lukas Macura Dne 2.1.2014 09:26, David Lang napsal(a): On Thu, 2 Jan 2014, Peter Lawler wrote: On 01/01/14 23:11, Weedy wrote: If this really bothers you, you build from source. And vet the source code before building images. This is what I do for my clients. Someone also mentioned this approach on the trac issue[0], so I'll use same comments here as well. No offence meant by not personalising it :) --- Someone asked me earlier today about how a 'self built' approach alleviates the chicken and egg problem of the compiler[1] why should you trust the compiler used by the project more than the compiler on your system? In any case, don't the people you are trying to defend against have the power to forge SSL certs as well? (by being able to get some CA that your system trusts to sign a cert that they control) so even if you downloaded via HTTPS they could still mitm your download. I would suggest that you turn your concerns closer to home. How do you know they haven't put malware on your hard drive the way that this page shows can be done? http://spritesmods.com/?art=hddhack not to mention the possibility of your smartphone being hacked by it's charger, and then being used to hack the rest of your system. There are so many ways in that modifying the source code you download in a way that will still compile on a project that changes as rapidly as openwrt is a very daunting task, and you should expect that they have far better uses of their time. David Lang At minimum, I'd suggest maybe it'd be a better usage of infrastructure/development time for OpenWRT to consider reproducible/deterministic binaries[2][3] or am I showing my ignorance of current practice of OpenWRT? Cheers, Pete. [0] https://dev.openwrt.org/ticket/13346#comment:6 [1] http://cm.bell-labs.com/who/ken/trust.html [2] https://wiki.debian.org/ReproducibleBuilds [3] https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Updating vlan interface link on switch port link change?
On Wednesday 18 December 2013 21:37:40 Rafał Miłecki wrote: > 2013/12/18 Rafał Miłecki : > > Some routers (a lot of/all Broadcom's BCM47xx based models) have only > > a one network card attached to a switch. In such situation you usually > > use one VLAN for WAN port and another VLAN for LAN ports. > > > > The problem is that WAN is a virtual VLAN interface and it's always > > up. Even if I disconnect ethernet cable from the WAN, eth0.X is still > > up. > > > > Do you have any idea how this could be improved? > > Could we for example keep a list of VLANs with only one port assigned > > and adjust VLAN interface state to match current port state? Is this > > the right thing to do? > > How otherwise we can know that WAN is disconnected/not working? > > Or maybe you have some other idea how we can handle refreshing IP > address on VLAN interface? Currently once-assigned IP doesn't change > until I restart network manually. http://0pointer.de/lennart/projects/ifplugd/ In openwrt: CONFIG_BUSYBOX_CONFIG_IFPLUGD or DHCP is unaware of any link changes, it will only renegotiate DHCP lease when lease time has elapsed.. so you could set dhcp lease time shorter (if you have control over DHCP server), like every 1 (or 5) minutes... that way (longer) link interrupts are caught more quickly by the DHCP daemon. Tijs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add sysfixtime init script, replacement of luci_fixtime
I don't see a problem with adding this. Sane usage case. Sane script. If we default to thirty days even if you turn it on by accident it won't ware anything out. I would like to see it take min,h,d,m as increment arguments. On 2 Jan 2014 04:26, "Bastian Bittorf" wrote: > * etienne.champet...@free.fr [02.01.2014 > 10:25]: > > When you do a fresh (re)start, openvpn complains because "certificate is > not yet valid". > > so simply set the system-time to the filedate of your cert + X seconds. > > bye, bastian > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add sysfixtime init script, replacement of luci_fixtime
* etienne.champet...@free.fr [02.01.2014 10:25]: > When you do a fresh (re)start, openvpn complains because "certificate is not > yet valid". so simply set the system-time to the filedate of your cert + X seconds. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HTTPS for binaries
On Thu, 2 Jan 2014, Peter Lawler wrote: On 01/01/14 23:11, Weedy wrote: If this really bothers you, you build from source. And vet the source code before building images. This is what I do for my clients. Someone also mentioned this approach on the trac issue[0], so I'll use same comments here as well. No offence meant by not personalising it :) --- Someone asked me earlier today about how a 'self built' approach alleviates the chicken and egg problem of the compiler[1] why should you trust the compiler used by the project more than the compiler on your system? In any case, don't the people you are trying to defend against have the power to forge SSL certs as well? (by being able to get some CA that your system trusts to sign a cert that they control) so even if you downloaded via HTTPS they could still mitm your download. I would suggest that you turn your concerns closer to home. How do you know they haven't put malware on your hard drive the way that this page shows can be done? http://spritesmods.com/?art=hddhack not to mention the possibility of your smartphone being hacked by it's charger, and then being used to hack the rest of your system. There are so many ways in that modifying the source code you download in a way that will still compile on a project that changes as rapidly as openwrt is a very daunting task, and you should expect that they have far better uses of their time. David Lang At minimum, I'd suggest maybe it'd be a better usage of infrastructure/development time for OpenWRT to consider reproducible/deterministic binaries[2][3] or am I showing my ignorance of current practice of OpenWRT? Cheers, Pete. [0] https://dev.openwrt.org/ticket/13346#comment:6 [1] http://cm.bell-labs.com/who/ken/trust.html [2] https://wiki.debian.org/ReproducibleBuilds [3] https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HTTPS for binaries
On 01/01/14 23:11, Weedy wrote: > If this really bothers you, you build from source. And vet the source code > before building images. > > This is what I do for my clients. Someone also mentioned this approach on the trac issue[0], so I'll use same comments here as well. No offence meant by not personalising it :) --- Someone asked me earlier today about how a 'self built' approach alleviates the chicken and egg problem of the compiler[1] At minimum, I'd suggest maybe it'd be a better usage of infrastructure/development time for OpenWRT to consider reproducible/deterministic binaries[2][3] or am I showing my ignorance of current practice of OpenWRT? Cheers, Pete. [0] https://dev.openwrt.org/ticket/13346#comment:6 [1] http://cm.bell-labs.com/who/ken/trust.html [2] https://wiki.debian.org/ReproducibleBuilds [3] https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
