Re: [OpenWrt-Devel] [PATCH v2] base-files: init/sysfixtime - exclude dnsmasq.time
On 9/22/15 1:52 PM, Bastian Bittorf wrote:
> +maxtime() {
> + local dir file
> +
> + find /etc -type d | while read dir; do
> + file="$dir/$( ls -1t "$dir" | head -n1 )"
> + [ -e "$file" -a "$file" != '/etc/dnsmasq.time' ] && date -r
> "$file" +%s
> + done | sort -nr | head -n1
> +}
It appears that if /etc/dnsmasq.time is the newest file in /etc, it will
"shadow" the next-newest file. "ls -lt /etc | head -n1" will be
/etc/dnsmasq.time, and no other /etc/* files will be checked. The new
code will also check the mod time of directories and symlinks, unlike
the previous implementation.
I was experimenting a little. The fastest is probably "ls -t $(find
/etc -type f) | head -1", but that does not behave well if there are too
many files in /etc (too many args). Using xargs to split the ls
invocations is possible, but then each xargs invocation needs to take
the max separately. The fourth sample below does this.
"test" has: test $a -ot $b ($a older than $b). This makes the script
reasonably straightforward (only checks files, ignores arbitrary paths)
and pretty fast in my test:
local file newest
for file in $( find /etc -type f ! -path /etc/dnsmasq.time ) ; do
[ -z "$newest" -o "$newest" -ot "$file"] && newest=$file
done
echo $newest
# time sh -c 'find /etc -type f -exec date -r {} +%s \; | sort -nr |
head -n1'
1443239314
real0m 0.77s
user0m 0.17s
sys 0m 0.58s
# time sh -c 'date -r $(ls -t $( find /etc -type f ) | head -1) +%s'
# fails if /etc contains too many files
1443239314
real0m 0.04s
user0m 0.02s
sys 0m 0.03s
# time sh -c 'local file newest; for file in $(find /etc -type f ! -path
/etc/dnsmasq.time) ; do [ -z "$newest" -o "$newest" -ot "$file" ] &&
newest=$file ; done ; [ "$newest" ] && date -r "$newest" +%s'
1443239314
real0m 0.06s
user0m 0.03s
sys 0m 0.03s
# time sh -c 'find /etc -type f ! -path /etc/dnsmasq.time | xargs sh -c
'\''ls -t "$@" | head -1'\'' - | while read p ; do date -r $p +%s ; done
| sort -nr | head -1'
1443239314
real0m 0.07s
user0m 0.02s
sys 0m 0.06s
Feel free to use or ignore.
--
-Justin
justinval...@gmail.com
smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [dnsmasq] support enforced start-IP, end-IP, netmask
On 10/14/14 7:07 AM, Bastian Bittorf wrote: * John Crispin blo...@openwrt.org [14.10.2014 12:36]: try this config dhcp 'roaming' option interface 'voyager' option netmask '255.255.255.0' option start 1 option limit 253 it does not work. this is my interface: Do you know: 192.168.0.0/16 with start=257, limit=253 gives range 192.168.1.1-192.168.1.253 (maybe off by one)? -- -Justin justinval...@gmail.com smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Default dhcp (client) hostname is unset - Luci implies $(hostname)
On 10/8/14 4:47 AM, Christian Schoenebeck wrote: Inside [buildroot]/feeds/luci/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua you find the definition hostname.placeholder = luci.sys.hostname(). It's not default so its never written/used to configuration. From the LuCI point of view placeholder is a sample. (light grey) If it's a default (also used be the system behind LuCI) then its written into the field as if the user write something into the field. Now I see what you mean. It is confusing, though, from a UI because sometimes the ghost values are defaults and sometimes samples. I don't think your last statement is accurate, because there are default values that are not saved in uci. 1) DHCP DNS / General Settings: DNS forwardings /example.org/10.1.2.3 is clearly a sample. 2) ... / Advanced Settings: DNS server port 53, but dhcp.@dnsmasq[0].port is unset. 53 is the default DNS port. Setting it causes dhcp.*.port to be set. 3) ... / Advanced Settings : Max concurrent queries 150, but no dhcp.@dnsmasq[0].* value. 150 is the default value (app default) The only way to tell the difference between a sample and a default would be to know whether the value is reasonable. In the case of DHCP hostname, the default seems reasonable, so it is confusing when udhcpc does not send $HOSTNAME. In 5434f9ac.3050...@openwrt.org, Jow said that some dhcp servers choke on dhcp hostnames. Then, if 99% of OpenWRT configurations are probably where the upstream dhcp server is external, sending a hostname will do more harm than good. Then, back to the UI. Since it is hard to distinguish between default value and example value in DHCP client hostname, can it be changed to empty-string? I tried the following: [[[ git://git.openwrt.org/project/luci.git diff --git a/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua b/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua index fe3fec6..62047b5 100644 --- a/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua +++ b/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua @@ -20,7 +20,6 @@ local bcast, defaultroute, peerdns, dns, metric, clientid, vendorclass hostname = section:taboption(general, Value, hostname, translate(Hostname to send when requesting DHCP)) -hostname.placeholder = luci.sys.hostname() hostname.datatype= hostname ]]] -- -Justin justinval...@gmail.com smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Default dhcp (client) hostname is unset - Luci implies $(hostname)
[BB 14.07] In the Luci section for Interface / General Setup, the is a parameter Hostname to send when requesting DHCP. That input field has a ghost value of $HOSTNAME (meaning to me that its default value is $HOSTNAME). However, entering the $HOSTNAME in the field changes the behavior. I can see udhcpc being called with -H $host if I give a value, and no -H if left blank. It appears from command-line options that -H (or newer -x hostname:$HOST) causes the DHCP Hostname option to be sent, but it is not sent otherwise. So either: 1) The dhcp hostname option should be blank to indicate no default value (maintain current behavior) 2) When udhcpc is invoked, it should pass -H $(hostname) in case of default (make backend behave as Luci implies) IMO: I find it nice that many hosts pass their hostname automatically, so that the DHCP active lease list is useful, versus a lot of ? entries and ethernet addresses. So, I would vote for 2. Opinions? Where would this bug get posted? (wiki.openwrt.org is down, so I cannot check the wiki) -- -Justin justinval...@gmail.com smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Services do not appear/disappear until reboot - luci-indexcache?
Running BB-rc3and configuring from scratch. Iinstalled luci-app-ddns and luci-app-upnp(svn-r10471-1). The apps should show up in the services menu, but they did not - in fact, the services menu did not appear at all. Tried restarting uhttpd, no effect. Rebooted, and the services menu appeared. Decided to cause some trouble, and removed the two packages. The services menu is unchanged (still shows the removed apps), and choosing an entry gives a lua (internal) error. Grepping around, I find an occurrence of the removed package string Dynamic DNS in /var/luci-indexcache. Maybe this is a package problem? If that is just the way it is, I'll get over it. If the package(s) is (are) not doing the right thing, let me know how it is supposed to work (example package), and I'll try fixing it. -- -Justin justinval...@gmail.com smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
I don't think turning off the firewall is a sane default. Your arguments based on global addressability are false because IPv4 can be globally addressable, if you want. You can get static ip addresses (or a subnet), turn off NAT, and turn off the firewall - every internal network device will be on the public internet. You say: A general principle is that a service should not be bound on a globally reachable address if it is not meant to be globally accessible. If my desktop is given an IPv6 address, are all of my services now globally addressable? If yes, I have opened up all local services (oops). If no, do I need a locally addressable and globally addressable IPv6 space for each device service, so that I can choose which services I consider internal (my printer, my smb share) vs external (my web server)? That is pushing the security problem to the terminal devices. I do not understand what the principle of least privilege has to do here. “Forbidden by default” is not about privileges. Privilege here is the right to do something; with respect to networking: open a connection to any host, open a connection to a specific host, allow incoming connections from any host. Principle of least privilege means that you only allow what is required - default is to restrict, not allow. Privileges are granted where necessary, instead of taken away when abused. Here, incoming connections represent a security risk (hackers), and mitigation is that it becomes a privilege (to be earned). By default, incoming connections are not allowed, and uPNP (etc) is used to request (and grant) that privilege. -Justin On 7/15/14, 1:43 PM, Benjamin Cama wrote: Le mardi 15 juillet 2014 à 11:45 -0400, Aaron Z a écrit : - Original Message - On Monday, July 14, 2014 5:36:09 PM Benjamin Cama ben...@dolka.fr wrote: Hi everyone, Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit : I'd rather have Don't bother the user: things should generally just work, without having to configure anything (in this case, port forwarding). But there is an obvious tradeoff with security. I agree with Baptiste here. There is no equivalent in IPv4 of “global reachability” by default with the NATs we have today, so we can't have the same defaults. Global reachability is how IP in general was meant to be; please, do not make it broken again. As I understand it, this is NOT adding NAT, but (by default) blocking unsolicited incoming connections from the outside world to devices on the internal network (which dont necessarily need to be accessible from the outside world). This thread is about choosing a sane default. Blocking by default means you can't have VoIP or P2P working out of the box. This was tricky with IPv4+NAT as it involves some trickery and software support (see UPnP and the like), but IPv6 offers the possibility to have it work without any supplemental development effort! When you say that devices don't “necessarily” need to be accessible, you already made a choice that is impossible to change back for 99.99% of people (which don't know how to tune a firewall). That is the whole point in using a firewall is it not? To keep people out of where they shouldn't be. Well, you can configure your “firewall” as it pleases you to block whatever you want, but the one in OpenWRT is quite “open” by default, as much as permit IPv4 (which is, only outbound connections are allowed; inbound connections are not possible “by design” by default because of NAT). Opening up the IPv6 firewall by default would be unexpected and I don't really like the approach for that matter and honestly I don't trust client devices that much. At least opening UDP ports 1024 seems pretty reasonable, and covers most use-cases regarding VoIP and video. But it does indeed depart from the IPv4 case (not sure if it is such a bad idea though). This looks like a good compromise to me. Knowledgeable users can disable the firewall for needed hosts, while for others this “just work”. PCP may be coming one day, but it's still not there yet, so we need not to break the default configuration while waiting for it. Opening access from the outside to the inside as a default rule goes against the principle of least privilege on which firewall rules are generally predicated. I do not understand what the principle of least privilege has to do here. “Forbidden by default” is not about privileges. As I understand it, if a device on the inside of the network initiates the connection to a device on the outside (say from a VOIP phone to a VOIP server), return connections from the server are allowed. Yes, by looking at it from a very client-inside and server-outside (and TCP and state-tracking) view. That is a lot of presuppositions. This way, you can call a “server”, but nobody can call you. What gets blocked are unsolicited connections from the outside which are generally unneeded (and can be a security
Re: [OpenWrt-Devel] Broken Ethernet switch on AsiaRF AWM002
On 5/30/14, 2:50 PM, jonsm...@gmail.com wrote:
I have this patch I wrote a year ago that fixed the broken Ethernet
switch on the AWM002. I've forgotten exactly what I was trying to do.
For some reason the switch was not getting programmed by default.
What is up with this bit? Why did I need to change it?
- if [ -n ${RT3X5X} ]; then
+ if [ ${RT3X5X} ]; then
I don't think there is any difference. From test man page (OS X):
stringTrue if string is not the null string.
-n string True if the length of string is nonzero.
null string == empty string
Quick test (AA 12.09, busybox 1.19.4-6):
# X=abc ; if [ -n $X ] ; then echo true ; else echo false ; fi ; if [
$X ] ; then echo true ; else echo false ; fi
true
true
# X= ; if [ -n $X ] ; then echo true ; else echo false ; fi ; if [
$X ] ; then echo true ; else echo false ; fi
false
false
# unset X ; if [ -n $X ] ; then echo true ; else echo false ; fi ; if
[ $X ] ; then echo true ; else echo false ; fi
false
false
--
-Justin
justinval...@gmail.com
smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenSSL: update to 1.0.1g - heartbleed bug
FYI: It appears opkg upgrade libopenssl will install it if it has not yet been installed. Therefore, if the commands are run just-in-case, you will end up installing libopenssl where it was not previously installed: # opkg info libopenssl | grep ^Status: Status: unknown ok not-installed # opkg list-upgradable # opkg upgrade libopenssl Installing libopenssl (1.0.1g-1) to root... Downloading http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages/libopenssl_1.0.1g-1_ar71xx.ipk. Configuring libopenssl. # opkg info libopenssl | grep ^Status: Status: install user installed # opkg remove libopenssl Removing package libopenssl from root... The Status: ... user ... means that it was manually requested (or installed via an upgrade). -Justin On 4/10/14, 4:45 PM, John Crispin wrote: Heartbleed - libopenssl AA binary feed update we updated the AA release. the files libopenssl_1.0.1e-1_*.ipk have been replaced with libopenssl_1.0.1g-1_*.ipk and the Packages index was updated. If you use openssl on your unit you need to run : # opkg update # opkg upgrade libopenssl In order to ensure that all affected services are using the updated OpenSSL library it is recommended to reboot the device after applying the upgrade. To find out more about the bug go to - http://heartbleed.com/ Note that default OpenWrt installations are not vulnerable to the particular bug, neither the builtin SSH server nor the optional LuCI SSL support rely on OpenSSL for cryptography. The OpenSSL library is not installed within the stock images available on the download server. This is not a lightweight bug. Please take it serious and check your unit. OpenWrt Developers ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- -Justin justinval...@gmail.com smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how enable the scp service ?
From my Mac, "scp -v myfile host:/tmp/target" (-v for verbose) appears to run "ssh host scp -v -t /tmp/target". On my AA 12.01: # which scp /usr/bin/scp # opkg search /usr/bin/scp dropbear - 2011.54-2 Does "ssh target" work? Can you run verbose mode (ie: "scp -v myfile host:/tmp/target")? Can you scp to other machines (insuring that your winscp is working)? On 3/13/14, 2:48 AM, Alan.Hoo wrote: PS, the winscp program login successfully but exit very soon. From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Alan.Hoo Sent: Thursday, March 13, 2014 2:43 PM To: 'OpenWrt Development List' Subject: [OpenWrt-Devel] how enable the scp service ? hello everyone I've encountered a error during use winscp for login to my router. it's seems scp service disbled. what's the name of scp service on OpenWRT ? BR Alan.Hoo,Code Monkey MSFT ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- -Justin justinval...@gmail.com smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [12.09] Luci list-based options - problem removing items
It appears that there is a problem with removing items from a list-based
entry in Luci. For example, the System/System NTP Server list has trouble.
Here is one case:
1) Start with the list {a, b, c, d}.
2) Remove {a, b, c} by clicking on the first item's delete three times.
3) Save.
4) The list refreshes to {a, b, c, d, d}. The new list {d} is appended
to the old list {a, b, c, d}.
Even with two items {a, b}, removing {a} and saving creates the list {a,
b, b}.
Actually, now I don't see how to make the list into a single item...
So, it appears that if the new list is a single item, it is appended to
the old list instead of replacing it.
[ AA 12.09, Mac OS X, Safari 6.0.4, Samsung LCD monitor :-) ]
--
-Justin
justinval...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] System config - Include package list?
I just did an upgrade from AAb2 to AA, and did not save my old package list. Wouldn't it be useful to (at least) save the package list in the config? At some later point, the restore settings could show diff between current packages and config-saved packages. -- -Justin justinval...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostapd hang - cannot associate but existing connections ok
On 1/21/13 12:39 PM, Felix Fietkau wrote: On 2013-01-21 6:22 PM, Justin Vallon wrote: The symptom is that I cannot connect to my wireless network, but existing connections are ok. Once I try to reconnect from the client (wifi off wifi on), that device is then unable to connect. In the past, restarting hostapd has fixed the problem. What OpenWrt version are you using? Attitude adjustment (I believe beta2). -- -Justin justinval...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] hostapd hang - cannot associate but existing connections ok
The symptom is that I cannot connect to my wireless network, but
existing connections are ok. Once I try to reconnect from the client
(wifi off wifi on), that device is then unable to connect. In the
past, restarting hostapd has fixed the problem.
strace says it is stuck here:
sendto(9,
\2\3\0_\2\0\212\0\20\0\0\0\0\0\0\0\1zu\3647v\353\246E\270\260\302c\362\232\337...,
99, 0, {sa_family=AF_PACKET, proto=0x888e, if34, pkttype=PACKET_HOST,
addr(6)={0, e4ce8f297c0c}, 20
# lsof -p 19442
COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME
...
hostapd 19442 root9u pack3009857 0t0 0
type=SOCK_DGRAM
...
Why would this hang?
{ kill hostapd, wifi up }
Restarting hostapd fixed it.
--
-Justin
justinval...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] make sure strings will always be 0-terminated.
On 12/6/12 1:18 AM, Frank Meerkötter wrote:
@@ -345,7 +345,7 @@ int system_bridge_delif(struct device *bridge, struct device *dev)
static int system_if_resolve(struct device *dev)
{
struct ifreq ifr;
- strncpy(ifr.ifr_name, dev-ifname, sizeof(ifr.ifr_name));
+ strncpy(ifr.ifr_name, dev-ifname, sizeof(ifr.ifr_name) - 1);
if (!ioctl(sock_ioctl, SIOCGIFINDEX, ifr))
A copy of a string of length sizeof(buf)-1 will leave the string
unterminated (or, more precisely, ifr.ifr_name[sizeof(buf)-1] value is
undefined).
Add:
ifr.ifr_name[sizeof(ifr.ifr_name)-1] = 0;
Some of the other cases had mem-zeroed the buffers, while some (still)
left the possibility of an unterminated string.
--
-Justin
justinval...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
