Re: [OpenWrt-Devel] Future of package maintenance and new scope of this mailing list
btw. What is the policy on pushing on that repository? Should be commits restricted to the maintained packages or extend to any possible package? You can commit / propose (via pull request) any packages you want to maintain as long as the packaged version is still supported upstream and has no security issues. For example I've added ddns-scripts (copied from the previous repository as I needed it). That's fine. After some time we will adjust the feeds.conf to this new feed. I think the sooner the better, as there are still patches going on for the old repository and as it is there is no incentive to switch to the new. Maybe early switching would speed the process up of porting old packages. I agree and will discuss it with the other core developers. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] protobuf: Bump version, fix build errors.
Hello Jacob, please note that we are not going to accept patches for the (old) packages feed anymore. See: https://forum.openwrt.org/viewtopic.php?id=51078 and the referenced mail for details. If you like you can adopt this package and maintain it in our new github feed: https://github.com/openwrt/packages though. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
Hi Andre, could you please add nettle-mini support and make this a build variant instead of a config option, please? Build variant has the advantage that we can precompile it as ipks because we cannot enable dnssec by default. Otherwise thanks for your work. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
Hi, thanks for this. my intention was more to add one build-variant dnsmasq-full with standard + dhcpv6 + authoritative + dnssec. As dnssec adds hundreds of KB of dependencies anyway I don't think the 10 or 20 KB of the other features make it particularly worse or worth adding variants for every possible combination. Cheers, Steven Am 16.06.2014 10:12, schrieb Andre Heider: Hi, On Sun, Jun 15, 2014 at 11:13 AM, Steven Barth cy...@openwrt.org wrote: could you please add nettle-mini support and make this a build variant instead of a config option, please? Build variant has the advantage that we can precompile it as ipks because we cannot enable dnssec by default. I posted a patch to fix nettle-mini builds to the dnsmasq list. Once a fix is merged I'll include that in this package. The ipkg suggestion sounds nice, but, as Zhou mentioned, that'll give 4 variants already. Is that really what we want? Regards, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
Hi Nikos, Is there a reason for not having dnssec by default? If there is a way to disable it, I believe it will only be beneficial to have it in. The main problem here is that this increase the default image size significantly plus we can't even reuse all the added crypto code because none of the core or important services use nettle. It would be nice to see dnsmasq interacting with a more mainstream embedded crypto library like polarssl or so. Also I would probably let all the DNSSEC deployment and the dnsmasq implementation mature a bit more before considering to enable it by default for everyone. But thats just my personal opinion. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
On the contrary I'd prefer if it doesn't. Nettle is an open project under LGPL that anyone can contribute and can be reused by a variety of software; polarssl is closed commercial project under a commercial license with a GPLv2 exception. Oh well, I sometimes have the feeling if its open-source + backed by a company there is more interest in avoiding another case of heartbleed or similar but I guess we will see about that. Companies are not necessarily evil. Plus nobody said anything about dropping nettle support. Maybe just a little abstraction layer for the crypto stuff would be useful so that other libraries can be used. Heck maybe even add openssl support. That is 10x bigger but still 100x more reusable in terms of other daemons but not necessarily a candidate for default builds either. Also I would probably let all the DNSSEC deployment and the dnsmasq implementation mature a bit more before considering to enable it by default for everyone. But thats just my personal opinion. Well, it will never mature if it is not distributed :) Well, you are not the one getting all the bugreports about mysterious DNS disfunction with certain zones then :P Anyway personally I would like to at least have prepackaged dnssec support ready for installation so people don't have to compile themselves thats one step closer to general adoption than just having a buildoption somewhere deep down in menuconfig. Once Andre sends his next batch of patches we can think about merging it, but that would mean I would have to move nettle to the core repo and adopt it myself since we don't want to have dependencies from core to any of the feeds. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] dnsmasq: DNSSEC support
That sounds better, but on the other side users wanting only dhcpv6 then get quite a lot of DNSSEC bloat. I don't have numbers at hand, but we could explore static libnettle-mini linking? No, I wasn't thinking about dropping the dhcpv6 variant just to add the full variant as number 3 so we have standard, dhcpv6 and full. Does that make sense? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 0/5] DNSSEC support
Applied, thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/5] netifd: Fix vlan delete via netlink
Applied, thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Patch] [Resend] Add terminfo file in ncurses
Ah sorry, seems I forgot to send a reply here. I noticed your initial patch was mangled but since it was trivial I applied it manually already: https://dev.openwrt.org/changeset/41212 Thanks and Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] [packages] tayga: fix broken ICMP checksum on big-endian machines
Hi Ondrej, thanks for your efforts. However we are not accepting patches for the old packages feed any more. However feel free to import, update and maintain the 2 packages in the new feed at https://github.com/openwrt/packages. You can send a Pull Request there. Cheers, Stevem ___ 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)
Hi Baptiste, in general our current firewalling approach is to keep defaults for IPv4 and IPv6 relatively close (not considering NAT here of course). 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. However the packaged version of miniupnpd does indeed support both UPNP WANIPv6FirewallControl and PCP. One of my colleague recently ran a test with PCP and said miniupnpd and it works fine. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New gstreamer packages
Hi Sergey, the oldpackages feed is unsupported and will not be updated any more. If you want to submit packages or adopt packages from oldpackages which are not there yet please go to https://github.com/openwrt/packages and make a pull request there. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi Dirk, thanks for your help. I'll try to add some more documentation for the IPv6 stuff in the near future. In general the aim is to make stuff comply with RFC 7084 (successor of 6204) as closely as possible (with only 1 or 2 exceptions on purpose). In general I'm not sure if anyone has really done a full interop test to check for compliance with RFCs, though it would be nice if someone volunteers. My work has been more on a best-effort basis for now. Though some of the OpenWrt people work closely together with various ISPs so there are some interoperability tests running and some ISPs even have provided some information or patches to make OpenWrt work with their glitches. That doesn't necessarily aid in RFC compliance though ;) Regarding firewalling: I understand and support your point for end-to-end connectivity though there are still quite a few people (including myself) who have reservations about the security implications. I don't think it makes sense to change the defaults for BB at this point, that would be totally unexpected and hastily. And I don't really agree with some of the opinions like users will get used to end-to-end IPv6 - in my experience users don't even know what IPv6 is and does. Nevertheless we should have a discussion about this for CC probably and I will try to get some more opinions also in the light of IETF 90 being next week. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Duplicate netifd protocol for l2tp
Hi Baptiste, thanks for the report. I renamed the xl2tpd netifd protocol to l2tpv2 and kept the l2tpv3 as l2tp as documented in the wiki. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] gre: Generic Routing Encapsulation package support
tbh. we should get rid of that option network stuff. I merged it anyway at first so we can get some experience with this gre-integration. Normally you should use something like this instead: config interface mygre option proto 'gre' option ipaddr '203.0.113.2' option peeraddr '192.0.2.42' option network 'tunnel' config interface mygre_static option proto static option ifname @mygre option ipaddr 10.0.0.217 option netmask 255.255.255.0 Same should hopefully work with gre and gretap as source. If this does the trick I'm for removing the option network stuff. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] netifd: GRE tunnel support
To be fair I introduced IFLA_IPTUN_ stuff earlier with MAP-encapsulation support. My general impression was that we do not care about 3.10 targets any more. So even if Hans provides some patches for GRE it will not help much since MAP-support does the same. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] netifd: GRE tunnel support
Hi Florian, I pushed a netifd revision 77a865b5b3ac476e05ff80f3c10d86686285c0da which disables ds-lite, map and gre using ifdefs if IFLA_IPTUN_MAX is not defined in the kernel headers. Could you please check if that does the trick for you (note: I did not bump the netifd-Makefile in trunk yet)? Cheers, Stevenmailto:openwrt-devel%40lists.openwrt.org?Subject=Re%3A%20%5BOpenWrt-Devel%5D%20%5BPATCH%203/3%5D%20netifd%3A%20GRE%20tunnel%20supportIn-Reply-To=%3CCAGVrzcbtMUhpDbhG4SbiGtk7LXO5REHaSxniuTHTBHUBv8jpBA%40mail.gmail.com%3E ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Lots of missing packages!
Hi Valent, we decided to reorganize the packages feed in June, since lots of the packages in there were unmaintained and we had lot's of patches we couldn't review. The new feed resides on github which makes contributing more straigt-forward. See https://github.com/openwrt/packages. Now the problem with packages like python or php in oldpackages is that they build a version which have known security issues, so providing binaries for them without notice is a bit dubious. Note: we didn't delete any package-definitions we just stopped building binaries. Once someone takes over maintainership for them and keeps them updated we will gladly welcome them in our new packages feed and start building binariers for them again. The current status of oldpackages is this: If you are using trunk and want to use the possibly outdated packages you have to enable the oldpackages feed and build them manually. If you are using barrier breaker in the final version we will still build these outdated packages in binary form but won't enable the package repository in opkg.conf by default, so you have to manually opt-in to use these packages. Some packages there might be broken due to changes in the SDK but this will hopefully get addressed before the final release. The next release after barrier breaker will not include any unmaintained packages at all not even as opt-in. So if you want to see some of the old packages reappearing in trunk and future releases please adopt them and become a maintainer or convince someone else to do it. See https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md Regards, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Lots of missing packages!
What you see right now in RC3 will be there in the final as well, it will just be split up into subdirectories and the unmaintained packages oldpackages need to be manually enabled in /etc/opkg.conf on your router before being installable using opkg. In RC3 they are still all together in one package repository. There might be a few more packages in the final but what is in RC3 now (rsync is still running btw.) is a pretty good estimate of what will be there. Cheers, Steven Am 13.08.2014 um 12:46 schrieb Aaron Z: On Wed, Aug 13, 2014 at 4:13 AM, Steven Barth cy...@openwrt.org wrote: The current status of oldpackages is this: If you are using trunk and want to use the possibly outdated packages you have to enable the oldpackages feed and build them manually. If you are using barrier breaker in the final version we will still build these outdated packages in binary form but won't enable the package repository in opkg.conf by default, so you have to manually opt-in to use these packages. Some packages there might be broken due to changes in the SDK but this will hopefully get addressed before the final release. The next release after barrier breaker will not include any unmaintained packages at all not even as opt-in. So, are the precompiled packages on openwrt.org [1] indicative of what will be available for the final release of BB? From there on ar71xx, nano was missing from RC1, but is back for RC2 [2] and RC3 [3]. Looking in the same folder [1] for the packages that Valent mentioned in his second ticket, I also see bluez-libs [4], bluez-utils [5], /i2c-tools [6], ntpclient [7], picocom [8] and python [9] as precompiled packages. Will those still be available in the final release? [1] http://downloads.openwrt.org/barrier_breaker/14.07-rc2/ar71xx/generic/packages/ [2] http://downloads.openwrt.org/barrier_breaker/14.07-rc2/ar71xx/generic/packages/nano_2.3.6-1_ar71xx.ipk [3] http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/nano_2.3.6-1_ar71xx.ipk [4] http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/bluez-libs_3.36-3_ar71xx.ipk [5] http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/bluez-utils_3.36-12_ar71xx.ipk [6] http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/i2c-tools_2013-12-15-1_ar71xx.ipk [7] http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/ntpclient_2007_365-4_ar71xx.ipk [8] http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/picocom_1.7-1_ar71xx.ipk [9] http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ar71xx/generic/packages/python_2.7.3-2_ar71xx.ipk Aaron Z A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. — Robert Heinlein, Time Enough for Love ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Q: curl: IPv6 zone identifiers / RFC6874 / OpenWrt
Please file a bug against CURL itself, this issue is outside of our scope. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq 2.71 dies silently (hangs) / how to debug
Hi Bastian, you should try: procd_set_param limits core=unlimited Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq 2.71 dies silently (hangs) / how to debug
No, miniupnp doesn't use procd yet. However you should be able to use the usual: ulimit -c unlimited somewhere above the service_start call to enable core dumps. On 19. August 2014 19:15:32 MESZ, Luis E. Garcia l...@bitamins.net wrote: I've noticed this issue with dnsmasq, I think that miniupnp is also having a similar issue where it dies silently after a few days. Can I apply the same method to debug miniupnp ?? Regards, Luis Garcia On Tue, Aug 19, 2014 at 10:45 AM, Bastian Bittorf bitt...@bluebottle.com wrote: * Steven Barth cy...@openwrt.org [19.08.2014 12:49]: procd_set_param limits core=unlimited thanks, this works fine here when the 'root' part of dnsmasq gets a -SIGSEGV (or during a real crash) and produces coredumps. i will keep the list updated, when i catch a real hang. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq 2.71 dies silently (hangs) / how to debug
On another note: I just backported an upstream fix for a race condition. Might be related to this issue or might not. Please try to test with latest trunk or bb-branch. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Lots of missing packages!
Please see https://forum.openwrt.org/viewtopic.php?id=52219 Am 20.08.2014 um 15:03 schrieb Bastian Bittorf: * Steven Barth cy...@openwrt.org [13.08.2014 10:48]: The current status of oldpackages is this: If you are using trunk and want to use the possibly outdated packages you have to enable the oldpackages feed and build them manually. how is this done? till some weeks it was: make package/symlinks and now? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 6in4 does not recover after wan outage
Hi Richard, could you please post the output of: ifstatus wan and ifstatus wan6 when said situation occurs? Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BB-rc3] Disabling DHCPv6 also disables IPv6 SLAAC
Please try with: option dhcpv6 disabled instead of none Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BB-rc3] Disabling DHCPv6 also disables IPv6 SLAAC
disabled is the same as omitting the dhcpv6 option. none is not valid in this context and causes havoc it seems ;)___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] disappearing on-link route with RA
Yeah, the issue was in the tons of work-arounds needed to deal with Linux' onlink-route handling before 3.14. I added another one because they are so nice and likeable. This should hopefully do the trick again, until next time. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch
Well it seems to be still somewhat used in embedded stuff, e.g. my 5-year old HP ethernet/802.11g printer/scanner/whatever still uses MLDv1 / IGMPv2 to do its MDNS / SSDP business. Another idea would maybe be to translate MLDv1 / IGMPv2 reports into appropriate MLDv2/IGMPv3 equivalents before sharing them on the bridge to prevent the suppression. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch
Am 12.09.2014 um 03:48 schrieb Linus Lüssing: Another idea would maybe be to translate MLDv1 / IGMPv2 reports into appropriate MLDv2/IGMPv3 equivalents before sharing them on the bridge to prevent the suppression. Hm, IGMPv2/MLDv1 to IGMPv3/MLDv2 should be relatively easy. But I'm currently not sure whether a router/querier will make and take some wrong assumptions and actions by thinking there is no IGMPv2/MLDv1 listener. What if there is one MLDv2 listener which included source specific state messages in its state change report? The querier would respond with a Multicast Address and Source Specific Query to learn whether there are listeners left for this multicast and source addresses. Would the MLDv1 listener interpret this query and process this message as a Multicast Address Specific Query or would it ignore it? It doesn't really matter since sending / receiving address-and-source-specific queries doesn't reduce the filter timer of the group but only the source timers of the sources included in the query. What about the many MLDv1 queriers we have right now through the bridge code? What if someone sneaks in an MLDv1 listener somewhere in your bridged network over an ethernet cable? (You'd need report translation both on the AP and on bridges and maybe query translation, too) Ah so the bridge code is actually a dumb v1-querier. Hmm that is problematic then I suppose. But doesn't that effectively downgrade the whole link to MLDv1 even if you potentially have a v2 querier at hand? Sounds very fishy to me. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libatomic patch
There you go. It would be nice if anyone could maintain a package for openvswitch in the packages or routing-feed then. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libatomic patch
Hi Alexandru, sure go ahead. I think there are already some package-definitions on github https://github.com/pichuang/openvwrt/ which you can base the package on. I think the easiest way would be to read our guidelines at: https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md and then make a pull request for that repository with the new package. Cheers, Steven Am 12.09.2014 um 14:51 schrieb Alexandru Ardelean: Awesome. Thanks for updating it. If nobody else wants to step forward for maintaining the OVS feed, I'll fully commit to maintaining it. [ Well, that is, if I'm allowed ] Thanks Alex On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth cy...@openwrt.org mailto:cy...@openwrt.org wrote: There you go. It would be nice if anyone could maintain a package for openvswitch in the packages or routing-feed then. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto: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] libatomic patch
Oh fine with me as well. Use whatever version or patches you think works best. I was just suggesting a starting point in case you needed one. Feel free to ignore it though. Cheers, Steven On 12. September 2014 16:26:16 MESZ, Alexandru Ardelean ardeleana...@gmail.com wrote: Hey Steven, At the moment we use this one as base: https://github.com/hschaa/openvswitch-feed I did also take a look also at pichuang's repo. I'll take a look at multiple versions and try to pull in all the cleanest elements from each. Then do some tests and come back with a pull request on Github. Thanks Alex On Fri, Sep 12, 2014 at 5:11 PM, Steven Barth cy...@openwrt.org wrote: Hi Alexandru, sure go ahead. I think there are already some package-definitions on github https://github.com/pichuang/openvwrt/ which you can base the package on. I think the easiest way would be to read our guidelines at: https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md and then make a pull request for that repository with the new package. Cheers, Steven Am 12.09.2014 um 14:51 schrieb Alexandru Ardelean: Awesome. Thanks for updating it. If nobody else wants to step forward for maintaining the OVS feed, I'll fully commit to maintaining it. [ Well, that is, if I'm allowed ] Thanks Alex On Fri, Sep 12, 2014 at 3:30 PM, Steven Barth cy...@openwrt.org wrote: There you go. It would be nice if anyone could maintain a package for openvswitch in the packages or routing-feed then. Cheers, Steven ___ 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] miniupnpd state loss
Your change completely disables reloading which breaks in case of wan switching to a different interface or if lan interfaces are coming up. I commited a change https://github.com/openwrt-routing/packages/commit/8bc38fccc73b40e9599b897e335f2e7a5a67e879 which should avoid restarts in case wan interface flakes but stays the same. Please test and let me know if this solves your issue. Still miniunpd needs to be restarted in certain cases as noted above, this will cause loss of state however this problem must be resolved upstream as the program doesn't suppport a change of external or addition of internal interfaces without a restart. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/4] openssl: disable sslv2, add an option to enable sslv3
Merged with some modifications. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iptables: correctly parse non-options arguments with musl libc
Hi Gianluca, thanks for your patch. However instead of adding wrappers to every single application I'd rather like us to add the optstring '-' extension to musl as a patch. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd: Don't append 6rd dhcp option when iface6rd is empty
That change was actually intentional so 6rd is setup if its available unless you disable it with iface6rd=0. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2]odhcp6c: message retransmission count support
Hello Hans, Thank you very much for your patches. I've commited them to the github repo and will do some testing probably next week. If all works out i will get them live afterwards. Cheers, Steven___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 6relayd: verify fd is valid before use
Hello Nathan, Thanks for your patches. I already had a quick look at them and found that i already addressed some of this in odhcpd which will replace 6relayd in the near future. I will go through the others later again. Cheers, Steven___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH]netifd: Fix source routing for IPv6 prefix address
Hello Hans, could you please explain your patch again. I didn't quite get the paragraph you've written. It seems the sentence is a bit garbled. Thanks, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [REGRESSION] netifd: IPv6 RA on-link route disappearing
Hello Gui, thanks for your report. I just updated odhcp6c to generate the routes and addresses in netifd in a better way. The old method seemed to have some races that could lead to the behaviour you have seen. Could you please retest with the new odhcp6c and see if that works better for you? Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] odhcp6c: don't handle certain RA data if the kernel is, configured to take care of it
Hello Heiner, thanks, however overriding the kernel behavior is intentional as its handling of e.g. routes is very limited. Also getting address from both the kernel and through dhcpv6 to netifd to the kernel causes conflicts such as the ones you noted. If you want to use Kernel RA-handling please disable the dhcpv6 protocol handler on said interface. If you really want to do this I suppose I could live with a manual switch for odhcp6c / the dhcpv6 handler to turn of RA-handling altogether. However the results won't be very pretty. Regards, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hello Henning, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. please see: https://dev.openwrt.org/changeset/40422 I added an option weakif which allows you to specify an interface from which we take the local IPv6 address defaulting to lan. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] OpenSSL: update to 1.0.1g
Applied, thanks. Will probably take care of AA later today. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi Gert, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. I'm sorry but it seems you misunderstood me. We were talking about IPv6 addresses here. It seems that Hennings' ISP only offers a delegated prefix but no global IPv6-address on the WAN-connection (or there is an unknown issue acquiring said address which I don't know of). I know that RFC 7084 requires a CER to actually deal with this (Weak ES model and all) so I added a fix to allow the DS-Lite source endpoint address to be acquired from a downstream interface. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi Gert, There has been quite a bit of discussion in the ISP camp regarding WAN IPv6 addresses. It's not actually straightforward what to do as an ISP, so multiple variants exist - RA for WAN, DHCPv6-PD for LAN - DHCPv6-IA for WAN, DHCPv6-PD for LAN - require use of an IPv6 address out of the delegated /56 for WAN - run the WAN over link-local only Now you can feel my pain trying to make OpenWrt compatible with all of that + deal with weird quirks from every other ISP. On a side note not all ISPs seem to like ds-lite as it requires Carrier-Grade-NAT. So I hope to get other stuff like lw4o6 and / or MAP-E/T in there at some point. Soo much todo, so little time *sigh*. Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi Henning, yeah that is another side-effect of your - well - irregular ISP-behaviour. I will try to put it on the TODO but it's not very high on the list as its more or less cosmetic, sorry I'm a little short on time at the moment. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd: fix IPv6 Link-local DNS server
Applied, thanks. Will get into OpenWrt with next netifd-bump. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] option ip6assign 60
Hi Gert, In regular OpenWrt ip6assign means that - as already written - a /60 (if available) is taken from the DP and the assigned to the given interface. That value was chosen rather arbitrarily. The first /64 of that DP is handed out via RA and stateful DHCPv6 (IA_NA). The rest of the /60 (or whatever you set in ip6assign) can be acquired by downstream routers on that interface via DHCPv6-PD. Regarding homenet / hnetd, please see http://www.homewrt.org for some documentation. Also feel free to ask me (I'm one of the authors of the draft and implementation) or join us on #hnet-hackers on freenode about anything you might need / want to know. hnetd implements its own prefix delegation algorithm (as its managed throughout the homenet) so usual ip6assign-stuff doesn't apply here. You can also use it with bridges but it might make more sense to use individual ports instead to e.g. avoid unnecessary traffic on WiFi or make proper use of the border detection (e.g. use one switch-port for a second uplink and another for downstream or so). Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] option ip6assign 60
Hi Gert, you are right its a bit unusual and you may very well consider it bad practice and if I have enough time it will hopefully solve it in a better way at some point. The reasoning behind this is that this way the DHCPv6 (PD) server can easily learn about the whole available prefix range and any lifetime etc. changes immediately via Kernel netlink updates and thus reconfigure clients and downstream routers easily if needed without a separate IPC or configuration channel. Of course it still sets up a more specific routes once a prefixes is actually assigned to a downstream router so that routing works correctly. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [openwrt-routing] mcast-tools: fix linux/pim.h include
Applied, thx. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] option ip6assign 60
Am 02.05.2014 21:00, schrieb Gert Doering: Ah! So it's a reservation for downstream-DHCPv6-PD. It's still slightly confusing, tbh, to see the ifconfig and route values point the /60 towards the actual interface. But maybe that's just me :-) - it certainly isn't causing problems, just to say that again. Yes, please see other e-mail in the thread for justification ;) Thanks for the offer. Right now, only one of the routers is life (due to convenience of access to stuff, like arbitrary upstream routers, I'm building this at office, and 3 out of 4 boxes are still at home...), but I'm planning to have this operational in the next few days - and I'm sure questions will come. I've read everything that's linked from the start page on http://www.homewrt.org/ - but it's not really much as far as how can I see what it does? how can I debug it? Is there only one single option to turn this on and off (option proto 'hnet'), or is there more? Does hnetd handle IPv4 and IPv6 today? How do I force selection of a certain /64 on a specific interface? question go... :-) Yeah to turn it on on a given interface simply change the proto to hnet (and remove any previous interface using the same interface in /etc/config/network). If you want to not use bridging you need to create one logical interface in /etc/config/network for each switch-port / vlan. Once you have configured an interface e.g. like this: config interface h1 option ifname eth1 option proto hnet and brough it up with /etc/init.d/network reload ifup h1 you can watch its state using: ifstatus h1. hnet also automatically creates a dhcp and dhcpv6 client subinterface which you can also monitor using ifstatus h1_4 and ifstatus h1_6. If there is 6rd or dslite provided by dhcp / dhcpv6 then there is a in addition an interface h1_6rd or h1_dslite. All these virtual interface are created automatically (you don't need to put then in /etc/config/network). Also hnetd at the moment is very talkative in syslog so you should get a pretty good view of whats going on. Forcing a certain prefix on an interface is implemented but not exposed to interface config yet. I will try to put it on todo for sometime next week and push a new version to OpenWrt once its working shouldn't be very hard. Regards, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hnet tests
Hi Gert,
Am 02.05.2014 23:14, schrieb Gert Doering:
Hi,
On Fri, May 02, 2014 at 10:56:07PM +0200, Gert Doering wrote:
... so, something I am missing... :-/
Oh well. First thing is I should have looked at 'ifstatus wan_6' which
indeed tells me WAN is working:
root@OpenWrt:/etc/config# ifstatus wan_6
{
up: false,
pending: true,
available: true,
autostart: true,
proto: dhcpv6,
device: eth0,
data: {
}
}
doesn't really look like working.
Questions :-)
- is hnetd intentionally ignoring the A-Bit in RA?
hnetd doesn't reimplement the dhcpv6-client it uses OpenWrt's internal
dhcpv6-protocol-handler.
So it behaves the same as if you had an interface with proto=dhcpv6 and
option forceprefix 1. If it works with that you should be good to go
(unless there is a bug somewhere sigh)
And normally the dhcpv6 handler ignores O/M-bits and just asks for IA_NA
+ IA_PD first in a solicit and when that fails (server returns with
NoAddrsAvail) tries with IA_PD-only which should succeed in your case
(don't know why it didn't though).
- what's the recommended config on the upstream side to make it work?
Remove the O-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)
I'll try to confirm / fix a bug tomorrow or on monday. I could offer you
a workaround at the moment which is: Open /lib/netifd/proto/hnet.sh and
search for json_add_string proto dhcpv6
Below that insert a line:
json_add_string reqaddress none
which should disable it asking for an IA_NA alltogether.
thanks,
gert
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hnet tests
Just did a quick test with hnet against ISC dhcp behaving the same
(IA_PD-only) and it worked out fine.
Am 03.05.2014 07:59, schrieb Steven Barth:
Hi Gert,
Am 02.05.2014 23:14, schrieb Gert Doering:
Hi,
On Fri, May 02, 2014 at 10:56:07PM +0200, Gert Doering wrote:
... so, something I am missing... :-/
Oh well. First thing is I should have looked at 'ifstatus wan_6'
which
indeed tells me WAN is working:
root@OpenWrt:/etc/config# ifstatus wan_6
{
up: false,
pending: true,
available: true,
autostart: true,
proto: dhcpv6,
device: eth0,
data: {
}
}
doesn't really look like working.
Questions :-)
- is hnetd intentionally ignoring the A-Bit in RA?
hnetd doesn't reimplement the dhcpv6-client it uses OpenWrt's internal
dhcpv6-protocol-handler.
So it behaves the same as if you had an interface with proto=dhcpv6
and option forceprefix 1. If it works with that you should be good to
go (unless there is a bug somewhere sigh)
And normally the dhcpv6 handler ignores O/M-bits and just asks for
IA_NA + IA_PD first in a solicit and when that fails (server returns
with NoAddrsAvail) tries with IA_PD-only which should succeed in your
case (don't know why it didn't though).
- what's the recommended config on the upstream side to make it work?
Remove the O-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)
I'll try to confirm / fix a bug tomorrow or on monday. I could offer
you a workaround at the moment which is: Open
/lib/netifd/proto/hnet.sh and search for json_add_string proto dhcpv6
Below that insert a line:
json_add_string reqaddress none
which should disable it asking for an IA_NA alltogether.
thanks,
gert
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hnet tests
Hi Gert,
well thanks for testing.
answers are inline.
Hi,
thanks for your help so far. (Side question: if people feel this is getting
off-topic for openwrt-devel, I'll take it offline. For now I keep the CC:
because I think other people might end up running into this, and google
might find the solutions, then :-) )
Should be fine.
What does forceprefix 1 do?
Normal dhcpv6 handler also succeeds without PD for simple clinets.
If I do proto dhcp and no forceprefix, the wan interface gets an
IPv6 address from the RAs received (plus default route).
Right now, I have neither an IPv6 default route nor an address, so it
very much looks like it's ignoring my RAs.
Strange as RA handling is done independently but OK.
[..]
- what's the recommended config on the upstream side to make it work?
Remove the O-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)
I'll try to confirm / fix a bug tomorrow or on monday.
Thanks for testing against ISC DHCP (other mail). I'm not sure what
is different here - maybe ISC is returning the prefix right away, while
IOS just tells the router go away?
Might be IOS weirdness of this specific version. We have tested against
other Cisco devices which works fine. Which version is it?
I could offer you
a workaround at the moment which is: Open /lib/netifd/proto/hnet.sh and
search for json_add_string proto dhcpv6
Below that insert a line:
json_add_string reqaddress none
which should disable it asking for an IA_NA alltogether.
Done...
May 3 14:47:47: IPv6 DHCP: Received SOLICIT from FE80::12FE:EDFF:FEE6:5F33 on
Vlan62
May 3 14:47:47: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 3 14:47:47: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 3 14:47:47: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 3 14:47:47: IPv6 DHCP: Sending ADVERTISE to FE80::12FE:EDFF:FEE6:5F33 on
Vlan62
May 3 14:47:47: IPv6 DHCP: Received REQUEST from FE80::12FE:EDFF:FEE6:5F33 on
Vlan62
May 3 14:47:47: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 3 14:47:47: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 3 14:47:47: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 3 14:47:47: IPv6 DHCP: Creating binding for FE80::12FE:EDFF:FEE6:5F33 in
pool NetmasterTEST
May 3 14:47:47: IPv6 DHCP: Allocating IA_PD 0001 in binding for
FE80::12FE:EDFF:FEE6:5F33
May 3 14:47:47: IPv6 DHCP: Allocating prefix 2001:608:5::/56 in binding for
FE80::12FE:EDFF:FEE6:5F33, IAID 0001
May 3 14:47:47: IPv6 DHCP: Sending REPLY to FE80::12FE:EDFF:FEE6:5F33 on Vlan62
... and things work :-) - I'm not posting the whole ifstatus wan_6 now,
as it is 100+ lines long. The most important bits are these, though:
OK, hopefully there is an IPv6 default route in there somewhere.
Next question :-)
root@OpenWrt:~# ifstatus lan_6
{
up: false,
pending: true,
available: true,
autostart: true,
proto: dhcpv6,
device: eth1,
data: {
}
}
as per your definition, this is not working, right?.
Not necessarily. The _6 interfaces are only showing information acquired
from DHCPv6-servers/RAs so this only matters if its an uplink. ifstatus
lan without _6 shows the data from homenet / hnetd such as IP address,
firewall zone.
OTOH, ip -6 addr confirms that it indeed selected a subnet from the
delegated prefix (2001:608:5::/56), assigned it to the lan=eth1 (only
a single LAN interface here)
3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qlen 1000
inet6 2001:608:5:b5:12fe:edff:fee6:5f32/64 scope global dynamic
valid_lft 3448sec preferred_lft 1648sec
inet6 2001:608:0:62:12fe:edff:fee6:5f33/64 scope global dynamic
valid_lft 2591971sec preferred_lft 604771sec
inet6 fe80::12fe:edff:fee6:5f32/64 scope link
valid_lft forever preferred_lft forever
$ ip -6 route
2001:608:5:b5::/64 dev eth1 proto static metric 1024
So it looks good to me.
Though... ip -6 route actually brings up the next huh, what? question:
root@OpenWrt:~# ip -6 route
default from :: via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
default from 2001:608:0:62::/64 via fe80::214:1cff:fed2:30c0 dev eth0 proto
static metric 1024
default from 2001:608:5::/56 via fe80::214:1cff:fed2:30c0 dev eth0 proto
static metric 1024
2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec
2001:608:5:b5::/64 dev eth1 proto static metric 1024
unreachable 2001:608:5::/56 dev lo proto static metric 10 error -128
unreachable 2001:608:5::/56 dev lo proto static metric 2147483647 error -128
unreachable fd83:af19:9ef::/48 dev lo proto static metric 2147483647 error
-128
I understand the defaults (eth0=wan, source dependent, could be multiple
routers, but there is only one, so all the same), and the unreachables.
I do not
Re: [OpenWrt-Devel] help with netifd 802.1ad development
Hi Gioacchino, it seems the kernel expects a big-endian value as vlan protocol, so you should probably try wrapping cfg-proto in htons when passing it to nla_put_u16. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] Add support for QMI-based mobile broadband modems
Hi Matti,
thanks for the patches. A few notes though:
I don't particularly like the dhcp-approach. Including the script
directly looks hackish and also it wouldn't work for DHCP and RA/DHCPv6
in parallel. Instead I would suggest to bring up the interface without
any addresses and at the end of the protocol handler launch two
subprotocols for dhcp and dhcpv6 respecitely. This way we avoid hacking
around with the dhcp-handler.
To do this add something like this at the end of your setup_interface
after the proto_send_update call:
json_init
json_add_string name ${INTERFACE}_dhcp
json_add_string ifname @$INTERFACE
json_add_string proto dhcp
json_close_object
ubus call network add_dynamic $(json_dump)
and then the same just with dhcp replaced by dhcpv6.
The second point would be that strictly speaking uci_set_state is
deprecated. But I can understand why you used it here. We might want to
think into other solutions at some point, i.e. add a kind of daemon mode
to uqmi which handles the whole process and also avoids those nasty
while - sleep loops.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Future of package maintenance and new scope of this mailing list
Hello Developers, it has been some time since our latest stable release, so we are currently busy preparing the first RC for Barrier Breaker. But before we want to do the actual builds we need to take care of the packages feed which has been neglected for a quite a while. A lot of packages are abandoned, some are broken, unusable or worse so we think its time for a fresh start. We know and acknowledge there are patches for some of them but we don't have the manpower to review all the patches to a reasonable extent and offer support for all of them. In a recent meeting we therefore decided to abandon the current packages feed as is and start off with a new github repository for the overall package feeds. We will grant everyone who is currently maintaining packages push rights there and will gladly invite other reliable contributors. So if you want to collaborate, please open tickets for bugs and send pull requests to this new github repository and get in touch with us for getting write-access to the feed. The new repository is located here: https://github.com/openwrt/packages Please read and follow the guidelines in the README. You may of course use packages from the current packages-feed and copy them as long as they are compliant, i.e. please don't copy outdated, unsupported or unmaintained packages without updating them. After some time we will adjust the feeds.conf to this new feed. Please note that there are also other themed packages feeds like routing and telephony that can be used when you want to move or add packages. Please refrain from sending packages-related patches to this list. In the future this mailing list should only be used for platform and packages in the core repository. Regards, OpenWrt release management team ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Netifd: Generic multi-wan support
Hi Kristian, at first: thanks for your feedback. I really like the general idea of this patch, however: 1) Instead of using the interface index to decide on interface metric, a table-option is added to interfaces. This way, users are sure which tables will be used for policy routing and can avoid overlaps. The table-option must be set for an interface to be 'multi-wan', and all routes belonging to the interface will be added to this table. This might be acceptable for IPv4 but is not for IPv6. I see the point of the table-attribute and don't object to it. However it must not default to main but to something interface-specific. One of the main points of adding multi-wan IPv6-support was to filter IPv6 traffic by source-address so that it is isn't sent through an interface where the source-address might be rejected by the upstream router or where it simply shouldn't go (e.g. in case of ULA-traffic). 2) Routes are added both to the original table (for example main) and the interface-specific table. This is done to ensure networked applications running on the node will behave as intended. If routes are only added to the interface-specific tables, traffic from applications not binding to an interface will not be routed correctly. Again I doubt this is a good idea and at least for IPv6 this again totally defeats the purpose (e.g. source-filtering, see above). Does a routing policy for each interface table from lo lookup ... (like it was done for IPv6) not cover all locally originating traffic? If it does not, please provide an example where this isn't sufficient. So in the current state: NAK from my side. I could however imagine a compromise here and being in favor for this if we make the following changes to it: * Adding an interface-specific default for the interface_table. * Adding routes to specific tables only (not twice to different tables). * Adding default routing policies for IPv4 so that each table is looked up from every source-address by default for backwards compatibility (also: source-based filtering doesn't make sense for masquerading NAT) * If one wants to restrict traffic (e.g. lan-traffic must only go to wan and not to wan2 or so) he can simply add policy rules through UCI with a higher priority than the default ones (e.g. from lan lookup XYZ + from lan unreachable). Anyway such an intrusive change to IPv4 routing would be needed to be ACKed by more developers. Regards, Steven PS: Also please avoid unrelated changes (interface_write_resolv_conf) or unrelated white-space changes in any follow-up patches. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Hi Thomas, I don't think the DHCPv6 client is the right place to do this. You should rather configure PPP and select the interface identifier in its configuration as this patch would completely defeat the purpose of IPv6CP. Regards, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
On 18.06.2013 01:15, Thomas Bächler wrote: You're confusing me even more - how does the patch relate to ipv6cp? In ipv6cp, I am assigned a link-local address by the provider. I may be wrong, but doesn't my peer expect that I use this link-local address in its routing table in order to communicate with me? This means that I cannot change the assigned link-local address. Well I'm not sure about that but that but that was not what I meant. Maybe my wording was a bit confusing as. IIRC pppd provides an option to define the local interface identifier for use in IPv6CP and is then hand-shaked with the peer. And as we by default use the interface-identifier of the link-local address for the global addresses as well this should equally do what you want with the nice side-effect that the interface identifier of the LL-address matches those of the global ones. On the other hand, my peer doesn't care which IPv6 address I choose inside the advertised prefix, and if it is related to the link-local or not, so this is the address that I can change, and the client is the only place where I can change it. Yeah you're right, but honestly I still don't see the point of adding this in the DHCPv6/RA-client rather than just configuring pppd. If configuring ppp doesn't work for you we can reevaluate adding this feature to odhcp6c instead. Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
On 18.06.2013 14:32, Gert Doering wrote: Hi, On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote: I think this change is useful (without having looked at the actual code), for exactly these reasons. With the IPv6CP handshake, you'll arrive at something the provider controls - but then in the /64 that is announced by RA, you can choose whatever host id / interface identifier you want, and I can see people wanting to use something easy to type and remember, like ::1. I must be missing something here... Exactly how do you communicate an interface identifier via RA? You don't. Which is the point :-) - ISP announces the RA, end user gets to pick whatever prefix they like, inside the /64 announced. One could argue that they should only use the interface identifier that PPP/IPv6CP negotiated, but in practice, that would break at least privacy addresses - so what I've seen so far is if the ISP sends RA with A=1, the user can use any address in that /64 they want. Which even holds true for 3G networks that force link-local to very specific IDs. gert Allright fine, you guys have convinced me. I just commited a modified version of that patch to trunk. Please test it. @Thomas: Please post patches against trunk and not AA in the future. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [6relayd] Crash when timerfd_create is not enabled
Thanks for the hint. It is fixed upstream now. I will update the OpenWrt revision when some more bugs pile up. Cheers, Stevem ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
On 25.06.2013 00:15, Thomas Bächler wrote: Am 18.06.2013 14:57, schrieb Steven Barth: Allright fine, you guys have convinced me. I just commited a modified version of that patch to trunk. Please test it. On AA, there's a missing line proto_config_add_string ifaceid in proto_dhcpv6_init_config() in package/odhcp6c/files/dhcpv6.sh. When I add it, everything works as expected. Thanks, corrected in both trunk and AA. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 6rd problem when setting up via DHCP due to typo
Thanks for the report. It should be fixed now. Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite setup problem due to missing statement in dhcpv6.sh
Thanks. Should be fixed now. Cheers, Steven___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Building nf_nat_ipv6.ko
Hi, thanks to you all for your contributions. I've commited something based upon this in https://dev.openwrt.org/changeset/37866 This also adds proper packaging for kernel-modules and iptables-modules. I moved the IPv6-NAT stuff out of regular NAT-stuff as it doesn't really fit in (many people use IPv4 NAT, only few will use IPv6-NAT). I hope this is more complete now but I would still consider this experimental, however this is something people can play with. Feedback and comments or improvements are appreciated. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: uci-defaults Actually generate a working ipv6 configuration by default.
I'm sorry but the @wan syntax does indeed work. It works for me and many other people using the new IPv6 stack. Could it be that you are using an old version of netifd for some reason? (e.g. you updated / installed only some of the new IPv6 packages on top of the 12.09 release). If there is still something wrong after updating please file a bug in Trac including the versions of the relevant packages including your config information. Also neither the DHCPv6 RFC nor the DHCPv6-PD RFC state something that a hint must be included and how big it needs to be. RFC 6204 says that one MAY include a hint and if so it must be big enough to assign a /64 to every downstream interface and should be configurable to a greater value. However we do not include a hint by default. You can however provide one if you like. Also please note that ip6assign=60 means that the network daemon should assign a prefix of AT MOST /60 to the interface, if there is only a /62 or /64 available it will assign the maximum available length. So I really don't see a problem here. -Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
http://wiki.openwrt.org/doc/uci/network6#native.ipv6.connection ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] race IPv6 odhcp6c IAID
Hi Bastian, I just commited a fix although it wasn't really a race. Please try with the latest revision. 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.script being triggered a lot
Hi Nathan, I've seen this being reported by someone else already a few months ago also involving Comcast ( https://forum.openwrt.org/viewtopic.php?pid=191916#p191916 ). It seems they have a rather weird way of sending out Router Advertisements every 3 seconds at some locations which is causing this behaviour. While 3 seconds is technically the lower bound of the interval range it doesn't make much sense to spam these control messages around at that interval so it might be a good idea to contact Comcast about it. 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.script being triggered a lot
Hi Nathan, actually it's not that easy. Especially if the contents are the same this means an update. This is because most contents of the RA contain a validity timer in seconds. Thus if you sent 2 successive RAs with the same contents with a 3 second difference the second RA increases the validity of the contents by 3 seconds (as it arrived 3 seconds later). 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.script being triggered a lot
Hi Nathan, I just pushed an update to netifd. Could you please check if the current version improves behaviour for you? Also alternatively could you please check in your /etc/config/6relayd if compat_ula is set to 1 and if so remove it or set it to 0? 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.script being triggered a lot
On 02.10.2013 07:35, Nathan Hintz wrote: Hi Steven: netifd eventually crashed: Tue Oct 1 21:57:58 2013 daemon.notice netifd: wan6 (1382): Segmentation fault Could this be due to continuing to call system_add_address(dev, a_new); without ever calling system_del_address(dev, a_old);? Hmm strange, I tested this fix and fired multiple rounds of RAs at it but couldn't reproduce this segfault. Also calling system_add_address just sends a netlink control-message to the kernel and does not allocate anything which must be deallocated later (same goes for _handle_subnet_route) so this shouldn't be causing this. -Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] package/index: fix index creating when building without signing
Sorry about the fuzz and thanks for the patch. Applied in r38287. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite interface not getting active
Hello Hans, thanks for the report. I put in on my todo list. I have a few other netifd changes staged somehwere anyway and will hopefully be able fix this issue soon. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build: generate_package_index: use 'sha256sum' in favor of 'openssl sha256'
Hi Bastian, I recently added openssl as a generic build dependency for OpenWrt as part of the new package signing infrastructure thus I don't think using openssl sha256 is problematic. Can you give an example please where there is an openssl without sha256 support? Thanks, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite interface not getting active
Hello Hans, I finally commited a netifd update yesterday which should take care of that. Regards, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hello Everyone, you may have noticed LuCI the Lua Configuration Interface in the official release announcement for Kamikaze 8.08 As there was not much information about this project in the past and we noticed several people asking in different places for it we like to make a little announcement here: LuCI is a new approach for a web user interface for OpenWRT. It aims to be free, clean and extensible. While most similar configuration interfaces make heavy use of the Shell-scripting language LuCI uses the Lua programming language and splits up the interface into logical parts like models and views, uses object-oriented libraries and templating. That ensures a higher performance, smaller installation size, faster runtimes and what is most important: better maintainibility. To the project status: LuCI is already quite stable and we are doing last improvements and bugfixes before the first RC version. At the moment all base-system networking and configuration stuff can be edited via LuCI plus a few more applications like firewalling and port-forwarding stuff, a statistics collector with rrdtool-graphs, OLSR and QoS support are included. We are always looking for people to maintain, improve or create web interface components. Maybe you would like to implement a webinterface page for your favorite application: It's not that difficult. If you want to contribute feel free to contact us. Any help whether it may be development, designing, translation or documentation stuff is highly appreciated. You will find all project-related links including a more detailed project description, the sourcecode repositories, screenshots and howtos on our current project website: http://luci.freifunk-halle.net Greetings Cyrus and Jow Lead Developers of LuCI ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hello wlanmac, at first thank you for your feedback. will it be difficult to remove overall or will the LuCI code be mixed up with non-GUI scripts? It's just a separate set of packages: not more, not less. As for LuCI, I would like to know more about why Lua and hence LuCI? You say It's not that difficult. - yet it does require learning a new language for most people and I don't see the huge benefit over using traditional shell scripts. That point would only matter if you do a shell-only interface like x-wrt did. But if you are using the Gargoyle approach - that is not bad but simply a different approach - you have to mess up with Shell and learn JavaScript or in your case *yourFrontendLanguage*. And you don't see any benefits of a programming language natively supporting floating point arithmetic, tables (hashmaps, arrays), a module-system, metatables (allowing prototyping, ...), file pointers, regular expressions, precompiled bytecode, ... over shell? It might be faster, but is that at the cost of complexity? You always have the complexity of separating view and programming logic as well as including i18n-support and multiple themes for example. It might be simple (once you know it) You should have a closer look at the LuCI documentation, the howtos and the source code. For the very basic stuff like writing a webinterface page for your application that already supports the UCI, it's just following a howto copying some code over and adapting it. And also for the more advanced tasks learning Lua is not that problem if you do know basic programming techniques and you should if you plan to develop an application. Besides that switching over from shell to Lua is easy if you keep in mind the sed/awk escapades in shell seen in other webifs. To the point the that JavaScript is probably more popular than Lua: If you know JavaScript it should be easy for you to learn Lua in a few days. but enough to attract new developers? oh, we will see. btw: It's not that difficult. vs. all using the same VERY simple XML GUI logic You see the point? ;-) I also agree with Eric, that the 'kitchen sink' doesn't really make for a good router interface. It might be useful for more advanced users - who know and understand all the options of a program, but not for your target audience, imho. I should have noted that before somewhere, but we are preparing a second simplified module that will not use the 'kitchen sink' but a smarter approach offering the most important features in a simplified form for the beginner (a bit like Gargoyle does). That would give us the ability to support both beginners and power users by letting the user decide which module of webif they are using. As it is not a good idea to only have a non-full-featured interface in the application. That's like domineering over the user. At least for the current state of the docs administrating OpenWRT via the shell and uci-cli is a bit painful. That's why we have started building the full-featured webif. And, as a application developer, I'm less interested in spending time making a 'smart' GUI for my application if it is limited to LuCI -- I would rather spend my time on something a bit more portable as my application also isn't limited to OpenWrt. I think that's not the point here: LuCI uses UCI (Universal Configuration Interface) that is an OpenWRT-only thing so we do not mess with the application itself but only throughout the standardized UC interface. And to not forget the application developer interests: Such an interface must link together different programs. Like when you want to use a WPA-encrypted DHCP-offering WLAN as your WAN interface. So you need the wpa-application, the dhcp-client, the wifi configuration subsystem and the network configuration subsystem of your os and probably also the firewall and for that all there is no OS (or even linux-distribution) independent solution. So you end up writing code for each linux distribution to be not limited to OpenWRT. Maybe not for all but I think for the greater part of the applications. And doing everything by hand with ip, iptables commands etc. would surely break the distribution's configuration system if you try to use an independent approach. So for me as an application developer it would be both not interesting to write an interface using LuCI or - if I understood your plans right - using your approach. That is at least some feedback. That notwithstanding, good work and great project! Thank you. I like the different approaches of you and Gargoyle that's how Open Source should work. And I also would be interested in seeing your sourcecode if you plan to make it public somewhere. greetings Cyrus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Yeah, sounds like many scripting languages... except shell ;-) Agreed, there is always some distribution specific glue needed. I'm leaning toward a 'meta configuration' (in XML) which can be edited, verified, and translated into distro specific configurations. Ah I see you added another abstraction layer in form of XML and have a kind of meta-format. Sounds interesting. We use a more UCI-based approach using an abstraction layer called CBI. The interface-designer just specifies a kind of model in Lua describing the scheme of the UCI file. This models conatins relations between configuration section and values like: there is a section, containing an on/off switch enabled and an optional text-value dummy. There is another text-value dummy2 but it will only be used when dummy is set. See this example: http://luci.freifunk-halle.net/WebUI/Documentation/ModulesHowTo#CBImodels The CBI then uses an appropriate renderer (at the moment HTML-templates) to create the output and validate the user input. As such, it is too bad it (the advanced logic part) can't be used outside of the GUI framework... or can it? You could for example use some Lua-ncurses bindings and write a CLI renderer for the CBI then you could completely reuse your models and i18n-files for a different thing and create a console based adminsitration app out of it but as long as you don't write an UCI - non-openwrt-configuration scheme translator it stays OpenWRT specific. And of course you cannot use any non-CBI-models like your HTML-templates that you may have written for something like a statuspage that shows your memory consumption. But regarding this you will use a different approach for such a thing when you use ncurses. But at least you could reuse the LuCI system library function that fetches the memory consumption information into a usable data structure. I'm not suggesting one approach is better than others. Developers tend to work with that they know (or otherwise have an interest in). And, one thing is for sure, with a user interface, no one solution is for everybody -- particularly so in OpenWrt devices, I'd say. That's right. Your approach also has its advantages and that's good. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hello Everyone, much work has been done this week and thanks to your feedback and opinions we are happy to inform you about the latest project updates. After the recent discussions about user-friendly vs. full-featured interfaces we decided to split up LuCI into two parts LuCI Administration and LuCI Essentials. Administration is the usual full-featured power-user interface while Essentials serves the non-power-user's needs by just providing the most important configuration settings in a simplified user-friendly way. Essentials contains configuration and status pages for basic Network, Wifi and System settings and can be extended with modules for Portforwarding, QoS, DDNS, UPNP, Time-Synchronization Everything of course with theme and translation support. You will find some screenshots of Essentials here: http://luci.freifunk-halle.net/WebUI/Screenshots/Essentials Build instructions - as usual - can be found here: http://luci.freifunk-halle.net/Installation LuCI Essentials (as well as LuCI Administration and the additional modules) can be found in your build configuration under Administration - LuCI - Webinterface Components after adding the LuCI OpenWRT feed to your buildroot. Greetings Cyrus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] About the new uci firewall
Try this: uci add firewall rule uci set [EMAIL PROTECTED] uci set [EMAIL PROTECTED] uci set [EMAIL PROTECTED] uci set [EMAIL PROTECTED] uci commit firewall Greetings Cyrus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rebooting from a kernel on external storage
Is it, or will it some day get Luci driven to operate as seamlessly as native firmware upgrades? Is this seamless enough: http://dev.luci.freifunk-halle.net/sysupgrade.png ;-) Greetings Cyrus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rebooting from a kernel on external storage
thats why UCI was invented I would have suggested some kind of on disk nvram emulation for such non-nvram capable systems so that the nvram paradigm remains the same for nvram capable systems and is emulated for others that have, say, persistent disk. Why emulate a 1 dimensional limited configuration system for all platforms, with a maximum capacity of 32kiB just because ONLY some old broadcom based routers use it? In this one dimension you cannot clearly create relationships between configuration options, you technically only have 1 datatype and you mess configurations together. I've heard that some other firmware projects use nvram-emulation but this is definitely very ugly. You will end up having lots and lots of abandoned configuration strings in your nvram if you use it overtime, install and uninstall packages etc. Clearly nvram has only disadvantages compared to UCI. But given the advances made with sysupgrade, this might be getting moot. I guess only time will tell if my fears of synchro problems between config files and sysupgrade manifest themselves. That is a problem that OpenWrt will face in the future when it comes to changes in some package/subsystem UCI format but you would and already had faced similar problems with nvram. That said, I wonder if sysupgrade has a user driven inventory list -- that is, a list of files to be included in the sysupgrade save set that the user can define. It has. It think this is a clean way Agreed, with the above idea. I disagree because that would create an unwanted relationship between ipkg and sysupgrade and also will result in having old configuration files if new versions of packages also have updated configuration files. anyway - if a config file changes you have always some fiddling by manual configuration. The most important thing is IMHO, that all network related stuff starts as usual. Probably networking stuff just just be kept backwards-compatible and/or include a conversion mechanism if a change is needed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd: Fix source routing
NAK, this would break source-dest-routing for IPv6 (documentation seems to be wrong here). Maybe we should use RTA_PREFSRC for IPv4 and RTA_SRC for IPv6? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd v2: Fix source routing for IPv4
Thanks, applied. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/4] netifd: Add igmpversion config support
On 03.12.2014 11:15, Hans Dedecker wrote: Config support to force the IGMP host version on device level; possible values are: 1|igmpv1: IGMP version 1 2|igmpv2: IGMP version 2 3|igmpv3: IGMP version 3 Thanks Hans. However, I don't really see the point of the string logic, it seems a bit bloated and the simple integer 1 2 or 3 should suffice imo. Also I'm wondering if this should set MLD version too (i.e. 1 if IGMP is 2 and 2 if IGMP is 3). Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/4] netifd: Add igmpversion config support
On 03.12.2014 11:39, Hans Dedecker wrote: Regarding the MLD version wouldn't it be preferable to have this as a different UCI parameter as I could imagine different versions in use for MLD and IGMP. Quite a lot of ISP's are still stuck to IGMPv2 in their network while they're using MLDv2 for IPV6. Okay, makes sense, thanks again. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] nftables development and support in openwrt
Hi Tomer, I am currently working on a kernel module which offloads traffic from the Networking stack. This is part of a project which optimizes IP forwarding for low end routers that have weak CPU and low on memory. Sounds interesting. Other approaches of speeding up forwarding are btw. also investigated right now, see https://dev.openwrt.org/changeset/43587 I saw that nftables and libnftables are not yet supported in my openwrt codebase (I am working with attitude adjustment 14.07) there is no attitude adjustment 14.07. attitude adjustment is 12.09, barrier breaker is 14.07. - but saw that recently some nftables related patches were added to the master branch by you. Could you please share the current status of nftables support in openwrt? nftables is packaged, I added some patches so that it is a bit more embedded friendly (some of those are upstream, some of them aren't). I also packaged and reorganised the netfilter kernel packages. So you can select nftables in menuconfig and can play around with it. You can also get rid of iptables and use nftables only by deselecting the related packages. Known Issues * In general its not well tested. It might blow up here or there. Help and bugreports are appreciated. * We are aiming for kernel 3.14 for the next release which has somewhat reasonable nftables support but lacks some useful things e.g. devgroups, extended reject support among maybe other things iirc. So it will be there to play around / get a first look at it but thats it. I don't know how the following release will look but I wouldn't keep my hopes up all too high there for it to change that much. * Which brings us to the main issue, our firewall abstraction (the firewall package, all the /etc/config/firewall magic) is tied to iptables at the moment, so if you want to use nftables right now you get bare metal and have to write your own rulesets completely from scratch, cannot use /etc/config/firewall or a gui. Hopefully someone will put some effort into this next year and refactor our firewall daemon to use nftables but thats a major effort. Also at the moment its not very clear when the netfilter team will create a high-level library to interact with nftables which would probably be sort of a prerequisite for it depending on how this rewritten daemon will work. Regardless, I will be happy to participate with the development and testing of nftables if needed, just let me know if I can help, Feel free to play around with it and send me bugreports etc. If it looks like an nftables bug you should probably contact the netfilter guys directly. If it looks like I messed up a patch or a package definition then tell me. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [package] shadow: unresolvable dependency with shadow-utils
Hi Gergely, my name is Gergely Kiss, I have recently started creating patches for openwrt and I'm about to publish some packages to the packages repository (some ported from oldpackages, others are brand new). Sounds good, thanks. Please read and follow our guidelines when doing pull requests (if you haven't already) since this will make it easier to review and we can push stuff faster. They can be found here: https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md root@OpenWrt:~# opkg install seafile-server Installing seafile-server (3.1.7-1) to root... Downloading file:///tmp/packages/seafile-server_3.1.7-1_ar71xx.ipk. Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for seafile-server: * shadow-utils * * opkg_install_cmd: Cannot install package seafile-server. As far as I can understand, shadow-utils is a pseudo-package only, it's install section is empty and therefore the package file is not generated, hence the dependency cannot be satisfied by opkg. I just pushed a fix to the packages feed. Please check if that solves your issue. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] python: file conflicts
Hi Gergely, this is the wrong place to post package-related patches and issues. Please do a pull requests here instead https://github.com/openwrt/packages/pulls and for issues please use: https://github.com/openwrt/packages/issues Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] nftables development and support in openwrt
You are right. I asked it in the netfilter-devel mailing list - libipct was never meant to be used as a public interface: http://www.netfilter.org/documentation/FAQ/netfilter-faq-4.html#ss4.5 Meh, absent of anything else it de-facto is anyway, see e.g. squid, miniupnpd and others using it as well. Also at the moment its not very clear when the netfilter team will create a high-level library to interact with nftables which would probably be sort of a prerequisite for it depending on how this rewritten daemon will work. I'm not sure if such a high level library is planned by the netfilter team, but why isn't libnftnl sufficient for rewriting the openwrt firewall daemon? I've seen a high-level library being mentioned in some nftables presentations, e.g. https://home.regit.org/wp-content/uploads/2014/09/2014_kernel_recipes_nftables.pdf The problem is this: libnftnl only allows manipulating nftables tables etc. but doesn't help with generating BPF-bytecode of the actual rules. This is done by the nftables-binary but not in a library. Generating that BPF-code is the actual hard part here and using libnftnl directly would mean we would have to do that on our own thus actually reimplementing the stuff that the nftables binary does. Another option would be to generate an nftables rule-file and applying this by calling the nftables binary, not exactly that trivial and / or clean either. Back to original problem of adding iptables rules awareness to kernel modules - I think that until nftables is fully supported in openwrt, it is possible to either patch the firewall package or libipct to notify about rules changes. Can such a change be acceptable in formal release? Notify whom? I mean we could probably notify someone or something when the high-level openwrt firewall is reloaded. In fact there is already a user-script hook. Cheers, Steven Best Regards, Tomer On Mon, Dec 15, 2014 at 9:18 AM, Steven Barth cy...@openwrt.org wrote: Hi Tomer, Regarding the firewall package - its probably a dumb question, but isn't this the reason for nftables' compatibility layer? (http://git.netfilter.org/iptables-nftables/) afaik - and please correct me if I'm wrong - that works only for the iptables CLI command, however our firewall tool currently uses libiptables directly so I don't think it would work easily. Cheers, Steven Best Regards, Tomer On Dec 14, 2014 7:08 PM, Steven Barth cy...@openwrt.org wrote: Hi Tomer, I am currently working on a kernel module which offloads traffic from the Networking stack. This is part of a project which optimizes IP forwarding for low end routers that have weak CPU and low on memory. Sounds interesting. Other approaches of speeding up forwarding are btw. also investigated right now, see https://dev.openwrt.org/changeset/43587 I saw that nftables and libnftables are not yet supported in my openwrt codebase (I am working with attitude adjustment 14.07) there is no attitude adjustment 14.07. attitude adjustment is 12.09, barrier breaker is 14.07. - but saw that recently some nftables related patches were added to the master branch by you. Could you please share the current status of nftables support in openwrt? nftables is packaged, I added some patches so that it is a bit more embedded friendly (some of those are upstream, some of them aren't). I also packaged and reorganised the netfilter kernel packages. So you can select nftables in menuconfig and can play around with it. You can also get rid of iptables and use nftables only by deselecting the related packages. Known Issues * In general its not well tested. It might blow up here or there. Help and bugreports are appreciated. * We are aiming for kernel 3.14 for the next release which has somewhat reasonable nftables support but lacks some useful things e.g. devgroups, extended reject support among maybe other things iirc. So it will be there to play around / get a first look at it but thats it. I don't know how the following release will look but I wouldn't keep my hopes up all too high there for it to change that much. * Which brings us to the main issue, our firewall abstraction (the firewall package, all the /etc/config/firewall magic) is tied to iptables at the moment, so if you want to use nftables right now you get bare metal and have to write your own rulesets completely from scratch, cannot use /etc/config/firewall or a gui. Hopefully someone will put some effort into this next year and refactor our firewall daemon to use nftables but thats a major effort. Also at the moment its not very clear when the netfilter team will create a high-level library to interact with nftables which would probably be sort of a prerequisite for it depending on how this rewritten daemon will work. Regardless, I will be happy to participate with the development and testing of nftables if needed, just let me know if I can help, Feel free to play around with it and send me bugreports etc
Re: [OpenWrt-Devel] [PATCH] iproute2: bump version from 3.16.0 to 3.17.0
applied, thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: allow de-selecting features from -full variant.
applied, thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] batman-adv ipv6
There were no firewall changes for quite a while really and IPv6 configuration hasn't been touched for quite a while either and if you have ruled out the igmp_snooping as a source of error then thats a bit confusing. OpenWrt switched from using kernel-mode IPv6 RA handling (SLAAC) to handling RAs in userspace some time after the AA release that means you need to have a proto=dhcpv6 interface section in /etc/config/network for using IPv6 SLAAC (in forwarding mode) as is done in the default configuration of OpenWrt. Alternatively you might set the sysctl value to accept RAs in forwarding mode but this is greatly discouraged and might cause some issues with other parts of OpenWrt. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: Makefile fixes and cleanups
NAK, unless you deal with all the dnsmasq-dhcpv6 and dnsmasq-full missing in opkg tickets afterwards ;) On a more serious note, some people depend on the precompiled stuff and they would probably not welcome that change all too much. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is there something preventing me from watching github openwrt/packages?
You can watch any repository you like. If something goes wrong its probably either github's or your browser's (or its addons') fault. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/3] iproute2: bump version to 3.18.0
Applied, thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
