Re: [OpenWrt-Devel] Security Vulnerability Reporting and Database
Le mercredi 25 mars 2015 à 14:31 -0500, Eric Schultz a écrit : During the discussions for the OpenWireless/OpenWrt security hackathon in April, one of the participants asked if there's a way to report security vulnerabilities in OpenWrt. I didn't know of one so I figured I should ask. Is there a recommended process for reporting a security vulnerability in OpenWrt? +1. I am also interested in an answer. Gnutella ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
If anyone wants to organize a BattleMesh event in Hungary, I would vote for that and have a near industrial amount of various compatible hardware standing by! On Wed, Mar 25, 2015 at 9:36 PM, Gergely Kiss mail.g...@gmail.com wrote: On 03/21/2015 08:51 PM, valent.turko...@gmail.com wrote: On 10 March 2015 at 21:26, Gergely Kiss mail.g...@gmail.com wrote: Hi Valent, first of all, I strongly disagree with people claiming that OpenWrt sucks because it doesn't. For me it rather looks like a well-maintained, rapidly improving project with a great number of actively supported hardware and quite a few people contributing to snip Do you think OpenWrt sucks? Then stop complaining and do something to make it better. It's that simple. Cheers, Gergely Hi Gergely, thanks for your reply and for your contribution to OpenWrt. But I have to ask - have you read my message apart from headline? If you have read it you will see that I'm defending OpenWrt and I definitely don't think it sucks! Hi Valent, I'm sorry, that paragraph wasn't addressed to you but to people claiming that OpenWrt sucks. Of course, I have read your message, I never reply to a message I haven't read in its entirety. I contribute to it everyday, but not (yet) as a developer but as advanced user, forum and wiki contributor and have organized multiple workshops all accross Croatia, Serbia and Macedonia to get people to use OpenWrt. That's great! Any plans to come to Hungary someday? :) Cheers, Valent. ___ 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] Security Vulnerability Reporting and Database
Hi. During the discussions for the OpenWireless/OpenWrt security hackathon in April, one of the participants asked if there's a way to report security vulnerabilities in OpenWrt. I didn't know of one so I figured I should ask. Is there a recommended process for reporting a security vulnerability in OpenWrt? I suggest to send such reports to openwrt-hack...@lists.openwrt.org. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Rebuilding for specific hardware, example ar71xx/image for TP-Link TL-WR841ND
Le mercredi 25 mars 2015 à 11:43 -0400, John Szakmeister a écrit : Why not just use: ./scripts/config/conf --savedefconfig=config.seed Config.in When building systems for release, one has to be very careful for security. IMHO, I would not leave a toolchain and configuration on a build server and change it from time to time. If this is the way OpenWRT is built, there is a higher risk for an attacker to modify the build environment and/or binaries. I prefer: build script = debian chroot = config = toolchain = compilation I will enquire more about conf --savedefconfig=config.seed Config.in to see if it suits my needs. From a first approach, I prefer to use a small script which turns on/off features and builds a .config from scratch. The only thing is that I need to keep the build script. But this has to be studies in more details as I am new in the community and have to learn. Thanks for pointing it out. There is a lot to learn about OpenWRT, which seems a very rich environment. 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] DHCPv6 flash renumbering patches with HE tunnel breaks
Hello Arjen, most likely, your DHCPv6 client implementation is faulty and you should probably file a bug for more than one reason. 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. Besides you also get addresses with higher values for preferred lifetime using RAs so you always have usable IPv6 addresses, so if your network-manager / OS behaves sanely you shouldn't have any issues. A work-around for this is setting: option ra_management 0 in the lan-section of /etc/config/dhcp which will cause most clients to not use DHCPv6 and rely on RAs only. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] EAP-TLS / EAP-TTLS PAP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Maybe you have been at the Chaos Communication Congress in Germany the last years. Then may you saw the WPA2 802.1X encrypted /public open wireless access points/, where a user/client can choose their own (random) name/password credentials. https://events.ccc.de/congress/2014/wiki/Static:Network#WPA2_802.1X.2C_e ncryption (CA-CERT, sha-1 fingerprint: 4C:11:E8:BA:DE:12:79:08:45:4F:53:33:1F:E9:B9:60:56:1D:63:9F) Due to popular demand (and with security in mind) we provide WPA2 802.1X. This will encrypt your traffic, preventing attackers from sniffing your data. Keep in mind that this won't protect you from other network attacks and you should still be aware that you are at a hacker conference! Your link layer should be secure if you do certificate checking (see below). Back in 2010 and 2012 one paper and some emails claim, that it is possible to patch hostapd to not have the need for client certificates. /* Mails from californiajack at tormail.org via [OpenWireless Tech]) */ So what now? There is a project ( https://github.com/OpenSecurityResearch/hostapd-wpe ) where people have patched and open sourced hostapd to do not request client certificates (and other things). So far so good, there are patches. But I'm not a C/C++ hacker and I will not touch TLS and other critical encryption and fuck it up to compile my version of hostapd. If I want to use it, I want to use a well maintained version, it there is any. (?!) However, I saw that all this stuff is specified: http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TLS and there is FreeRadius which will do similar stuff, I heard about. I was curious in that technology cause it would be a nice thing for our wireless community network. The sad fact today is, that we do not have wireless security because in a flat organised community you will not have central credentials (that is stupid and not open) and you will not have a central comity which verifies user client certificates, which is even more a closed system and can restrict user access (realy realy bad!). But if a user could choose his own (fake) credentials we have some security against passive network sniffing. As you may know that there are hunderds of shitty mobile apps with broken api-calls and poor tls/ssl quality. We don't have to put our users at unnecessary risks. We can not expect that every user can use end-to-end vpn connections. Further, if we had an active network scanner within our infrastructure we had an other problem. ... 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? Thanks for comments and pointers! Greetings, Bernd - -- Bernd Naumann be...@kr217.de PGP: 0xA150A04F via pool.sks-keyservers.net XMPP: b...@weimarnetz.de -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJVFAqUAAoJEEYW3OihUKBPOLkQAIHn8ovj3qEIjKnQ5YGLQr/Z rttoYAeC1uZePbVTCe5c/DOZVvDp0tn174Eu8itKA5E+NUOJ4RjQ/Xr9tWdtQme/ kXnJoYS15+m2tivRbpYvHGTV47bWYYEBMg+P0Wg0XOHsy580CT88ZuBZDL1FlTcr VjwibSwoNT7ZVO7UemrBmt8LNaItgNVwyhID6Eo//JyTWft2idPA9X4DPiMYndJG cE3UwBcq5nqTh0whZXsUCmcjWzZ91hV+D2BfDf6rsWCIzdoFA+42HqwX4RSgJaQn TCQeQYZpYgeysqBoAuetJc2AEGHRA3Vt+pxuX2HCerfk+pWU1F4ZCKRQ1q1u7XQk p3ZD8tSofLZjmyXxAMrWJnNk74T1qLF/YuS2g5ms9kKIWzre6xOQ7Exe5yn0W+Mq uKLexEI6BAJtDEiGKRMtn7tw70v6G0lhNtrbebgIULbHpaY+ToxozksGxUtyfbQ7 PnTnGqk2HS0XHn7noZgzqbLh6X9MniGrAEU3zJkhdcbAVTF//0lC/YUcrQKlOX5u dpvcFu6FzvLUzncRXIJVjovuYzGpkP054fY379spSGyZo7/MDuUkKwT3bOYbf7oL gOs0OA4e9RfIEvy0avR9SgR02n+w/QTSiqz3bl6UdZ5TTO810LXK8FpJMZV2gJcz WdUg2cAuqsEC+7vp27v8 =8QL5 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Updating dnsmasq 2.73rc1 new dnssec timestamp checking option
Hi All, New here, new to openwrt, not really a developer, more a willing idiot. Appreciate your help, patience, guidance etc. I've been following dnsmasq git master for a year or two on other router firmware projects and have always tried to keep them up to date. I'd like to do the same with/for openwrt. I've a local clone of openwrt following CC master (bleeding edge) and have updated the dnsmasq package makefile to pull RC1, removed unneeded patches and got something compiling working (on one box, one platform - yeah huge test base!) I'd like to contribute these changes but I'm very unsure how to go about it. There have been quite a few little fixes and improvements gone into dnsmasq 2.73 (having gone through a number of test revisions) One particular feature relates to the 'dnssec validation/time not set/lookup ntp server' chicken egg problem. Simon Kelly took the seed of an idea that I had, ran with it, greatly improved it and came up with a 'timestamp file' which helps dnsmasq determine automatically whether the current time is to be considered 'good' or not and hence whether to check dnssec certificate time validity or not. I personally think this is the final hurdle removed with regard to getting dnssec validation to an easily deployable state when using dnsmasq (luci needs a few extra options though - I've had ideas for that too) I've updated the package dnsmasq init script so that it uses this new option if dnssec is enabled. The location of the timestamp file is currently '/etc/dnsmasq.d/dnsmasq.timestamp' but is this the best location for it? The file needs to survive reboots and a further complication is that it must be r/w by the unprivileged user that dnsmasq drops to (nobody) hence the new directory and init script doing chown nobody:nogroup /etc/dnsmasq.d (I can't work out how to do that as part of the image build process) Your advice, help appreciated. Kevin 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] DHCPv6 flash renumbering patches with HE tunnel breaks
Citeren Steven Barth cy...@openwrt.org: Hello Arjen, most likely, your DHCPv6 client implementation is faulty and you should probably file a bug for more than one reason. In that case, I have a lot of bug reports to file, because none of the DHCPv6 clients I tried were happy with preferred lifetimes of 1 second on their leases (which includes Windows 7, 8.1 and openSUSE 13.2). Removing lines 813 if (!a-accept_reconf iface-managed RELAYD_MANAGED_NO_AFLAG 814 addrs[i].prefix == 64) 815 n.preferred = htonl(1); and all were good again. I'm still looking for why setting a preferred lifetime of 1 second is not going to render the IPv6 address that is provided in the reply by odhcpd useless. 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. I'm not sure if preferred lifetime T1 and/or T2 is expected behavior of the DHCPv6 server. One second after receiving the address, clients can't use the address for new connections, but also can't renew (until T1) or rebind (until T2). And that's precisely what I'm seeing here. Note that the continuous renewals were only with the first patch applied, for the most recent version of odhcpd the clients will just give up on the DHCPv6 address after one second and use SLAAC instead. But this is not what I want (and I can't switch off SLAAC either, since I have also clients to support which don't do DHCPv6). Besides you also get addresses with higher values for preferred lifetime using RAs so you always have usable IPv6 addresses, so if your network-manager / OS behaves sanely you shouldn't have any issues. They don't have an issue with IPv6 connectivity, its the source address that is used *I* have a problem with. A work-around for this is setting: option ra_management 0 in the lan-section of /etc/config/dhcp which will cause most clients to not use DHCPv6 and rely on RAs only. This is not an option, as the whole purpose of using DHCPv6 for address configuration is to give clients a fixed IPv6 address. This has worked correctly since Barrier Breaker was released, I see no reason why it no longer should. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Alfa Hornet-UB no longer supports OpenWrt?
I've been buying batches of Hornet-UB based routers with OpenWrt preinstalled from data-alliance.net for a while now; today I got a message from them that they were unable to install the OpenWrt image they'd been using on any of the Hornet-UB boards in the latest batch they received from Alfa. From my initial discussion with them, it sounds like they were able to TFTP the image and write it to flash, but it didn't boot as expected after the reset command was issued in U-Boot. So we're trying to figure out what's going wrong right now; did Alfa make some change to the hardware in `recent' history (recent being a relative term--bearing in mind that sometimes it can take years to run through old stock, depending on how many old units exist and the rate at which they get sold...)? Something like...: - different flash layout? - different components? - something else? Anything that would prevent the early Attitude Adjustment (pre-release) builds from booting on the newer Hornet-UB boards? And if there has been some sort of change, do newer builds of OpenWrt work on these boards? I notice that there are actually two hornet-ub images for download these days--one of which is for hornet-ub-x2? What is that? There's no mention of it on in the wiki AFAICT, and I'm having trouble finding useful pages with that name on it elsewhere on the web -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] synchronous network reload/restart
Hi. Is there any way to synchronously (blocking) reload or restart the network configuration? ubus call network reload (or restart) returns immediately, and the re-configuration happens asynchronously in the background. I'd like the command to block or otherwise wait until the reconfiguration is complete. Any way to achieve this? No. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] synchronous network reload/restart
Hello, Is there any way to synchronously (blocking) reload or restart the network configuration? ubus call network reload (or restart) returns immediately, and the re-configuration happens asynchronously in the background. I'd like the command to block or otherwise wait until the reconfiguration is complete. Any way to achieve this? Thanks, bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] seccomp patch lead to build failures
On 26/03/2015 19:17, Dirk Neukirchen wrote: procd: add jail support 45010 leads to build errors on some? arches On omap I get: /jail/seccomp-bpf.h:72:3: error: #w$ # warning Platform does not support seccomp filter yet which fails the build completely (-Werror issue) I think there are some issues with other arch/detection when building libseccomp especially for PowerPC arch: - http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/ because I think atm there is no powerpc support: I looked in: https://github.com/seccomp/libseccomp/tree/master/src Hi Dirk, pushed a fix, please test it and let me know if the problem is gone John ___ 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: This breaks clients that need fixed IPs (in my case, mostly webmail clients). I wonder why they are so sensitive to source-address changes since their old address is still valid and not deprecated so there is no need to switch. Webmail clients usually don't keep a connection open to the server, hence every connection is a new one. The webmail server only sees the source IP, so even if the DHCPv6 address is still valid for the client, a re-login is needed because the source IP changes. I would gladly send the DHCPv6 address with 0 preferred lifetime but Apple's DHCPv6 client has issues and discard addresses therefore the 1. I could create a patch for this, but for now I consider this a regression, rather than a feature that needs to be configurable. I fail to understand the reasons why this change, which deliberately breaks the outgoing addresses (even if only momentarily) was introduced. The reason for this change is that no host seems to support DHCPv6 reconfiguration so we cannot update clients whenever we see fit (e.g. ISP goes down / is switched / designates a different PD). Which means that in absence of that in worst case client connectivity is lost for T1 seconds. I don't see how this fixes things then. When ra_management is '2' you'd still run into the exact same problem (just without the fallback to SLAAC). In contrast, if the ip6prefix is configured statically (as in my case), there is no chance this will ever happen, since changes will never happen unexpectedly. I think this would be much better fixed by making the client renew its lease more frequently (by lowering the valid and preferred lifetimes). The present fix will also not work for anthing else than a /64. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] seccomp patch lead to build failures
procd: add jail support 45010 leads to build errors on some? arches On omap I get: /jail/seccomp-bpf.h:72:3: error: #w$ # warning Platform does not support seccomp filter yet which fails the build completely (-Werror issue) I think there are some issues with other arch/detection when building libseccomp especially for PowerPC arch: - http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/ because I think atm there is no powerpc support: I looked in: https://github.com/seccomp/libseccomp/tree/master/src ___ 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
This breaks clients that need fixed IPs (in my case, mostly webmail clients). I wonder why they are so sensitive to source-address changes since their old address is still valid and not deprecated so there is no need to switch. I would gladly send the DHCPv6 address with 0 preferred lifetime but Apple's DHCPv6 client has issues and discard addresses therefore the 1. I could create a patch for this, but for now I consider this a regression, rather than a feature that needs to be configurable. I fail to understand the reasons why this change, which deliberately breaks the outgoing addresses (even if only momentarily) was introduced. The reason for this change is that no host seems to support DHCPv6 reconfiguration so we cannot update clients whenever we see fit (e.g. ISP goes down / is switched / designates a different PD). Which means that in absence of that in worst case client connectivity is lost for T1 seconds. 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 26/03/2015 18:36, Arjen de Korte wrote: Citeren Steven Barth cy...@openwrt.org: In that case, I have a lot of bug reports to file, because none of the DHCPv6 clients I tried were happy with preferred lifetimes of 1 second on their leases (which includes Windows 7, 8.1 and openSUSE 13.2). Sorry, I cannot confirm this. I just tried it with both Windows 8.1 and Debian testing (w/ network-manager) both didn't react strangely or tried to renew the lease every second. Connectivity was okay. The constant refreshes were only with the first patch that introduced this behavior (sorry for the confusion), with the current odhcpd clients will indeed not attempt to renew continuously. But they won't be able to use the address provided by DHCPv6 for outgoing connections either. They will use the address from SLAAC most of the time, but at the time the lease is renewed, switch to the DHCPv6 address and back again to SLAAC 1 second later. Although the window of opportunity for this to happen may seem to be small, it is enough for webmail clients that happen to check for the source IP to require logging in again when this happens (twice in a row actually, as the source IP changes twice). Besides you also get addresses with higher values for preferred lifetime using RAs so you always have usable IPv6 addresses, so if your network-manager / OS behaves sanely you shouldn't have any issues. They don't have an issue with IPv6 connectivity, its the source address that is used *I* have a problem with. Unless you disable RAs there is no way to tell the client which source address to pick anyway. If some OS use the DHCPv6 addresses by default then thats by chance. True. But most OSes will pick either one and will stick to that. Windows seems to favor DHCPv6, while Linux by defaults selects SLAAC then. Both are OK with me. The problem I have with the current implementation in odhcpd, is that systems favoring DHCPv6 will switch between the two. A work-around for this is setting: option ra_management 0 in the lan-section of /etc/config/dhcp which will cause most clients to not use DHCPv6 and rely on RAs only. This is not an option, as the whole purpose of using DHCPv6 for address configuration is to give clients a fixed IPv6 address. This has worked correctly since Barrier Breaker was released, I see no reason why it no longer should. That still works. The client will just not use the address for outgoing traffic. This breaks clients that need fixed IPs (in my case, mostly webmail clients). I'm fine with making this configurable (current behavior as default) though and would welcome a patch for this. I could put it on my todo but don't really know when I have the time to deal with this. I could create a patch for this, but for now I consider this a regression, rather than a feature that needs to be configurable. I fail to understand the reasons why this change, which deliberately breaks the outgoing addresses (even if only momentarily) was introduced. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel I know this isn't ideal and I've come in late to this discussion, have you considered using the DHCPv6 functionality in dnsmasq? I have strenuously avoided radvd odhcpv6 in preference for keeping everything in one place. I shall now return to my cupboard :-) 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] seccomp patch lead to build failures
On 26/03/2015 19:47, Kevin Darbyshire-Bryant wrote: On 26/03/2015 18:39, John Crispin wrote: On 26/03/2015 19:17, Dirk Neukirchen wrote: procd: add jail support 45010 leads to build errors on some? arches On omap I get: /jail/seccomp-bpf.h:72:3: error: #w$ # warning Platform does not support seccomp filter yet which fails the build completely (-Werror issue) I think there are some issues with other arch/detection when building libseccomp especially for PowerPC arch: - http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/ because I think atm there is no powerpc support: I looked in: https://github.com/seccomp/libseccomp/tree/master/src ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel fix coming up, just started a ppc build to verify ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Hi John, Earlier today I was working on some dnsmasq changes. When I pulled the latest updates I was surprised by the (new to me) 'jail' related updates. Is there any documentation that I may be able to read to understand how I can update my latest changes and retain compatibility? upcoming, i'll write some docs tomorrow I was more than surprised to find dnsmasq running as root :-) I'm should not be will have a look at that guessing this is some sort of 'sandboxing'/chroot/virtual filesystem type arrangement but I'm guessing. yes using namespaces and a staged readonly fs and with seccomp, more features like cgroups etc coming up. Many thanks, Kevin ___ 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] seccomp patch lead to build failures
On 26/03/2015 19:17, Dirk Neukirchen wrote: procd: add jail support 45010 leads to build errors on some? arches On omap I get: /jail/seccomp-bpf.h:72:3: error: #w$ # warning Platform does not support seccomp filter yet which fails the build completely (-Werror issue) I think there are some issues with other arch/detection when building libseccomp especially for PowerPC arch: - http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/ because I think atm there is no powerpc support: I looked in: https://github.com/seccomp/libseccomp/tree/master/src ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel fix coming up, just started a ppc build to verify ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] seccomp patch lead to build failures
On 26/03/2015 19:27, John Crispin wrote: Hi John, Earlier today I was working on some dnsmasq changes. When I pulled the latest updates I was surprised by the (new to me) 'jail' related updates. Is there any documentation that I may be able to read to understand how I can update my latest changes and retain compatibility? upcoming, i'll write some docs tomorrow I was more than surprised to find dnsmasq running as root :-) I'm should not be will have a look at that guessing this is some sort of 'sandboxing'/chroot/virtual filesystem type arrangement but I'm guessing. yes using namespaces and a staged readonly fs and with seccomp, more features like cgroups etc coming up. Many thanks, Kevin Thanks John. Very much appreciated. Will look out for the docs. 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] [PATCH 3/3] rb532: switch to 3.18
Signed-off-by: Roman Yeryomin ro...@advem.lv --- target/linux/rb532/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/rb532/Makefile b/target/linux/rb532/Makefile index 0a6bd71..e5c6ad7 100644 --- a/target/linux/rb532/Makefile +++ b/target/linux/rb532/Makefile @@ -11,7 +11,7 @@ BOARD:=rb532 BOARDNAME:=Mikrotik RouterBoard 532 FEATURES:=pci targz -KERNEL_PATCHVER:=3.14 +KERNEL_PATCHVER:=3.18 include $(INCLUDE_DIR)/target.mk DEFAULT_PACKAGES += wpad-mini kmod-ath5k kmod-input-rb532 -- 2.1.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] syslog: use appropriate levels for logging
Signed-off-by: Christian Mehlis christ...@m3hlis.de
---
kmodloader.c | 2 +-
log/logread.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kmodloader.c b/kmodloader.c
index 8f41e74..387678a 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -751,7 +751,7 @@ static int main_loader(int argc, char **argv)
if (scan_module_folders())
return -1;
- syslog(0, kmodloader: loading kernel modules from %s\n, path);
+ syslog(LOG_INFO, kmodloader: loading kernel modules from %s\n, path);
if (glob(path, gl_flags, NULL, gl) 0)
goto out;
diff --git a/log/logread.c b/log/logread.c
index a7ab567..871cd5b 100644
--- a/log/logread.c
+++ b/log/logread.c
@@ -79,7 +79,7 @@ static void log_handle_reconnect(struct uloop_timeout
*timeout)
uloop_timeout_set(retry, 1000);
} else {
uloop_fd_add(sender, ULOOP_READ);
- syslog(0, Logread connected to %s:%s\n, log_ip, log_port);
+ syslog(LOG_INFO, Logread connected to %s:%s\n, log_ip,
log_port);
}
}
@@ -154,7 +154,7 @@ static int log_notify(struct blob_attr *msg)
err = send(sender.fd, buf, strlen(buf), 0);
if (err 0) {
- syslog(0, failed to send log data to %s:%s via %s\n,
+ syslog(LOG_INFO, failed to send log data to %s:%s via
%s\n,
log_ip, log_port, (log_udp) ? (udp) :
(tcp));
uloop_fd_delete(sender);
close(sender.fd);
--
2.3.4.263.gf53fc38
___
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: In that case, I have a lot of bug reports to file, because none of the DHCPv6 clients I tried were happy with preferred lifetimes of 1 second on their leases (which includes Windows 7, 8.1 and openSUSE 13.2). Sorry, I cannot confirm this. I just tried it with both Windows 8.1 and Debian testing (w/ network-manager) both didn't react strangely or tried to renew the lease every second. Connectivity was okay. The constant refreshes were only with the first patch that introduced this behavior (sorry for the confusion), with the current odhcpd clients will indeed not attempt to renew continuously. But they won't be able to use the address provided by DHCPv6 for outgoing connections either. They will use the address from SLAAC most of the time, but at the time the lease is renewed, switch to the DHCPv6 address and back again to SLAAC 1 second later. Although the window of opportunity for this to happen may seem to be small, it is enough for webmail clients that happen to check for the source IP to require logging in again when this happens (twice in a row actually, as the source IP changes twice). Besides you also get addresses with higher values for preferred lifetime using RAs so you always have usable IPv6 addresses, so if your network-manager / OS behaves sanely you shouldn't have any issues. They don't have an issue with IPv6 connectivity, its the source address that is used *I* have a problem with. Unless you disable RAs there is no way to tell the client which source address to pick anyway. If some OS use the DHCPv6 addresses by default then thats by chance. True. But most OSes will pick either one and will stick to that. Windows seems to favor DHCPv6, while Linux by defaults selects SLAAC then. Both are OK with me. The problem I have with the current implementation in odhcpd, is that systems favoring DHCPv6 will switch between the two. A work-around for this is setting: option ra_management 0 in the lan-section of /etc/config/dhcp which will cause most clients to not use DHCPv6 and rely on RAs only. This is not an option, as the whole purpose of using DHCPv6 for address configuration is to give clients a fixed IPv6 address. This has worked correctly since Barrier Breaker was released, I see no reason why it no longer should. That still works. The client will just not use the address for outgoing traffic. This breaks clients that need fixed IPs (in my case, mostly webmail clients). I'm fine with making this configurable (current behavior as default) though and would welcome a patch for this. I could put it on my todo but don't really know when I have the time to deal with this. I could create a patch for this, but for now I consider this a regression, rather than a feature that needs to be configurable. I fail to understand the reasons why this change, which deliberately breaks the outgoing addresses (even if only momentarily) was introduced. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] seccomp patch lead to build failures
On 26/03/2015 18:39, John Crispin wrote: On 26/03/2015 19:17, Dirk Neukirchen wrote: procd: add jail support 45010 leads to build errors on some? arches On omap I get: /jail/seccomp-bpf.h:72:3: error: #w$ # warning Platform does not support seccomp filter yet which fails the build completely (-Werror issue) I think there are some issues with other arch/detection when building libseccomp especially for PowerPC arch: - http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/libseccomp/compile.txt - http://buildbot.openwrt.org:8010/broken_packages/mpc83xx/ because I think atm there is no powerpc support: I looked in: https://github.com/seccomp/libseccomp/tree/master/src ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel fix coming up, just started a ppc build to verify ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Hi John, Earlier today I was working on some dnsmasq changes. When I pulled the latest updates I was surprised by the (new to me) 'jail' related updates. Is there any documentation that I may be able to read to understand how I can update my latest changes and retain compatibility? I was more than surprised to find dnsmasq running as root :-) I'm guessing this is some sort of 'sandboxing'/chroot/virtual filesystem type arrangement but I'm guessing. Many thanks, Kevin 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] DHCPv6 flash renumbering patches with HE tunnel breaks
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. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] rb532: add 3.18 support
Signed-off-by: Roman Yeryomin ro...@advem.lv --- target/linux/rb532/config-3.18 | 146 + .../rb532/patches-3.18/001-cmdline_hack.patch | 20 +++ .../rb532/patches-3.18/002-rb532_nand_fixup.patch | 47 +++ ...tion_info-rename-rootfs-to-rootfs_onboard.patch | 11 ++ 4 files changed, 224 insertions(+) create mode 100644 target/linux/rb532/config-3.18 create mode 100644 target/linux/rb532/patches-3.18/001-cmdline_hack.patch create mode 100644 target/linux/rb532/patches-3.18/002-rb532_nand_fixup.patch create mode 100644 target/linux/rb532/patches-3.18/004-rb532_partition_info-rename-rootfs-to-rootfs_onboard.patch diff --git a/target/linux/rb532/config-3.18 b/target/linux/rb532/config-3.18 new file mode 100644 index 000..246c5d2 --- /dev/null +++ b/target/linux/rb532/config-3.18 @@ -0,0 +1,146 @@ +CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y +CONFIG_ARCH_DISCARD_MEMBLOCK=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_REQUIRE_GPIOLIB=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ATA=y +CONFIG_BLK_DEV_SD=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_CEVT_R4K=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_CPU_GENERIC_DUMP_TLB=y +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPS32_R1=y +CONFIG_CPU_MIPSR1=y +CONFIG_CPU_R4K_CACHE_TLB=y +CONFIG_CPU_R4K_FPU=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRC16=y +CONFIG_CRYPTO_CRC32C=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CSRC_R4K=y +CONFIG_DMA_NONCOHERENT=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +CONFIG_EXT4_FS=y +CONFIG_FS_MBCACHE=y +CONFIG_GENERIC_ATOMIC64=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_IO=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_DEVRES=y +CONFIG_GPIO_SYSFS=y +CONFIG_HARDWARE_WATCHPOINTS=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT=y +# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set +CONFIG_HAVE_ARCH_JUMP_LABEL=y +CONFIG_HAVE_ARCH_KGDB=y +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set +CONFIG_HAVE_C_RECORDMCOUNT=y +CONFIG_HAVE_DEBUG_KMEMLEAK=y +CONFIG_HAVE_DMA_API_DEBUG=y +CONFIG_HAVE_DMA_ATTRS=y +CONFIG_HAVE_DYNAMIC_FTRACE=y +CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y +CONFIG_HAVE_FUNCTION_TRACER=y +CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_HAVE_GENERIC_HARDIRQS=y +CONFIG_HAVE_IDE=y +CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MEMBLOCK_NODE_MAP=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y +CONFIG_HAVE_NET_DSA=y +CONFIG_HAVE_OPROFILE=y +CONFIG_HAVE_PERF_EVENTS=y +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_HW_HAS_PCI=y +CONFIG_HW_RANDOM=y +CONFIG_HZ=250 +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +CONFIG_HZ_PERIODIC=y +CONFIG_IMAGE_CMDLINE_HACK=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_IRQ_CPU=y +CONFIG_IRQ_FORCED_THREADING=y +CONFIG_IRQ_WORK=y +CONFIG_JBD2=y +CONFIG_KEXEC=y +CONFIG_KORINA=y +CONFIG_LEDS_MIKROTIK_RB532=y +CONFIG_MIKROTIK_RB532=y +CONFIG_MIPS=y +# CONFIG_MIPS_HUGE_TLB_SUPPORT is not set +CONFIG_MIPS_L1_CACHE_SHIFT=4 +# CONFIG_MIPS_MACHINE is not set +CONFIG_MIPS_MT_DISABLED=y +CONFIG_MODULES_USE_ELF_REL=y +CONFIG_MTD_BLOCK2MTD=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +# CONFIG_MTD_CFI_AMDSTD is not set +CONFIG_MTD_CFI_GEOMETRY=y +# CONFIG_MTD_CFI_INTELEXT is not set +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_NAND_PLATFORM=y +CONFIG_MTD_PHYSMAP=y +# CONFIG_MTD_ROOTFS_ROOT_DEV is not set +CONFIG_MTD_ROOTFS_SPLIT=y +# CONFIG_MTD_SM_COMMON is not set +# CONFIG_MTD_SPLIT is not set +CONFIG_NEED_DMA_MAP_STATE=y +CONFIG_NEED_PER_CPU_KM=y +CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y +CONFIG_PAGEFLAGS_EXTENDED=y +CONFIG_PATA_RB532=y +CONFIG_PCI=y +CONFIG_PCI_DISABLE_COMMON_QUIRKS=y +CONFIG_PCI_DOMAINS=y +CONFIG_PERF_USE_VMALLOC=y +# CONFIG_PREEMPT_RCU is not set +CONFIG_RC32434_WDT=y +# CONFIG_RCU_STALL_COMMON is not set +CONFIG_SCSI=y +# CONFIG_SCSI_LOWLEVEL is not set +# CONFIG_SCSI_MULTI_LUN is not set +# CONFIG_SCSI_PROC_FS is not set +# CONFIG_SWAP is not set +CONFIG_SWAP_IO_SPACE=y +CONFIG_SYS_HAS_CPU_MIPS32_R1=y +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y +CONFIG_TICK_CPU_ACCOUNTING=y +CONFIG_UIDGID_CONVERTED=y +CONFIG_USB_ARCH_HAS_XHCI=y +CONFIG_VIA_RHINE=y +CONFIG_VIA_RHINE_MMIO=y +CONFIG_YAFFS_9BYTE_TAGS=y +# CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED is not set +CONFIG_YAFFS_AUTO_YAFFS2=y +# CONFIG_YAFFS_DISABLE_BACKGROUND is not set +# CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is not set +# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set +# CONFIG_YAFFS_EMPTY_LOST_AND_FOUND is not set +CONFIG_YAFFS_FS=y +CONFIG_YAFFS_XATTR=y +CONFIG_YAFFS_YAFFS1=y +CONFIG_YAFFS_YAFFS2=y
[OpenWrt-Devel] [PATCH 2/3] rb532: align partitions to 128KB
because block2mtd wants erasesize must be a divisor of device size since 3.15
Signed-off-by: Roman Yeryomin ro...@advem.lv
---
target/linux/rb532/image/Makefile | 10 +-
target/linux/rb532/image/gen_image.sh | 3 ++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/target/linux/rb532/image/Makefile
b/target/linux/rb532/image/Makefile
index 706c768..284b3d4 100644
--- a/target/linux/rb532/image/Makefile
+++ b/target/linux/rb532/image/Makefile
@@ -63,10 +63,18 @@ define Image/cmdline/yaffs2
root=/dev/mtdblock1 rootfstype=yaffs2
endef
+define Image/Build/squashfs
+ $(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
+endef
+
define Image/Build
+ $(call Image/Build/$(1),$(1))
$(CP) $(KDIR)/vmlinux.elf $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel
$(STAGING_DIR_HOST)/bin/patch-cmdline
$(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel '$(strip $(call Image/cmdline/$(1))) '
- ./gen_image.sh $(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).bin 4
$(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel $(CONFIG_TARGET_ROOTFS_PARTSIZE)
$(KDIR)/root.$(1)
+ ./gen_image.sh $(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).bin \
+ 4 $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel \
+ $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(KDIR)/root.$(1) \
+ 128
endef
$(eval $(call BuildImage))
diff --git a/target/linux/rb532/image/gen_image.sh
b/target/linux/rb532/image/gen_image.sh
index 8875834..a2d6f40 100755
--- a/target/linux/rb532/image/gen_image.sh
+++ b/target/linux/rb532/image/gen_image.sh
@@ -4,11 +4,12 @@ KERNELSIZE=$2
KERNELIMAGE=$3
ROOTFSSIZE=$4
ROOTFSIMAGE=$5
+ALIGN=$6
rm -f $OUTPUT
# create partition table
-set `ptgen -o $OUTPUT -h 16 -s 32 -t 0x27 -p ${KERNELSIZE}m -t 0x83 -p
${ROOTFSSIZE}m`
+set `ptgen -o $OUTPUT -h 16 -s 32 -l ${ALIGN} -t 0x27 -p ${KERNELSIZE}m -t
0x83 -p ${ROOTFSSIZE}m`
KERNELOFFSET=$(($1 / 512))
ROOTFSOFFSET=$(($3 / 512))
--
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] DHCPv6 flash renumbering patches with HE tunnel breaks
In that case, I have a lot of bug reports to file, because none of the DHCPv6 clients I tried were happy with preferred lifetimes of 1 second on their leases (which includes Windows 7, 8.1 and openSUSE 13.2). Sorry, I cannot confirm this. I just tried it with both Windows 8.1 and Debian testing (w/ network-manager) both didn't react strangely or tried to renew the lease every second. Connectivity was okay. Besides you also get addresses with higher values for preferred lifetime using RAs so you always have usable IPv6 addresses, so if your network-manager / OS behaves sanely you shouldn't have any issues. They don't have an issue with IPv6 connectivity, its the source address that is used *I* have a problem with. Unless you disable RAs there is no way to tell the client which source address to pick anyway. If some OS use the DHCPv6 addresses by default then thats by chance. A work-around for this is setting: option ra_management 0 in the lan-section of /etc/config/dhcp which will cause most clients to not use DHCPv6 and rely on RAs only. This is not an option, as the whole purpose of using DHCPv6 for address configuration is to give clients a fixed IPv6 address. This has worked correctly since Barrier Breaker was released, I see no reason why it no longer should. That still works. The client will just not use the address for outgoing traffic. I'm fine with making this configurable (current behavior as default) though and would welcome a patch for this. I could put it on my todo but don't really know when I have the time to deal with this. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
