[OpenWrt-Devel] IPv6: network segmentation, use of vlan and IPsec
Dear friends, I am studying IPv6 networks and would like to share some ideas with the community. At present, I am not sure to understand how to filter traffic and split networks. Here are a few questions: vlan: IPv6 has no broadcast. Do we still need vlans to segment traffic? Would you recommend using vlans together with IPv6? Filtering a switch: When a device includes a switch, how to filter ipV6 traffic on the switch? Do we need to use Brouting and ebtable or can it be done with iptables6? Mac address filtering: ipv6 embeds MAC address in frames. Clients may generate fake MAC addresses. Is there a way to hide MAC addresses on the router itself? IPsec: IPv6 allows to use IPsec in IPv6 frames. Can it be done already with a combination of FreeRadius, StrongSwan and IPv6. Do you know working configurations in OpenWRT? Kind regards, Gnutella ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] EAP-TLS / EAP-TTLS PAP
Le jeudi 26 mars 2015 à 14:33 +0100, Bernd Naumann a écrit : K back to the plot: Know you any hostapd configurations or other software in openwrt which can achieve that goal? Are there any issues which might can lead to problems or other downsides I may have missed? Reasons against? I am new to OpenWRT, but I will try to answer shortly: The wiki page for wireless is: http://wiki.openwrt.org/doc/howto/wireless.overview OpenWRT includes Linux IEEE 802.11 (wireless) subsystem. It covers a wide range of wireless cards. What you are referencing in your post is : 802.1X (secure) Per-user authentication using RADIUS, including support for dynamic vlan assignment. Basic WPA Enterprise configuration instructions: http://wiki.openwrt.org/doc/howto/wireless.security.8021x You should never use passwords, whether self-signed X.509 certificates, i.e. EAP-TLS. It seems to be supported and documentation is available. Loot at Radius and client certificate in this page: http://wiki.openwrt.org/doc/uci/wireless#wpaenterpriseaccesspoint You should be aware that when using certificates, you should be able to create, sign and manage your CA and certificates. You should set up a dedicated computer with no connection to Internet. OpenSSL will allow you to do that and is very well documented. Gnomint is a nice GUI: http://gnomint.sourceforge.net/ Kind regards, Gnutella ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6: network segmentation, use of vlan and IPsec
Hi Gnutella, This is likely not the correct mailing list for general network questions like this, and I'd suggest you go to somewhere like ##networking on Freenode to talk about this, however I'll try to answer your questions :) Firstly, your question seems to lack the clear distinction that should be made between Ethernet (layer2) and IPv6 (layer3). Please ensure that you are clear about the difference and the way in which they interact. For example you talk about MAC addresses in frames, but this is just a basic feature of the underlying Ethernet and is unavoidable when using this medium but would be unnecessary if using a different medium, such as PPP. While IPv6 has no broadcast addresses, it does have a large number of multicast addresses, including some that reach all nodes on a network. Therefore, if the decision to segment a network is based on having too much broadcast traffic (which takes a lot of nodes on a gigabit network to be a problem) then this is unlikely to change with IPv6 due to a similar volume of multicast traffic. Another common reason to segment a network is for security and firewalling, and the choice of layer 3 protocol does not change this. Nodes on the same layer 2 network (VLAN) will communicate with each other directly, whereas those on different layer 2 networks will communicate via a router, which is where firewalling would usually take place. You talk about filtering on a switch. This is usually considered a last resort when it is not practical to segment a network into separate subnets / VLANs. However as far as I know, the process for filtering traffic through a Linux switch is the same for IPv6 as it would be in IPv4, and Linux supports filtering bridged traffic with iptables (and I assume iptables6 though I have never tested this). MAC address filtering - unfortunately, I think this question is lacking some understanding of the interaction between layers. Clients can always use a fake MAC address, but this only affects the local LAN. MAC addresses are always stripped from packets when they pass through a router. It's possible that you aren't talking about MAC addresses at all, but EUI-64 IP addresses based on MAC addresses. In this case, you will find that most clients by default will use their MAC to generate their primary IP when using SLAAC but will also use additional random privacy addresses. It would probably not be a good idea to try to modify (NAT) people's IPs as they pass through a router, though it's certainly possible. I don't know enough about IPsec to answer your last question. I hope some of this is helpful :) Charlie On 27/03/15 07:33, Jean-Michel Pouré - GOOZE wrote: Dear friends, I am studying IPv6 networks and would like to share some ideas with the community. At present, I am not sure to understand how to filter traffic and split networks. Here are a few questions: vlan: IPv6 has no broadcast. Do we still need vlans to segment traffic? Would you recommend using vlans together with IPv6? Filtering a switch: When a device includes a switch, how to filter ipV6 traffic on the switch? Do we need to use Brouting and ebtable or can it be done with iptables6? Mac address filtering: ipv6 embeds MAC address in frames. Clients may generate fake MAC addresses. Is there a way to hide MAC addresses on the router itself? IPsec: IPv6 allows to use IPsec in IPv6 frames. Can it be done already with a combination of FreeRadius, StrongSwan and IPv6. Do you know working configurations in OpenWRT? Kind regards, Gnutella ___ 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] DHCPv6 flash renumbering patches with HE tunnel breaks
Steven Barth cy...@openwrt.org writes: If the DHCPv6 server sends values for T1 and / or T2 which are valid the client must honor them and not try to be smart about lifetimes of addresses. The problem is that you try to be smart by abusing the ability to set the address preferred lifetime lower than T1. I don't dispute that it is allowed by the RFC, but it is definitely not recommended. Quoting from RFC3315: 22.4. Identity Association for Non-temporary Addresses Option .. The server selects the T1 and T2 times to allow the client to extend the lifetimes of any addresses in the IA_NA before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the addresses in the IA that the server is willing to extend, respectively. Based on this, it should not come as an surprise that a number of clients start behaving erratically if you set T1 much higher than the preferred lifetime. Don't do that. It causes problems. You can of course continue to argue that not honouring T1 is a bug, but that will not fix any of the failing clients. in the lan-section of /etc/config/dhcp which will cause most clients to not use DHCPv6 and rely on RAs only. I have a real hard time understanding what makes a DHCPv6 IA_NA address any different from a RA based address wrt lifetimes. If you choose to provide both RA and DHCPv6 service to the lan clients using the same assigned prefix, then the lifetimes should be kept the same as well. Choosing between DHCPv6 and SLAAC is really up to the clients in this case. If you want to prefer one or the other from the server side, then I don't see any reason to provide both. And wrt the fear of sudden renumbering: The upstrem source, where you get these addresses assigned, will include lifetimes. Why don't you reuse those (after some basic sanitation)? If the problem is that the upstream lies to you, then I suggest fixing that instead. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] adding seccomp and service jailing to procd
OpenWrt service hardening and jailing = Current firmware builds have the problem, that a lot of services are running as root. This is especially critical for those services exposed to the network. Once an attacker has managed to compromise such a service he has full control over the system. Even if we change all processes to run as non root, there is still the risk of root privilege escalation using for example a bug in a kernel syscall implementation. Patching all services that we run (we have over 1000 packages) is not possible. The problem is far to diverse and distributed. Linux has many on board features to reduce these attack vectors. Lets create a solution that allows us to use these features without touching all services. Adding Seccomp support to procd === Seccomp is a Berkley Packet Filter (BPF) base syscall filter. Whenever a service does a syscall, a BPF filter runs and checks if the syscall is allowed. Currently the filters are setup to allow whitelisted syscalls. All other syscalls get handled by the default policy. This can be. * kill the service (policy = 0) * return -1 and set errno to n (policy = n) In order to define a syscall filter for a service, it must as a prerequisite be a procd managed service. Once this is done we simply add the following line to the init.d script - procd_set_param seccomp /etc/seccomp/service_name.json This will tell procd that when the service is started to use the filter rules defined inside the json file. As we do not want to patch every service to support seccomp natively we use the following LD_PRELOAD trick. The service is started with /lib/libpreload-seccomp.so preloading the __libc_start_main() function of the libc. The preloaded function does the following things. 1) get a pointer to the real __libc_start_main() 2) get a pointer to the real main() function of the service 3) call the real __libc_start_main() but pass it a pointer to a dummy main() function 4) inside the dummy main() we read the seccomp filter from json and apply it 5) call the real main() Doing this allows us to run the dynamic loader (ld.so) and libc_init code before we apply the seccomp filter. This reduces the amount of whitelisted syscall required to run the service. We have extended the kernels seccomp implementation and added an additional return action that works exactly like the errno action described above but also prints a line to the kernel log reporting which process trigger the exception and what syscall number is missing. This could also be achieved using the trap action but that would require additional stack parsing inside user-land, which is ugly. Enabling seccomp support As this procd feature is still new and under development it is not enabled by default. In order to enable it you need to select the following option inside make menuconfig - Global build settings --- [*] Enable seccomp support The feature has so far been implemented for mips, i386 and x86_64. Other architectures will follow shortly. Creating a seccomp filter json file === It would be very tedious to dig through all packages and figure out which syscalls are used, specially as many of them are hidden inside the libc functions that get used. To make things easier we have written a trivial strace like tool called utrace that will automagically create the json file for you. Simply calling - /sbin/utrace /bin/echo foo will create a file called /tmp/echo.json.$pid The syscalls are ordered with the one called most often listed first, so that it is the first inside the actual filter rules set inside the kernel. To make things even easier an extra init.d command called trace was added. By calling - /etc/init.d/service_name trace you can make procd start the service in trace mode. Once the service is stopped the json file is written to /tmp/. Adding process jailing to procd === This feature uses Linux namespaces. If you do not know what namespaces are (there are currently 5 of them) please refer to this LWN article. - http://lwn.net/Articles/531114/ In a nutshell a namespace is a container that separates various aspects of the user-land from the rest of the system. Namespaces are the base feature that allows us to run virtual containers using projects such as LXC. The first namespace that we use is the mount namespace. Once we have spawned our service inside a mount namespace it cannot see an mounts outside the container. This in turn allows us to use the pivot_root() syscall and effectively creating a separate rootfs for the service. As we do not want the service to see all files on the system, we stage the required ones into the container. The jailing tool will automatically detect the libraries needed to run the service, all other files need to be defined inside the procd init script. The following 3 new commands are used for this.
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
On 26/03/2015 23:51, Steven Barth wrote: Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support downstream delegation and its DHCPv6 features aren't well integrated if you have a dynamic prefix e.g. delegated from your ISP. I've been messing with the 'constructor' option for quite a while which is supposed to handle dynamic prefix allocation/deprecation, admittedly with my HE tunnel things aren't very (at all!) dynamic, but dnsmasq does pick up new publicly routable prefixes and start RA DHCPv6 on them automagically for me. From my /etc/dnsmasq.conf dhcp-range=lan,::100, ::F::, constructor:br-lan, ra-names, 64, 12h enable-ra I'll get back in my box now. 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] adding seccomp and service jailing to procd
Hi, 2015-03-27 10:42 GMT+01:00 John Crispin blo...@openwrt.org: OpenWrt service hardening and jailing = ... If there are features that we are not aware of yet or that we forgot to list, then please let us know about them. Comments and ideas are welcome ... ___ Thanks for this impressive piece of work!!! (awesome features and documentation) As you are working on Openwrt hardenning, what need to be done before activating option like STACKPROTECTOR, FORTIFY_SOURCE, RELRO_PARTIAL by default? (i'm already using them in all my builds, but i think everybody should use these options) Also i would love to hear the pro and cons of extending ubus vs switching to kdbus (i'm not trying to start a debate, and i really have no idea of the work involved, just curious) Thanks again and keep up the good work!!! (you and all the other devs) Etienne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Citeren Steven Barth cy...@openwrt.org: The problem is that you try to be smart by abusing the ability to set the address preferred lifetime lower than T1. I don't dispute that it is allowed by the RFC, but it is definitely not recommended. There is no formal requirement (not even a SHOULD) that says otherwise. The recommendation made is usually based on the basis that DHCPv6 is your only source of addresses which it isn't for us. That may be, but I think it is sufficiently hacky that it really not should be the default (or even only) mode of operation. I will provide a patch shortly to make this configurable. Based on this, it should not come as an surprise that a number of clients start behaving erratically if you set T1 much higher than the preferred lifetime. Don't do that. It causes problems. You can of course continue to argue that not honouring T1 is a bug, but that will not fix any of the failing clients. Now we know that they actually don't. The clients behave well, that seemed to be a misunderstanding. No, they don't. With regard to the renewal storms, that was a misunderstanding. But even with the latest odhcpd from trunk, especially webmail clients *will* see loss of connection, as the source IP on outgoing connections will be different 1 second of every T1 interval. Depending on the leasetime that is configured on the server, this may be infrequent enough to be hardly noticeable, or will lead to support calls. In my case, it was the latter. Arjen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
The problem is that you try to be smart by abusing the ability to set the address preferred lifetime lower than T1. I don't dispute that it is allowed by the RFC, but it is definitely not recommended. There is no formal requirement (not even a SHOULD) that says otherwise. The recommendation made is usually based on the basis that DHCPv6 is your only source of addresses which it isn't for us. Based on this, it should not come as an surprise that a number of clients start behaving erratically if you set T1 much higher than the preferred lifetime. Don't do that. It causes problems. You can of course continue to argue that not honouring T1 is a bug, but that will not fix any of the failing clients. Now we know that they actually don't. The clients behave well, that seemed to be a misunderstanding. The OP just tried with a version of our server which had a buggy T1 calculation. I have a real hard time understanding what makes a DHCPv6 IA_NA address any different from a RA based address wrt lifetimes. If you choose to provide both RA and DHCPv6 service to the lan clients using the same assigned prefix, then the lifetimes should be kept the same as well. Choosing between DHCPv6 and SLAAC is really up to the clients in this case. If you want to prefer one or the other from the server side, then I don't see any reason to provide both. The big difference is that as a router I can send RAs whenever I want and clients will react immediately. Most clients however do not support the same when doing DHCP and only do dumb polling based on T1/T2. So I have to be smart in some way to workaround. I would gladly get rid of DHCPv6 after all for clients but there is no good way to collect hostnames otherwise. And wrt the fear of sudden renumbering: The upstrem source, where you get these addresses assigned, will include lifetimes. Why don't you reuse those (after some basic sanitation)? If the problem is that the upstream lies to you, then I suggest fixing that instead. We do propagate them as-is through RAs. However imagine manual or automatic failover to a different ISP / connection or simply an ISP doing 6rd where your IPv6 prefix is mapped from your IPv4-address and th connection flaps and you get a different v4-address or a VPN-connection being brought up or down. In all these scenarios there needs to be a way to tell clients to stop using an address for global traffic near instantaneously otherwise they might lose connectivity. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
On 27.03.2015 10:41, Kevin Darbyshire-Bryant wrote: On 26/03/2015 23:51, Steven Barth wrote: Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support downstream delegation and its DHCPv6 features aren't well integrated if you have a dynamic prefix e.g. delegated from your ISP. I've been messing with the 'constructor' option for quite a while which is supposed to handle dynamic prefix allocation/deprecation, admittedly with my HE tunnel things aren't very (at all!) dynamic, but dnsmasq does pick up new publicly routable prefixes and start RA DHCPv6 on them automagically for me. From my /etc/dnsmasq.conf dhcp-range=lan,::100, ::F::, constructor:br-lan, ra-names, 64, 12h enable-ra Sure that works, but you can't e.g. number downstream routers with this only clients. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Steven Barth cy...@openwrt.org writes: The problem is that you try to be smart by abusing the ability to set the address preferred lifetime lower than T1. I don't dispute that it is allowed by the RFC, but it is definitely not recommended. There is no formal requirement (not even a SHOULD) that says otherwise. Agreed. But as usual, balancing on the edge of what you are allowed to do will give you more trouble than playing it safe. The recommended values are clearly stated. It's very likely that some client implementation didn't anticipate servers not following the recommendation. Which of course is their fault. Still your problem, though. The recommendation made is usually based on the basis that DHCPv6 is your only source of addresses which it isn't for us. What makes you believe that? Based on this, it should not come as an surprise that a number of clients start behaving erratically if you set T1 much higher than the preferred lifetime. Don't do that. It causes problems. You can of course continue to argue that not honouring T1 is a bug, but that will not fix any of the failing clients. Now we know that they actually don't. The clients behave well, that seemed to be a misunderstanding. The OP just tried with a version of our server which had a buggy T1 calculation. Ah, OK. That sounds better. I have a real hard time understanding what makes a DHCPv6 IA_NA address any different from a RA based address wrt lifetimes. If you choose to provide both RA and DHCPv6 service to the lan clients using the same assigned prefix, then the lifetimes should be kept the same as well. Choosing between DHCPv6 and SLAAC is really up to the clients in this case. If you want to prefer one or the other from the server side, then I don't see any reason to provide both. The big difference is that as a router I can send RAs whenever I want and clients will react immediately. Sure. This is a very good argument for using only RAs in an environment where the address lifetimes cannot be trusted. Most clients however do not support the same when doing DHCP and only do dumb polling based on T1/T2. So I have to be smart in some way to workaround. But how does it help? You are still not able to assign a new address to any DHCPv6 (only) client until T1 expires. And the SLAAC+DHCPv6 clients get a new and usable address immediately whether or not the old DHCPv6 address is deprecated. Yes, I can see that it helps clients using both DHCPv6 and SLAAC with their source address selection, simply by always avoiding DHCPv6 assigned addresses. But this policy should be up to the client, not the router. If they don't want to use the DHCPv6 address then they shouldn't ask for it. If they do want to use it, then you shouldn't prevent them from doing so. I would gladly get rid of DHCPv6 after all for clients but there is no good way to collect hostnames otherwise. Huh? How can you collect a hostname from DHCPv6? You get a DUID and that's all, isn't it? Ah, I see that you use DHCPV6_OPT_FQDN aka OPTION_CLIENT_FQDN. OK, so you want all the good parts from both DHCPv6 and SLAAC without sacrificing anything. Understandable :-) I'm still not convinced that it is a good idea to assign immedietaly deprecated addresses. The 1 second change of preferred source address every T1 seconds is likely to break stuff far more times than an occasional wan link failover. Applications tend to associate sessions with IP addresses, grouping tcp connections from the same address into a session. Load balancers try hard to redirect you to the same server, but don't necessarily understand that you may use several different source addresses. Regularily switching the preferred source address like that is bad. And wrt the fear of sudden renumbering: The upstrem source, where you get these addresses assigned, will include lifetimes. Why don't you reuse those (after some basic sanitation)? If the problem is that the upstream lies to you, then I suggest fixing that instead. We do propagate them as-is through RAs. However imagine manual or automatic failover to a different ISP / connection or simply an ISP doing 6rd where your IPv6 prefix is mapped from your IPv4-address and th connection flaps and you get a different v4-address or a VPN-connection being brought up or down. In all these scenarios there needs to be a way to tell clients to stop using an address for global traffic near instantaneously otherwise they might lose connectivity. Those use cases are broken by design. Don't get me started on 6rd :-) But they should of course be supported as smoothly as possible despite the inherent flaws. One option would be prefix translation, possibly with ULA addresses on the lan. Has this been considered? It would avoid the need to renumber the lan at all. Please also note that the use cases break connectivity whether you have an OpenWRT router in the path or not. ISPs will hopefully realize that and
[OpenWrt-Devel] [PATCH] gemini: fix usb driver compilation on 3.18
Signed-off-by: Roman Yeryomin ro...@advem.lv
---
target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c
b/target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c
index 4d95f2e..0717abc 100644
--- a/target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c
+++ b/target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c
@@ -206,8 +206,8 @@ static int fotg2_ehci_probe(struct platform_device *pdev)
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
- hcd-regs = devm_request_and_ioremap(pdev-dev, res);
- if (!hcd-regs) {
+ hcd-regs = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(hcd-regs)) {
err = -ENOMEM;
goto err_put_hcd;
}
--
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] adding seccomp and service jailing to procd
On 27/03/2015 13:45, Etienne Champetier wrote: Hi, 2015-03-27 10:42 GMT+01:00 John Crispin blo...@openwrt.org mailto:blo...@openwrt.org: OpenWrt service hardening and jailing = ... If there are features that we are not aware of yet or that we forgot to list, then please let us know about them. Comments and ideas are welcome ... ___ Thanks for this impressive piece of work!!! (awesome features and documentation) As you are working on Openwrt hardenning, what need to be done before activating option like STACKPROTECTOR, FORTIFY_SOURCE, RELRO_PARTIAL by default? (i'm already using them in all my builds, but i think everybody should use these options) i have added them to my list, will look at that in the next days Also i would love to hear the pro and cons of extending ubus vs switching to kdbus (i'm not trying to start a debate, and i really have no idea of the work involved, just curious) we need to discuss this internally. i have already started thinking about it.bu have no opinion yet John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] adding seccomp and service jailing to procd
Hi again, 2015-03-27 15:37 GMT+01:00 John Crispin blo...@openwrt.org: On 27/03/2015 13:45, Etienne Champetier wrote: Hi, 2015-03-27 10:42 GMT+01:00 John Crispin blo...@openwrt.org mailto:blo...@openwrt.org: OpenWrt service hardening and jailing = ... If there are features that we are not aware of yet or that we forgot to list, then please let us know about them. Comments and ideas are welcome ... ___ Thanks for this impressive piece of work!!! (awesome features and documentation) As you are working on Openwrt hardenning, what need to be done before activating option like STACKPROTECTOR, FORTIFY_SOURCE, RELRO_PARTIAL by default? (i'm already using them in all my builds, but i think everybody should use these options) i have added them to my list, will look at that in the next days Cool, quick note, RELRO_FULL can really hurt performance for non daemon stuff, like luci Also i would love to hear the pro and cons of extending ubus vs switching to kdbus (i'm not trying to start a debate, and i really have no idea of the work involved, just curious) we need to discuss this internally. i have already started thinking about it.bu have no opinion yet John ___ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ptrace and pselect
Are you still seeing this? Please note that the official BB build only has mosquitto 1.3.4. If you want to use 1.4, either use the feed: https://github.com/remakeelectric/owrt_pub_feeds or update to a CC based tree. Sorry, I've been on holidays, and only just saw this, but I'm the mosquitto maintainer, so I'd like to work out what's happening for you. I've not seen this error before, but it looks like you've managed to disable libpthread support somehow, which should be difficult/impossible to do. As it's selected by the target for ar71xx on the WE-IO board Cheers, Karl P Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: Hi all, I installed `mosquitto` via `opkg` on BarrierBreaker, and I am getting: root@WEIO:~# mosquitto_pub -h test.mosquitto.org -t temp/random -m 40 mosquitto_pub: can't resolve symbol 'pselect' Then I wnated to see what's happening, and I installed `strace`, but I am getting: root@WEIO:~# strace mosquitto_pub -h test.mosquitto.org -t temp/random -m 40 strace: can't resolve symbol 'ptrace' in lib 'strace'. strace: test_ptrace_setoptions_for_all: unexpected exit status 1 root@WEIO:~# Any ideas? BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Sent using Mailpile, Free Software from www.mailpile.is___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] adding seccomp and service jailing to procd
Hi John, On Fri, Mar 27, 2015 at 07:58:46PM +0100, John Crispin wrote: On 27/03/2015 19:56, Luka Perkov wrote: Hi John, On Fri, Mar 27, 2015 at 03:37:33PM +0100, John Crispin wrote: Also i would love to hear the pro and cons of extending ubus vs switching to kdbus (i'm not trying to start a debate, and i really have no idea of the work involved, just curious) we need to discuss this internally. i have already started thinking about it.bu have no opinion yet It would be better that such invasive changes that were done or are planned are communicated and explained before the actual push and not after. In this specific case a patch to either public or internal mailing list would not hurt. The breakage for some targets could have been easily avoided that way. Luka i communicated this to lots of people ahead and sent a mail to the internal list 1 day in advance, Ah, I see, I should be grateful that we had a full day. there was next to zero damaged caused by this. you should spend your time fixing up imx6, What is broken in imx6? The target is just not bumped to 3.18. rather than criticizing other for adding cool features. I did not say the features are not cool. Actually, I think they are cool. After my trip I'll take a closer look at the new features and I am really looking forward to making contributions! Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] adding seccomp and service jailing to procd
On 27/03/2015 19:56, Luka Perkov wrote: Hi John, On Fri, Mar 27, 2015 at 03:37:33PM +0100, John Crispin wrote: Also i would love to hear the pro and cons of extending ubus vs switching to kdbus (i'm not trying to start a debate, and i really have no idea of the work involved, just curious) we need to discuss this internally. i have already started thinking about it.bu have no opinion yet It would be better that such invasive changes that were done or are planned are communicated and explained before the actual push and not after. In this specific case a patch to either public or internal mailing list would not hurt. The breakage for some targets could have been easily avoided that way. Luka i communicated this to lots of people ahead and sent a mail to the internal list 1 day in advance, there was next to zero damaged caused by this. you should spend your time fixing up imx6, rather than criticizing other for adding cool features. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] adding seccomp and service jailing to procd
Hi John, On Fri, Mar 27, 2015 at 03:37:33PM +0100, John Crispin wrote: Also i would love to hear the pro and cons of extending ubus vs switching to kdbus (i'm not trying to start a debate, and i really have no idea of the work involved, just curious) we need to discuss this internally. i have already started thinking about it.bu have no opinion yet It would be better that such invasive changes that were done or are planned are communicated and explained before the actual push and not after. In this specific case a patch to either public or internal mailing list would not hurt. The breakage for some targets could have been easily avoided that way. Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] update libnetfilter_conntrack to version 1.0.4
This updates libnetfilter_conntrack to the latest stable version 1.0.4 which was released Aug-06-2013. Changeset is available here: http://git.netfilter.org/libnetfilter_conntrack/log/ Signed-off-by: Christian Mehlis christ...@m3hlis.de --- package/libs/libnetfilter-conntrack/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/libs/libnetfilter-conntrack/Makefile b/package/libs/libnetfilter-conntrack/Makefile index 4579a02..e60b59a 100644 --- a/package/libs/libnetfilter-conntrack/Makefile +++ b/package/libs/libnetfilter-conntrack/Makefile @@ -8,14 +8,14 @@ include $(TOPDIR)/rules.mk PKG_NAME:=libnetfilter_conntrack -PKG_VERSION:=1.0.3 +PKG_VERSION:=1.0.4 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:= \ http://www.netfilter.org/projects/libnetfilter_conntrack/files/ \ ftp://ftp.netfilter.org/pub/libnetfilter_conntrack/ -PKG_MD5SUM:=73394a3d8d0cfecc6abb6027b4792d52 +PKG_MD5SUM:=18cf80c4b339a3285e78822dbd4f08d7 PKG_MAINTAINER:=Jo-Philipp Wich j...@openwrt.org PKG_FIXUP:=autoreconf -- 2.4.0.rc0.16.g283cd32 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
