Re: [OpenWrt-Devel] Unable to create GRE interface using netifd
You are most likely missing a route to the remote tunnel endpoint (192.168.11.5). The system doesn't know which interface and next hop to send the tunneled packets to, thats why its blocking the tunnel bringup. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Git mirror with branches, tags and full history
Hey everyone, I took the time last week to create a full-history git-mirror with branches, author mapping and release tags. It is currently on github, but it will probably end up on git.openwrt.org in the end. Note: Do NOT send us pull requests to this repository, they will be ignored. Send patches to this mailing-list instead. Now finally the mirror is at: https://github.com/openwrt/openwrt Since the authors are mapped, it is NOT compatible with the current git-mirror. Let us know what you think. 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/2] [netifd] multicast flag control
I'm sorry but this patch doesn't apply: Applying patch #532998 using 'git am' Description: [OpenWrt-Devel,1/2,netifd] multicast flag control Applying: multicast flag control error: patch failed: device.c:40 error: device.c: patch does not apply error: patch failed: system-linux.c:1091 error: system-linux.c: patch does not apply error: patch failed: device.h:34 error: device.h: patch does not apply Patch failed at 0001 multicast flag control The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". 'git am' failed with exit status 128 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Progress on Reproducible Builds
Hello Bryan, thanks a lot for your efforts. I would suggest to submit the patchset to this list (with added Signed-Off-By tags) and we can discuss the individual ones here then. Thanks, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
> > Step 5 is unnecessary, patchwork sends emails on status changes. Okay, it seems it does this only for the original submitter, right? I guess it might come in handy to send it to the ML as well, or at least make that possible in the WebUI. > I usually copy the mbox link from patchwork and do this: wget -O- | > git am Yes, I guess that is easier than pwclient. Though it doesn't solve patchsets really. > >> Compared to Github, Gitlab or Gerrit this is bullshit. > Even with those, there is some bouncing around in counter-intuitive ways > if your process includes testing a commit before pushing it. Yes, this is true and I see that really as the main valid point for criticism. Ideally you want the "magic merge" only happen to your (local?) branch and not the main one and then manually send off a batch of staged commits manually via git push, so that would be the downside of using one of those tools. > What would your preferred workflow be? Please list the exact series of > steps for it. So to summarize, based on the current workflow: 1. Be able to send mails (and change status) from within patchwork, e.g. how you can do it in trac, just that it gets send out to the ML and the author instead of being just hidden in some UI. 2. Download a whole set of the patches (e.g. one patch series) without having to do it for all patches indivdually (e.g. like Github let's you download a whole pull-request as a single patchfile). I'm fine with it even not keeping track what patches belong to which series, but just having e.g. a page with checkboxes where I can tick patches and some where on the bottom click "download series as .patch". 3. Have some kind of tool that applies stuff locally (but I guess one could write some handler and associate that with .mbox or .patch and just click on the downloaded patch (serieses) and apply them like that). 4. Ideally have some sort of integration with a bugtracker. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
Let's face it though: the current workflow wrt. core patches is crappy. 1. Go to patchwork, see if there is a patch 2. If you want to comment, switch to mail client, find thread, write reply. 3. If you want to commit: download patch, go to command line, see if it applies 4. Then manually go back to patchwork and adjust the status of the patch. 5. Upon merging go back to mail and write a mail ala "Patch Accepted". Sure could use pwclient and ocassionally do, however it does essentially one thing only: save me the download step. Yes, I can also save me the click back to the browser to hit accept and can do that via CLI (if I remember the cryptic switches). On top of that now I have to deal with an opaque 5 or 6-digit patch id in my head. Compared to Github, Gitlab or Gerrit this is bullshit. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
>> Let's face it though: the current workflow wrt. core patches is crappy. >> >> 1. Go to patchwork, see if there is a patch >> 2. If you want to comment, switch to mail client, find thread, write reply. >> 3. If you want to commit: download patch, go to command line, see if it >> applies >> 4. Then manually go back to patchwork and adjust the status of the patch. >> 5. Upon merging go back to mail and write a mail ala "Patch Accepted". >> >> >> Sure could use pwclient and ocassionally do, however it does essentially one >> thing >> only: save me the download step. Yes, I can also save me the click back to >> the >> browser to hit accept and can do that via CLI (if I remember the cryptic >> switches). >> On top of that now I have to deal with an opaque 5 or 6-digit patch id in my >> head. >> >> Compared to Github, Gitlab or Gerrit this is bullshit. >> > > lets face it, it works very well. if you find it crappy then please > provide consistent reasons why this is so. If you find the steps above a sensible workflow, i.e., I essentially need to switch between 3 different programs having no connection between one another at all to merge a patch then I don't know what arguments could actually convince you. > currently having people look at every patch while merging it is very > usefull and leads to a solid codebase. So, the assumptions is, because its email everyone reads everything and magically doesn't filter by subject etc. and when you switch to Gitlab or similar people suddenly change? Tbh. I don't care if its email or some sort of web-based stuff, as long as tracking the patches actually doesn't add more overhead than it delivers value aka. the way we use patchwork. If we had a patch-tracker that let's me reply (send mail) directly from the gui and optionally doesn't make it a stupid hassle to merge a whole patchset then I don't have a problem with e-mail. I'm sorry that I actually value my free time when doing either volunteer or paid work. And don't get me started about having a completely different Issuetracker with different credentials etc. > having the github "click and merge" stuff will lead to people "clicking > and merging" and not reviewing it properly. So, you don't trust the same group of people having push-access if they would be using a web-interface over the current e-mail approach? > i understand that some people love to upload their data to us based > cloud services. but then again i would argue that this is a really illy > thing to do for a whole number of reasons. first of all our dependence > on that $corporation Right, because a self-hosted Gitlab or Gerrit instance will send data to the US. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
>>> What would your preferred workflow be? Please list the exact series of >>> steps for it. >> So to summarize, based on the current workflow: >> 1. Be able to send mails (and change status) from within patchwork, e.g. >> how you can do it in trac, just that it gets send out to the ML and the >> author instead >> of being just hidden in some UI. > Maybe you could suggest that to the patchwork author. I guess so. > >> 2. Download a whole set of the patches (e.g. one patch series) >> without having to do it for all patches indivdually (e.g. like Github >> let's you download >> a whole pull-request as a single patchfile). I'm fine with it even not >> keeping track what >> patches belong to which series, but just having e.g. a page with >> checkboxes where >> I can tick patches and some where on the bottom click "download series >> as .patch". > Just select a bunch of patches, put in a name at the bottom of the page > and click "Create bundle". You can download that bundle as .mbox Yeah using bundles can sort of do that, but it can get cumbersome quickly as well. You first have to select the patches and create a new bundle, then click on bundles, and click download for the new bundle which I guess is somewhat reasonable. However once you are done, you have to either - remove accepted patches from the bundle or kill the whole bundle and start over next time, because the bundle always gets you all patches in it, including the ones accepted or rejected. I guess again, its a start but needs some improvements to feel really convenient. Maybe suggesting a second button to the author "download patches needing action" or so, would do it. > >> 4. Ideally have some sort of integration with a bugtracker. > What kind of integration and for what purpose? It's mainly having some tool that is integrated, i.e., uses same credentials and maybe even the possibility to close related tickets just by accepting the patches. Using entirely different tools just feels a bit unnecessary. I do not consider that to be an essential issue really, more like a nice to have which you get to like when working with more integrated environments. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] Add package django-sslserver
Please read our package submission guidelines here https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md and once your submission complies, create a pull request at: https://github.com/openwrt/packages Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SVN to GIT transition
One important point was IIRC, migrating from one stable branch to another is awkward since the history is different, so rebasing custom changes on top is painful. All in all there was relatively overwhelming feedback of most of the people at the summit that there lifes would be very much easier if the main repo was based on git and there was noone who really felt the opposite. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH netifd] netifd-proto.sh: add table argument to proto_add_ipv4_route()
Alexander, I don't have a problem with that particular patch. However since the other patch was redundant and the only user of this one it seemed redundant to me as well. If you have another usecase for this then please let us know. Cheers, Steven On 29.09.2015 11:37, Alexander Couzens wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi Steven, > > you rejected this patch as well. > > Why would you not allow to define a specific table for ipv4, but for > ipv6? > >> cy...@openwrt.org >> NAK. Use "option ip4table" and "option ip6table" which works with >> all protocols already. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWClv2AAoJEMKenaag34YEpGUP/1j+pipA5j9C7vkfAMyYqkkU > ZzDR3k/rEXK9JeAXVABagSG3SRmfOGOCkgFMShW4vxapO7beKViAFU/tUroSB69K > +hdCFMqkUcKtAa9AMm0JDkA5tkNxQ3uBPNAnj/PTxNMFFRDk2+qX7Do05Y4KbB2g > FWeialu1K5pJydPFeu2fP1ajID05phOlJPHjalLyDjYLtPU2KDDSiGICmldGo18J > 0RDgy4/9GVxGkU8v3+3S5szQWZxns2M/CJSJ0T182cHpLRzP2qOFvt802q+hdm1i > latOWvVJ6+qsX0rMJh3SlSMF75vWo6FkAkld4vpiWtF0KT718v1+xEF+DDou9pw4 > QLhb/OO52Ic2Qv81St7kkknVQU45jcOA3JNQsB9UpDxRSng0QnTZyX507B8iHfJh > XfHOz5ZBgZ1J+OW/RgPf889ChUtGWYlFU31snZWPfBcSVsHuKpZ396SoKyqDWOZI > GuSnNQViYrgBQAba98Y0UlYQ+lFxHs4+Vivd2qzGE/9RxhR4wuSWbiI5vKic2S1r > anEklRrDpv0zo8tyaEKKetMyE9K2l2k3zEJ54jJhALC9vldX+cEnYnvqt5zN3ImE > hHO8BtlrjcdUGOu9xHyWG4Igsra23wGZ0UGAuGVDGyED3oBFX4kJlv3JF4g9DEiV > 6xqiqLeAcZ/f5+gVaua3 > =Xe6x > -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd: add table argument to dhcp(v4)
NAK. Use "option ip4table" and "option ip6table" which works with all protocols already. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: prevent forwarding RFC6303 zones
There is already "option boguspriv 1" so I do not really see the point. 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 v2] base-files: init/sysfixtime - exclude dnsmasq.time
Using --dnssec-no-timecheck is impractical since it reacts to SIGHUP which is already overloaded and might be triggered by e.g. config changes. Btw. an ntp hotplug infrastructure exists: https://dev.openwrt.org/changeset/43421 Please also consider that some devices have an RTC, so disabling timecheck indiscriminately at startup might not be ideal either. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Chaos Calmer 15.05
The OpenWrt developers are proud to announce the final release of OpenWrt Chaos Calmer. ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M - CHAOS CALMER (15.05) - * 1 1/2 oz GinShake with a glassful * 1/4 oz Triple Sec of broken ice and pour * 3/4 oz Lime Juice unstrained into a goblet. * 1 1/2 oz Orange Juice * 1 tsp. Grenadine Syrup - - http://downloads.openwrt.org/chaos_calmer/15.05/ ** Highlights since Barrier Breaker ** * Linux kernel updated to version 3.18 * Improved Security Features - Rewritten package signing architecture based on ed25519 - Added support for jails - Added support for hardened builds * Improved Networking Support - Added or improved support for lots of 3G/4G modems (MBIM, QMI, NCM, ...) - Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050] - Netfilter performance enhancements (conntrack route cache) - Improved support for self-managing networks [draft-ietf-homenet-hncp] - Better multi-core support for the network stack - Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning technologies [draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6] - Improved network auto-setup capable of detecting and bootstrapping IPv4-only, 6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT and combinations without explicit configuration [based on RFC 7084] - Added support for Smart Queue Management (SQM) QoS, AQM and Traffic Shaping - Improved support for DNSSEC * Platform and Driver Support - Added support for feeds of externally maintained targets - New mt7621 subtarget for Mediatek 11ac SoC - New mt76 mac80211 based wifi driver for MTK 11ac cores. - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices - New mxs target for Freescale i.MX23/28 family and various boards - New sunxi target for AllWinner A10/A13/A20 family and various boards - brcm2708: support for Raspberry Pi 2 - brcm63xx: support for BCM6318 and BCM63268 family - brcm63xx: improved fallback sprom support with bcma support ** Improvements since RC 3 ** * Updated 3.18 to 3.18.20 * Security update of openssl to 1.0.2d * Security update of curl * brcmfmac: many BCM43602 related fixes * ar71xx: support more devices * brcm47xx/bcm53xx: support any NVRAM size * bcm53xx: basic Netgear R7000 support & R8000 image ** Improvements since RC 2 ** * brcmfmac: support for BCM43602 * mt76: updated version with new firmware support, TX & DMA fixes * Updated 3.18 to 3.18.17 * Fixed image builder generation * Various security updates (e.g. openssl, curl) * Minor fixes ** Improvements since RC 1 ** * Fixed broken ImageBuilders for most targets * Updated 3.18 to 3.18.14 * Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling * Images (special format) for Asus brcm47xx and bcm53xx devices * Improved stability of sysupgrade on brcm47xx and bcm53xx * Added HTTPS enforcement option to uhttpd * Fixed umask issue * Added support for a few new boards And lots and lots of other advancements... As always a big thank you goes to all our active package maintainers, testers, supporters and documenters. Have fun! The OpenWrt developer team ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] thanks for r46829 / replace ifconfig-usage with ip
Well it's not yet abandoned we still have to migrate a lot of stuff under target/ and in the feeds. ifconfig and route won't go away before that happens. Besides I guess it's a more pressing issue now with IPv6 and so on where the old tools are relatively useless. As we are making some more ground-breaking changes and breaking all kinds of stuff, we might as well introduce ip. DD will be the first "non-alcoholic" release after all so who knows what other crazy thing we will come up with before 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] Removing Telnet
Hello Michael, that is interesting, though I guess since these are mainly our default it shouldn't be too hard for someone manufacturing to change the config and readd a simple init-script for telnetd if that is really required. Lack of entropy doesn't seem to be too much of an issue here, in fact in failsafe mode we generate a 1024 bit RSA-key on demand which takes <2s on my old Buffalo here. Granted its only 1024-bit but still. Now the regular keys are 2048-bit which takes about a minute which could be seen as problematic. However in the verge of making these changes we also removed DSS support and removed some of the ciphers (3DES, Twofish) and CBC mode in general as well, so we at least save ourselves the DSS key generation. In the future we might want to switch to add ed25519 since its more secure and probably faster than the classical approaches mechanisms here, but we have to ensure that it is compatible with at least most common SSH clients out there, mainly probably Putty on Windows and OpenSSH on Linux & OS X. 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] uqmi: Add proper IPv6 support
Hello Matti,
thanks, I very much support this patch.
One little thing:
proto_add_ipv6_route "::0" 0 "$gateway_6"
should be
proto_add_ipv6_route "::0" 0 "$gateway_6" "" "" "${ip_6}/${ip_prefix_length}"
otherwise this might break IPv6 connectivity in the presence of other
IPv6 connections. In general for IPv6 routes must be source-restricted
to the prefixes and addresses that the ISP delegated, otherwise it might
happen that the routers tries to route traffic with source-addresses
from a different ISP through this connection and the ISP might drop the traffic
due to the source-addressing being "spoofed" essentially creating a blackhole.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Removing Telnet
Hello everyone, as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of the base images. As a replacement, it is now possible to login to the root- account via SSH without a password prompt whenever no root password is set, e.g. after a flash without keeping config, factory reset or in failsafe. We will see how that goes. Let us know if there are any 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] [PATCH] openwrt/hardening: Fix CFLAGS usage for -D_FORTIFY_SOURCE
NAK. Not many package build systems honors CPPFLAGS so this solution is impractical, since it effectively disables fortification for many of them. To my knowledge c-ares is the only package enforcing this kind of behavior so it should be fixed to work with our buildsystem instead. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: bridge, multicast-to-unicast: fix echoes on STA
Am 02.09.2015 um 05:17 schrieb Linus Lüssing: > Currently, multicast packets from an STA are sent to any according > multicast listener directly through the bridge multicast-to-unicast > feature. Unfortunately, so far this includes the originating STA, too, > resulting in multicast packets being echo'ed back to the originating STA > if it itself is a multicast listener for that group. Thanks Linus, I can confirm the patch fixes the issue. Unless Felix has any objections I will push it in the coming days. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert "kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)"
>Ok, I was able to easily reproduce the issue here. Looking at the >tcpdump the wifi client receives its own Neighbor Solicitation >again, reflected through the bridge-hairpin option. Why are we reflecting packets back to the originator anyway? Could it not be excluded? Btw. once we are bit more stable i will try to test how the igmpv3/mldv2 querier / proxy I wrote interacts here (disabling kernel querier). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)
Hi Linus, one of these two kernel patches break IPv6 over WiFi completely. https://dev.openwrt.org/changeset/46719 works https://dev.openwrt.org/changeset/46723 is broken with default settings, but works when setting option igmp_snooping 0. symptoms are: IPv6: wlan0: IPv6 duplicate address fe80::[...] detected! in the client's kernel log when connecting using WiFi. Connecting through Ethernet (bridged to said WiFi) works as expected though. Since the link-local is marked as dadfailed over WiFi, IPv6 connectivity is completely broken, obviously the DAD failed is a false positive. Router is ar71xx / ath9k. Client is iwlwfi. Let me know if you need more info. 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 2/2] proto-shell: add checkup timeout to restart interface.
Hello Yousong, thanks for your patch. Shouldn't there by a timeout cancel path somewhere in case the protocol gets removed after the timer was armed but before it was fired? I could imagine it causing memory corruption otherwise. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Recommended settings ip6 DNS server / dnsmasq
I could solve all issues and write a complete HOWTO (in French only at first).http://wiki.openwrt.org/doc/howto/freebox That is nice to hear. OpenWRT seems to provide at the same time stateful and stateless adressing. Where you have option dhcpv6 and option ra you can add an option ra_management and set it to 0, 1 or 2. 0 means stateless only, 1 means stateless + stateful (default) 2 means stateful only Please note that stateful is not supported by all clients, e.g. all android-based devices will not have IPv6 connectivity with setting 2. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Recommended settings ip6 DNS server / dnsmasq
I'm not sure what you are trying to accomplish. If you are connecting a router with a default OpenWrt image with default configuration to an ISP or IPv6 router which offers prefix delegation, everything works out of the box including client configuration. You don't need to touch a single config file. OpenWrt serves stateless and stateful addresses to clients by default, the combination of option duid and option hostid should also work to change the hostid (I'm using it right now). So could you please explain what is special about the freebox as an uplink (sorry I don't speak french so I can't decode your wiki page)? What is currently working and what is broken for you? What addresses do your clients get? Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Recommended settings ip6 DNS server / dnsmasq
Hello Jean-Michel, according to your Wiki-Entry stateful addressing does work, no need to do anything with dnsmasq. Quoting your ifconfig output addr inet6: 2a01:e35:87d8:::953/128 Scope:Global is clearly a stateful address (/128) and your host got the host-id 953 for stateful adressing. You should see the lease on the router in the WebUi or under /tmp/hosts/odhcpd. There you can also see the duid you need for adding the static lease. At some point using the mac-address (option mac) should work here as well but it might be broken currently. I will put it on my todo. Nevertheless: config host option duid '0012345678900...' option hostid 4 is what works already. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Not able to get ipv6 address on OpenWrt ported embedded target
Add a section like this: config lan6 option proto dhcpv6 option ifname @lan And yes, proto dhcpv6 also works with RAs only. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Not able to get ipv6 address on OpenWrt ported embedded target
Sorry there was a typo in my last e-mail. It should have been: config interface lan6 option proto dhcpv6 option ifname @lan After doing the change, please run: reload_config Cheers, Steven Am 24.07.2015 um 14:27 schrieb Pratik Prajapati: I have added that section on target's /etc/config/network file but still ipv6 is not assigned to it ifconfig on target: eth0 Link encap:Ethernet HWaddr E2:AB:C0:A8:5F:38 inet6 addr: fe80::e0ab:c0ff:fea8:5f38/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8730 errors:0 dropped:0 overruns:0 frame:0 TX packets:191 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:968468 (945.7 KiB) TX bytes:17574 (17.1 KiB) Interrupt:57 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:8225 errors:0 dropped:0 overruns:0 frame:0 TX packets:8225 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:677074 (661.2 KiB) TX bytes:677074 (661.2 KiB) On Fri, Jul 24, 2015 at 5:32 PM, Steven Barth cy...@openwrt.org mailto:cy...@openwrt.org wrote: Add a section like this: config lan6 option proto dhcpv6 option ifname @lan And yes, proto dhcpv6 also works with RAs only. ___ 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] [PATCH] dnsmasq bump to dnsmasq2.74rc3
I don't think we should be tracking RCs any longer. I did this for 2.73 mainly due to the security exploit and there not being a stable update, plus DNSSEC was pretty screwed before that. I think we should go back to backporting individual fixes via patches instead. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc3
Sorry, small mistake. Kernel is 3.18.17 in RC3. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Chaos Calmer 15.05-rc3
The OpenWrt developers are proud to announce the third release candidate of OpenWrt Chaos Calmer. ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M - CHAOS CALMER (15.05 RC3) - * 1 1/2 oz GinShake with a glassful * 1/4 oz Triple Sec of broken ice and pour * 3/4 oz Lime Juice unstrained into a goblet. * 1 1/2 oz Orange Juice * 1 tsp. Grenadine Syrup - - http://downloads.openwrt.org/chaos_calmer/15.05-rc3/ ** Improvements since RC 2 ** * brcmfmac: support for BCM43602 * mt76: updated version with new firmware support, TX DMA fixes * Updated 3.18 to 3.18.18 * Fixed image builder generation * Various security updates (e.g. openssl, curl) * Minor fixes ** Improvements since RC 1 ** * Fixed broken ImageBuilders for most targets * Updated 3.18 to 3.18.14 * Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling * Images (special format) for Asus brcm47xx and bcm53xx devices * Improved stability of sysupgrade on brcm47xx and bcm53xx * Added HTTPS enforcement option to uhttpd * Fixed umask issue * Added support for a few new boards ** Highlights since Barrier Breaker ** * Linux kernel updated to version 3.18 * Improved Security Features - Rewritten package signing architecture based on ed25519 - Added support for jails - Added support for hardened builds * Improved Networking Support - Added or improved support for lots of 3G/4G modems (MBIM, QMI, NCM, ...) - Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050] - Netfilter performance enhancements (conntrack route cache) - Improved support for self-managing networks [draft-ietf-homenet-hncp] - Better multi-core support for the network stack - Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning technologies [draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6] - Improved network auto-setup capable of detecting and bootstrapping IPv4-only, 6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT and combinations without explicit configuration [based on RFC 7084] - Added support for Smart Queue Management (SQM) QoS, AQM and Traffic Shaping - Improved support for DNSSEC * Platform and Driver Support - Added support for feeds of externally maintained targets - New mt7621 subtarget for Mediatek 11ac SoC - New mt76 mac80211 based wifi driver for MTK 11ac cores. - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices - New mxs target for Freescale i.MX23/28 family and various boards - New sunxi target for AllWinner A10/A13/A20 family and various boards - brcm2708: support for Raspberry Pi 2 - brcm63xx: support for BCM6318 and BCM63268 family - brcm63xx: improved fallback sprom support with bcma support - New ipq806x target for QCA IPQ806x SoC family * Known Issues - KALLSYMS is active causing some devices to fail And lots and lots of other advancements... As always a big thank you goes to all our active package maintainers, testers, supporters and documenters. Have fun! The OpenWrt developer team ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc3
Does this Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling fix the issue with loosing the default gateway for IPv6 and only fixing when you reboot the router ? I haven't heard of such an issue. This might be something specific to your ISP which is outside of our range or maybe not, but I would need more information such as a pcap of ICMPv6 / DHCPv6 traffic on your egress interface to figure this one out. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] IPv6/odhcpd: Attempt to workaround phones ignoring RAs in standby + to fix NDP-relays
Hi everyone, I just pushed a few experimental changes to trunk for odhcpd. #1 Unsolicited RAs are now also sent via unicast to known neighbors This may help address an issues commonly seen in some android phones. Some popular devices seem to ignore MC RAs during standby / display off, thus once address / route lifetimes run out they loose IPv6 connectivity. IPv6 connectivity is only regained after the device is in use AND the next multicast RA is received. For details, see: https://code.google.com/p/android/issues/detail?id=32662 #2 Finally, another attempt at fixing the NDP / RA / DHCPv6 relay. Some kernel semantics seem to have changed and I hope the new version works better now. Both changes are experimental, so if you are affected it would be nice to get some feedback. 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] toolchain/uClibc: add uclibc-ng 1.0.3
Thanks for the effort. However, I personally think we should rather phase out uclibc completely and focus on musl which has a much cleaner codebase. I don't think it is worth in the long run to maintain support for both libcs given our limited ressources. 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/2] dnsmasq: enable extra tracing by default when UCI parameter logqueries is set
Applied, thanks.
Am 06.07.2015 um 18:29 schrieb Hans Dedecker:
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index b0a5fbc..bbe2b56 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -121,7 +121,7 @@ dnsmasq() {
append_bool $cfg nohosts --no-hosts
append_bool $cfg nonegcache --no-negcache
append_bool $cfg strictorder --strict-order
- append_bool $cfg logqueries --log-queries
+ append_bool $cfg logqueries --log-queries=extra
append_bool $cfg noresolv --no-resolv
append_bool $cfg localise_queries --localise-queries
append_bool $cfg readethers --read-ethers
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Revert 46119 (hardening: make override variables more intuitive)
Hi Etienne, I don't get your issue. 46119 only unifies the override variables, meaning if a package maintainer wants to override e.g. RELRO he now only needs to add PKG_RELRO:=0 instead of adding two for both RELRO modes. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] oldpackages for CC
oldpackages are obsolete and in many instances riddled with security issues. They should not be used at all. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
You should see an unreachable route for your own local ULA /48. Also if your clients try to use your local ULA as source to reach anything outside of the ULA (e.g. global addresses) this is blocked (there is no matching route - simpler explanation to my previous post). I don't see any particular point to blocking all of the ULA-space as destination though. If you think its useful for you you can either add a firewall route or an unreachable route manually in /etc/config/firewall or /etc/config/network respectively. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
Source-Destination matching is done in the regular routing table. E.g. for my he.net connection the v6 routing table looks like this: default from 2001:470:xx:yyy::/64 dev 6in4-henet proto static metric 1024 default from 2001:470:::/48 dev 6in4-henet proto static metric 1024 if you try to send with a ULA there is no matching route since there is no unspecific default route. Also I disagree about the general usefulness of a fc00::/7 block. I can imagine e.g. a VPN-scenario where (on top of tunneling internet access) you access certain local services which have ULAs. This would essentially be broken by your generic rule for not much added gain. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
That commit got reverted 4 months later and was never really in use for long. Source-Destination routing has been used to replace it for egress traffic, i.e. there are simply no external (e.g. default) routes that have a matching source-restriction. For ingress traffic the stateful firewall handles this automatically (unless you manually open it, then you might want to consider adding a rule again here). Using policy rules for incoming would be possible yes, however since we have a zone-based firewall replicating the zones with policy rules is awkward. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update dnsmasq to v2.73.
Thanks, applied to trunk and CC. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc2
Since you are replying to the Chaos Calmer announcement, have you actually tried it with the CC RC2 or only BB as you mentioned? If not, then please try if CC makes a difference to you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Chaos Calmer 15.05-rc2
The OpenWrt developers are proud to announce the first release candidate of OpenWrt Chaos Calmer. ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M - CHAOS CALMER (15.05 RC2) - * 1 1/2 oz GinShake with a glassful * 1/4 oz Triple Sec of broken ice and pour * 3/4 oz Lime Juice unstrained into a goblet. * 1 1/2 oz Orange Juice * 1 tsp. Grenadine Syrup - - http://downloads.openwrt.org/chaos_calmer/15.05-rc2/ ** Improvements since RC 1 ** * Fixed broken ImageBuilders for most targets * Updated 3.18 to 3.18.14 * Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling * Images (special format) for Asus brcm47xx and bcm53xx devices * Improved stability of sysupgrade on brcm47xx and bcm53xx * Added HTTPS enforcement option to uhttpd * Fixed umask issue * Added support for a few new boards ** Highlights since Barrier Breaker ** * Linux kernel updated to version 3.18 * Improved Security Features - Rewritten package signing architecture based on ed25519 - Added support for jails - Added support for hardened builds * Improved Networking Support - Added or improved support for lots of 3G/4G modems (MBIM, QMI, NCM, ...) - Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050] - Netfilter performance enhancements (conntrack route cache) - Improved support for self-managing networks [draft-ietf-homenet-hncp] - Better multi-core support for the network stack - Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning technologies [draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6] - Improved network auto-setup capable of detecting and bootstrapping IPv4-only, 6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT and combinations without explicit configuration [based on RFC 7084] - Added support for Smart Queue Management (SQM) QoS, AQM and Traffic Shaping - Improved support for DNSSEC * Platform and Driver Support - Added support for feeds of externally maintained targets - New mt7621 subtarget for Mediatek 11ac SoC - New mt76 mac80211 based wifi driver for MTK 11ac cores. - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices - New mxs target for Freescale i.MX23/28 family and various boards - New sunxi target for AllWinner A10/A13/A20 family and various boards - brcm2708: support for Raspberry Pi 2 - brcm63xx: support for BCM6318 and BCM63268 family - brcm63xx: improved fallback sprom support with bcma support * Known Issues - Sysupgrade on brcm47xx may fail by running out of memory when using .bin or .chk files. Please use .trx when using rc1 (it was fixed in rc2). - openssl and strongswan are outdated. If you intend to use either of them please update the packages using the snapshots repository: https://downloads.openwrt.org/snapshots/trunk/ And lots and lots of other advancements... As always a big thank you goes to all our active package maintainers, testers, supporters and documenters. Have fun! The OpenWrt developer team ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] ppp : Unnumbered support
Applied, thanks.
On 12.06.2015 09:26, Hans Dedecker wrote:
Adds PPP unnumbered support via the parameter unnumbered which points to a
logical OpenWRT interface.
The PPP proto shell handler will borrow an IP address from the unnumbered
interface (if multiple
IP addresses are present the longest prefix different from 32 will be
borrowed) for which a host
interface dependency will be created. Due to the host interface dependency
the PPP unnumbered interface
will only borrow an IP address from an interface which is up.
The borrowed IP address will be shared as local IP address by the PPP daemon
and no other local IP
will be accepted from the peer in the IPCP negotiation.
A typical use case is the usage of a public IP subnet on the Lan interface
which will be shared
by the PPP interface as local IP address.
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
package/network/services/ppp/files/ppp.sh | 40
++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/package/network/services/ppp/files/ppp.sh
b/package/network/services/ppp/files/ppp.sh
index 1a72a1e..a6389a8 100755
--- a/package/network/services/ppp/files/ppp.sh
+++ b/package/network/services/ppp/files/ppp.sh
@@ -4,10 +4,35 @@
[ -n $INCLUDE_ONLY ] || {
. /lib/functions.sh
+ . /lib/functions/network.sh
. ../netifd-proto.sh
init_proto $@
}
+ppp_select_ipaddr()
+{
+ local subnets=$1
+ local res
+ local res_mask
+
+ for subnet in $subnets; do
+ local addr=${subnet%%/*}
+ local mask=${subnet#*/}
+
+ if [ -n $res_mask -a $mask != 32 ]; then
+ [ $mask -gt $res_mask ] || [ $res_mask = 32 ] {
+ res=$addr
+ res_mask=$mask
+ }
+ elif [ -z $res_mask ]; then
+ res=$addr
+ res_mask=$mask
+ fi
+ done
+
+ echo $res
+}
+
ppp_exitcode_tostring()
{
local errorcode=$1
@@ -53,12 +78,14 @@ ppp_generic_init_config() {
proto_config_add_boolean authfail
proto_config_add_int mtu
proto_config_add_string pppname
+ proto_config_add_string unnumbered
}
ppp_generic_setup() {
local config=$1; shift
+ local localip
- json_get_vars ipv6 demand keepalive keepalive_adaptive username
password pppd_options pppname
+ json_get_vars ipv6 demand keepalive keepalive_adaptive username
password pppd_options pppname unnumbered
if [ $ipv6 = 0 ]; then
ipv6=
elif [ -z $ipv6 -o $ipv6 = auto ]; then
@@ -73,6 +100,16 @@ ppp_generic_setup() {
fi
[ -n $mtu ] || json_get_var mtu mtu
[ -n $pppname ] || pppname=${proto:-ppp}-$config
+ [ -n $unnumbered ] {
+ local subnets
+ ( proto_add_host_dependency $config $unnumbered )
+ network_get_subnets subnets $unnumbered
+ localip=$(ppp_select_ipaddr $subnets)
+ [ -n $localip ] || {
+ proto_block_restart $config
+ return
+ }
+ }
local lcp_failure=${keepalive%%[, ]*}
local lcp_interval=${keepalive##*[, ]}
@@ -86,6 +123,7 @@ ppp_generic_setup() {
proto_run_command $config /usr/sbin/pppd \
nodetach ipparam $config \
ifname $pppname \
+ ${localip:+$localip:} \
${lcp_failure:+lcp-echo-interval $lcp_interval lcp-echo-failure
$lcp_failure $lcp_adaptive} \
${ipv6:++ipv6} \
nodefaultroute \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] strongswan CVE-2015-3991 CVE-2015-4171
Thanks for the hint, I updated the package-definitions. 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 2/3] 6to4: Remove sourcerouting parameter registration
It's fine, he's just cleaning up after me *ducks and hides*. ___ 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] ppp: Unnumbered support
Thanks, I already applied the other two.
On 10.06.2015 10:39, Hans Dedecker wrote:
+ppp_select_ipaddr()
+{
+ local interface=$1
+ local addrs=$(uci_get network.${interface}.ipaddr)
+ local netmask=$(uci_get network.${interface}.netmask)
Any particular reason you are reading from UCI here and do not use the
interface status parsing via e.g. network_get_subnets from
/lib/functions/network.sh? This would seem more clear to me and would
avoid the awkward parsing of netmasks as well. Additionally this would
make it work with non-static protos as well.
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] ppp: Unnumbered support
I just pushed http://git.openwrt.org/?p=project/netifd.git;a=commit;h=5cf30b59baa03db2448570c78e7e92873555d2ec (not yet bumped in trunk) which allows generic dependencies to interfaces by using an empty address, with that you can add a host dependency and once fulfilled use network_* to get the addresses. Please let me know if that works for you. Cheers, Steven On 10.06.2015 14:52, Steven Barth wrote: UCI is read as network_get_subnets only returns info for active interfaces; e.g. if the referred interface in the unnumbered parameter is down it's not possible to install the host dependency based on the IP address for the PPP interface. Did not (yet) find a way to circumvent this issue. Understood, I think the sane way around here would be to add a host_dependency on the interface itself (without a specific IP-address). Let me see if this can be added to netifd easily. 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,v2] dnsmasq: bump to dnsmasq2.73rc9
Indeed, you can have a look at http://patchwork.ozlabs.org/project/openwrt/list/ to see and download the patches extracted from the mails (also the old ones). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: bump to dnsmasq2.73rc9
Your patch is mangled and doesn't apply. On another note I hope we will see the final 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,v2] dnsmasq: bump to dnsmasq2.73rc9
Nope, mangled still. See MUA-SPECIFIC HINTS on https://git-scm.com/docs/git-format-patch to fix Thunderbird though tbh. using git-send-email is easier in most cases, see https://git-scm.com/docs/git-send-email especially EXAMPLE at the very end. 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] Add sch_fq and sch_pie to the kmod-sched package.
Applied, we have to cleanup kmod-sched at some point and throw out all the crap nobody uses anyway. 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
Thanks for the quick reply. On 03.06.2015 08:26, Linus Lüssing wrote: For IPv6 and a non-zero IPv4 source address it'll use the normal IGMP/MLD querier election mechanism, meaning the one with the lowest IP address will become the selected querier and the only one querying on the link. So especially for v6 - since the kernel doesn't do IGMPv3 / MLDv2 - this effectively downgrades all the bridge links to ASM then (at least with a 50% chance, i.e. when the kernel wins due to lower MAC-address), which is a bit meh. Now remaining question is, does the kernel detect if there is a userspace-querier running on the same machine and silence itself then? If not we probably need to address this as well somehow. 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
Steven, could you elaborate a little more on the scenario and explain why it is a must to shut up automatically when having a local user-space querier? If people are able to manually install and configure a complex multicast router, aren't they capable of manually disabling the bridge querier, too (there's even a netifd option for that)? I'm not thinking about complex router setups but instead about simple SSM capable proxies (i.e. mcproxy and the like). I think thats a valid point and don't see why v6 behaves rather awkwardly compared to v4 which simply goes silent. If i run a userspace querier the kernel should shut up otherwise the userspace querier might get utterly confused since its suddenly competing against itself in the election. I mean the kernel can still do the mc- uc translation but simply let userspace do the querying. Though i guess if all else fails we need to do this manually using /proc writes in the init script hmmm... ___ 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
Do you by chance remember what was the behavior of the Linux kernel's intenral querier was. I mean does it use the usual L3-address of the bridge as source? How does it behave in the presence of other queriers either on WiFi stas or other bridge ports? Thanks, 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: script: only call firewall, if installed
Is that okay with you as well https://dev.openwrt.org/changeset/45867 ? 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/resend] [odhcp6c] script: only call firewall, if installed
The patch is malformed and cannot be applied. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc1
Ok thanks for the suggestion. I added some ietf references to the homepage. Cheers, Steven Am 22. Mai 2015 16:29:12 MESZ, schrieb Michael Richardson m...@sandelman.ca: Steven Barth cy...@openwrt.org wrote: Steven Barth cy...@openwrt.org wrote: - Added support for 464XLAT (CLAT) Is this signaled in some way by DHCPv6? If so, I imagine that there is an RFC# which says how it works, could be listed here, so that google will find CC when people look for it... There seems to be no standardized RFC for this yet, as Bjorn pointed out. All I'm suggesting is that it say: - Added support for 464XLAT (CLAT) based upon RFC6877 (includes using heuristic to discover the PLAT side) if one supported the new DHCPv6 option, then one would say instead: - Added support for 464XLAT (CLAT) based upon RFC6877 (includes using heuristic to discover the PLAT side, and supporting DHCPv6 option in draft-cui-intarea-464xlat-prefix-dhcp-00) it's just google fodder so that IETF people can find the code, and OpenWRT people can find the specification :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc1
On 21.05.2015 20:32, Michael Richardson wrote: Steven Barth cy...@openwrt.org wrote: - Added support for 464XLAT (CLAT) Is this signaled in some way by DHCPv6? If so, I imagine that there is an RFC# which says how it works, could be listed here, so that google will find CC when people look for it... There seems to be no standardized RFC for this yet, as Bjorn pointed out. So what we do currently if 464xlat is installed is trying to resolve an record for ipv4-only.arpa (i.e. detect an existing DNS64) and if we get a valid response use the first 96-bits of the result as NAT64-prefix. Of course one can also manually configure 464xlat with a custom prefix. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Chaos Calmer 15.05-rc1
The OpenWrt developers are proud to announce the first release candidate of OpenWrt Chaos Calmer. ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M - CHAOS CALMER (15.05 RC1) - * 1 1/2 oz GinShake with a glassful * 1/4 oz Triple Sec of broken ice and pour * 3/4 oz Lime Juice unstrained into a goblet. * 1 1/2 oz Orange Juice * 1 tsp. Grenadine Syrup - - http://downloads.openwrt.org/chaos_calmer/15.05-rc1/ ** Highlights since Barrier Breaker ** * Linux kernel updated to version 3.18 * Improved Security Features - Rewritten package signing architecture based on ed25519 - Added support for jails - Added support for hardened builds * Improved Networking Support - Added or improved support for lots of 3G/4G modems (MBIM, QMI, NCM, ...) - Added support for 464XLAT (CLAT) - Improved support for self-managing networks (draft-ietf-homenet-hncp) - Netfilter performance enhancements (conntrack route cache) - Better multi-core support for the network stack - Improved support for MAP-E and MAP-T IPv4 transitioning technologies - Improved network auto-setup capable of detecting and bootstrapping IPv4-only, 6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT and combinations without explicit configuration - Added support for Smart Queue Management (SQM) QoS, AQM and Traffic Shaping - Improved support for DNSSEC * Platform and Driver Support - Added support for feeds of externally maintained targets - New mt7621 subtarget for Mediatek 11ac SoC - New mt76 mac80211 based wifi driver for MTK 11ac cores. - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices - brcm2708: support for Raspberry Pi 2 - brcm63xx: support for BCM6318 and BCM63268 family - brcm63xx: improved fallback sprom support with bcma support * Known Issues - libusb-1.0 is currently not installable (#19668). This is already fixed in svn. This can be manually fixed by applying the changes from r45702 by hand. - the targets feed is part of opkg.conf, and will produce warnings. It is save to remove from /etc/opkg.conf. And lots and lots of other advancements... As always a big thank you goes to all our active package maintainers, testers, supporters and documenters. Have fun! The OpenWrt developer team ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] generic/4.0: fix error during kernel patch application
Thanks, and sorry for the mess. I probably ran the compile-check on the wrong kernel-version. 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: bump to dnsmasq2.73rc8 Important.
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][v2] netifd: Support for configurable default packet steering behavior
Applied, thanks.
On 12.05.2015 13:11, Hans Dedecker wrote:
The default packet steering behavior can be configured via the parameter
default_ps in the global section; the default value is true to keep
backwards compatibility.
Device packet steering (rps/xps) config can still be used to override the
default behavior.
This allows you to disable packet steering for all devices without the need
to define a device config list which disables receive/transmit packet steering
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
config.c | 6 ++
device.c | 56 +---
device.h | 3 +++
3 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/config.c b/config.c
index 48c4fbf..5d3db9f 100644
--- a/config.c
+++ b/config.c
@@ -306,6 +306,12 @@ config_init_globals(void)
const char *ula_prefix = uci_lookup_option_string(
uci_ctx, globals, ula_prefix);
interface_ip_set_ula_prefix(ula_prefix);
+
+ const char *default_ps = uci_lookup_option_string(
+ uci_ctx, globals, default_ps);
+
+ if (default_ps)
+ device_set_default_ps(strcmp(default_ps, 1) ? false : true);
}
static void
diff --git a/device.c b/device.c
index 092c2d9..dd2823d 100644
--- a/device.c
+++ b/device.c
@@ -29,6 +29,7 @@
#include config.h
static struct avl_tree devices;
+static bool default_ps = true;
static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] = {
[DEV_ATTR_TYPE] = { .name = type, .type = BLOBMSG_TYPE_STRING },
@@ -244,15 +245,19 @@ device_init_settings(struct device *dev, struct blob_attr
**tb)
s-flags |= DEV_OPT_NEIGHREACHABLETIME;
}
- if ((cur = tb[DEV_ATTR_RPS]))
+ if ((cur = tb[DEV_ATTR_RPS])) {
s-rps = blobmsg_get_bool(cur);
+ s-flags |= DEV_OPT_RPS;
+ }
else
- s-rps = true;
+ s-rps = default_ps;
- if ((cur = tb[DEV_ATTR_XPS]))
+ if ((cur = tb[DEV_ATTR_XPS])) {
s-xps = blobmsg_get_bool(cur);
+ s-flags |= DEV_OPT_XPS;
+ }
else
- s-xps = true;
+ s-xps = default_ps;
device_set_disabled(dev, disabled);
}
@@ -370,8 +375,8 @@ int device_init(struct device *dev, const struct
device_type *type, const char *
system_if_clear_state(dev);
device_check_state(dev);
- dev-settings.rps = true;
- dev-settings.xps = true;
+ dev-settings.rps = default_ps;
+ dev-settings.xps = default_ps;
return 0;
}
@@ -723,6 +728,41 @@ device_reset_old(void)
}
}
+void
+device_set_default_ps(bool state)
+{
+ struct device *dev;
+
+ if (state == default_ps)
+ return;
+
+ default_ps = state;
+
+ avl_for_each_element(devices, dev, avl) {
+ struct device_settings *s = dev-settings;
+ unsigned int apply_mask = 0;
+
+ if (!(s-flags DEV_OPT_RPS)) {
+ s-rps = default_ps;
+ apply_mask |= DEV_OPT_RPS;
+ }
+
+ if (!(s-flags DEV_OPT_XPS)) {
+ s-xps = default_ps;
+ apply_mask |= DEV_OPT_XPS;
+ }
+
+ if (!apply_mask)
+ continue;
+
+ if (!(dev-external || (dev-present dev-active)) ||
+ dev-config_pending)
+ continue;
+
+ system_if_apply_settings(dev, s, apply_mask);
+ }
+}
+
struct device *
device_create(const char *name, const struct device_type *type,
struct blob_attr *config)
@@ -758,8 +798,10 @@ device_create(const char *name, const struct device_type
*type,
if (odev)
device_replace(dev, odev);
- if (!config_init dev-config_pending)
+ if (!config_init dev-config_pending) {
type-config_init(dev);
+ dev-config_pending = false;
+ }
return dev;
}
diff --git a/device.h b/device.h
index 753e1fa..3001f10 100644
--- a/device.h
+++ b/device.h
@@ -78,6 +78,8 @@ enum {
DEV_OPT_IGMPVERSION = (1 7),
DEV_OPT_MLDVERSION = (1 8),
DEV_OPT_NEIGHREACHABLETIME = (1 9),
+ DEV_OPT_RPS = (1 10),
+ DEV_OPT_XPS = (1 11),
};
/* events broadcasted to all users of a device */
@@ -206,6 +208,7 @@ device_apply_config(struct device *dev, const struct
device_type *type,
void device_reset_config(void);
void device_reset_old(void);
+void device_set_default_ps(bool state);
void device_init_virtual(struct device *dev, const struct device_type *type, const char *name);
int device_init(struct device *iface, const struct device_type *type, const
char *ifname);
___
Re: [OpenWrt-Devel] [PATCH] netifd: Support for configurable default packet steering
Fine with me in principle, howeverI find the name force_ps to be
misleading since the option does not override or enforce anything. Maybe
default_ps would be a more suitable name?
Cheers,
Steven
On 11.05.2015 18:30, Hans Dedecker wrote:
Default packet steering behavior can be configured via the parameter force_ps
in the global section; the default value is true to keep backwards
compatibility.
Device packet steering (rps/xps) config can still be used to override the
default behavior.
This allows you to disable packet steering for all devices without the need
to define a device config list which disables receive/transmit packet steering
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
config.c | 6 ++
device.c | 56 +---
device.h | 3 +++
3 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/config.c b/config.c
index 48c4fbf..77ebb45 100644
--- a/config.c
+++ b/config.c
@@ -306,6 +306,12 @@ config_init_globals(void)
const char *ula_prefix = uci_lookup_option_string(
uci_ctx, globals, ula_prefix);
interface_ip_set_ula_prefix(ula_prefix);
+
+ const char *force_ps = uci_lookup_option_string(
+ uci_ctx, globals, force_ps);
+
+ if (force_ps)
+ device_set_force_ps(strcmp(force_ps, 1) ? false : true);
}
static void
diff --git a/device.c b/device.c
index 092c2d9..afe917c 100644
--- a/device.c
+++ b/device.c
@@ -29,6 +29,7 @@
#include config.h
static struct avl_tree devices;
+static bool force_ps = true;
static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] = {
[DEV_ATTR_TYPE] = { .name = type, .type = BLOBMSG_TYPE_STRING },
@@ -244,15 +245,19 @@ device_init_settings(struct device *dev, struct blob_attr
**tb)
s-flags |= DEV_OPT_NEIGHREACHABLETIME;
}
- if ((cur = tb[DEV_ATTR_RPS]))
+ if ((cur = tb[DEV_ATTR_RPS])) {
s-rps = blobmsg_get_bool(cur);
+ s-flags |= DEV_OPT_RPS;
+ }
else
- s-rps = true;
+ s-rps = force_ps;
- if ((cur = tb[DEV_ATTR_XPS]))
+ if ((cur = tb[DEV_ATTR_XPS])) {
s-xps = blobmsg_get_bool(cur);
+ s-flags |= DEV_OPT_XPS;
+ }
else
- s-xps = true;
+ s-xps = force_ps;
device_set_disabled(dev, disabled);
}
@@ -370,8 +375,8 @@ int device_init(struct device *dev, const struct
device_type *type, const char *
system_if_clear_state(dev);
device_check_state(dev);
- dev-settings.rps = true;
- dev-settings.xps = true;
+ dev-settings.rps = force_ps;
+ dev-settings.xps = force_ps;
return 0;
}
@@ -723,6 +728,41 @@ device_reset_old(void)
}
}
+void
+device_set_force_ps(bool state)
+{
+ struct device *dev;
+
+ if (state == force_ps)
+ return;
+
+ force_ps = state;
+
+ avl_for_each_element(devices, dev, avl) {
+ struct device_settings *s = dev-settings;
+ unsigned int apply_mask = 0;
+
+ if (!(s-flags DEV_OPT_RPS)) {
+ s-rps = force_ps;
+ apply_mask |= DEV_OPT_RPS;
+ }
+
+ if (!(s-flags DEV_OPT_XPS)) {
+ s-xps = force_ps;
+ apply_mask |= DEV_OPT_XPS;
+ }
+
+ if (!apply_mask)
+ continue;
+
+ if (!(dev-external || (dev-present dev-active)) ||
+ dev-config_pending)
+ continue;
+
+ system_if_apply_settings(dev, s, apply_mask);
+ }
+}
+
struct device *
device_create(const char *name, const struct device_type *type,
struct blob_attr *config)
@@ -758,8 +798,10 @@ device_create(const char *name, const struct device_type
*type,
if (odev)
device_replace(dev, odev);
- if (!config_init dev-config_pending)
+ if (!config_init dev-config_pending) {
type-config_init(dev);
+ dev-config_pending = false;
+ }
return dev;
}
diff --git a/device.h b/device.h
index 753e1fa..d80142b 100644
--- a/device.h
+++ b/device.h
@@ -78,6 +78,8 @@ enum {
DEV_OPT_IGMPVERSION = (1 7),
DEV_OPT_MLDVERSION = (1 8),
DEV_OPT_NEIGHREACHABLETIME = (1 9),
+ DEV_OPT_RPS = (1 10),
+ DEV_OPT_XPS = (1 11),
};
/* events broadcasted to all users of a device */
@@ -206,6 +208,7 @@ device_apply_config(struct device *dev, const struct
device_type *type,
void device_reset_config(void);
void device_reset_old(void);
+void device_set_force_ps(bool state);
void device_init_virtual(struct device *dev, const struct device_type *type, const char *name);
int
Re: [OpenWrt-Devel] [PATCH] modules: package l2tp_ip6.ko in kmod-l2tp-ip6
On 02.05.2015 13:33, Daniel Golle wrote: r45593 includes l2tp_ip6 in the kmod-l2tp-ip package. This is not feasible for several reasons: - in a given setup one usually uses either l2tp_ip or l2tp_ip6, but never both I disagree here, if you e.g. use a hostname and resolve that before connecting this would dynamically resolve to either IPv6 or IPv4. - l2tp_ip doesn't depend on ipv6 True, I'm not sure if it makes sense to have IPv6 as an external module any longer since its been a while and its enabled by default anyway. I guess after the CC branch we might want to enable it in the default kernel config and remove the module packaging. This would also save some space in the end. - versioning of kmod-l2tp-ip doesn't indicate that it now does include support for L2TP-over-IPv6 Versioning is based on the kernel, so I don't think I get this argument. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] firewall: Allow MLD input on WAN
Hello Linus, thanks for the patch. I have two questions here. #1 Why should this be done for v6 but not for v4? #2 If the intention is to respond to MLD queries why should the firewall allow reception of report messages? 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] modules: package l2tp_ip6.ko in kmod-l2tp-ip6
Anyway, I get that argument, but it could still be solved by adding +IPV6:kmod-l2tp-ip6 as a dependency to kmod-l2tp-ip. If it's really about the packaging overhead, it would also be possible to only include l2tp_ip6.ko in FILES if IPV6 is set, thus getting rid of the kmod-ipv6 dependency on non-IPv6 systems. I guess that sounds like a good compromise. In the long-run, I dream about native L2TPv3 integration in netifd using netlink, just like GRE tunnels are supported in Yes, it's one of those: I would really love to implement that one day list, along with a 100 other things unfortunately :/ http://git.openwrt.org/?p=project/netifd.git;a=blob;f=system-linux.c That could then take care of resolving hostnames, adding host- routes and all that... What are you using to setup pseudo-wires in OpenWrt after https://github.com/openwrt/packages/commit/08ae49377644067d2ad3e004f7fc1644e128b6c4 ? ip-full for now, though I might one day get annoyed enough to write a smaller replacement but IIRC it uses generic netlink which is a bit more complicated than usual netlink. There are still many cases where people use ImageBuilder to have a firmware without IPv6, so they can use the space for other things. I don't like that approach either and only know about it because these systems then don't respond to IPv6 link-local multicast ping which is one of my most used tools in my personal maintainance toolbox... I guess those people would need to use the SDK / buildroot then. I will try to bring it up with the other core-hackers at some point. And won't we one day package IPv4 as an optional module instead then? I don't think that the Linux kernel supports that (yet?). Right, the fact that versioning is based on the kernel is exactly the problem here. Imagine that I'm using a 3.14-based locally maintained OpenWrt branch and provide updates via a feed. Now some user asked me for l2tp_ip6 support and I'd like to tell her, yes, it's available now. Go ahead an install kmod- Now the user already got kmod-l2tp-ip installed, so opkg won't re-install the package as it believes it's up-to-date. I guess that should explain it. Okay, got it though to be fair snapshot builds are in practice not really upgradable at the moment anyway due to the often times false-positive kernel version mismatch. 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: bump to dnsmasq2.73rc7
Sorry, beat you again by 20 minutes :P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: bump to dnsmasq2.73rc7
Looks good and applies. Usually the Signed-off-by is at the end of the commit message 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] iproute2: update to v4.0.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] DHCPv6 flash renumbering patches with HE tunnel breaks
After thinking it through a bit more, I changed the default behavior to the following: The preferred lifetime is now as given by the ISP, however the DHCPv6 server will only hand out the address with the highest preferred lifetime (= the ULA unless disabled). Thus flash renumbering should still work (since only the ULA-address cannot be changed immediately). Is that okay with you or do you see any other issues? Cheers, Steven On 26.03.2015 20:38, Arjen de Korte wrote: Citeren Steven Barth cy...@openwrt.org: This breaks clients that need fixed IPs (in my case, mostly webmail clients). I wonder why they are so sensitive to source-address changes since their old address is still valid and not deprecated so there is no need to switch. Webmail clients usually don't keep a connection open to the server, hence every connection is a new one. The webmail server only sees the source IP, so even if the DHCPv6 address is still valid for the client, a re-login is needed because the source IP changes. I would gladly send the DHCPv6 address with 0 preferred lifetime but Apple's DHCPv6 client has issues and discard addresses therefore the 1. I could create a patch for this, but for now I consider this a regression, rather than a feature that needs to be configurable. I fail to understand the reasons why this change, which deliberately breaks the outgoing addresses (even if only momentarily) was introduced. The reason for this change is that no host seems to support DHCPv6 reconfiguration so we cannot update clients whenever we see fit (e.g. ISP goes down / is switched / designates a different PD). Which means that in absence of that in worst case client connectivity is lost for T1 seconds. I don't see how this fixes things then. When ra_management is '2' you'd still run into the exact same problem (just without the fallback to SLAAC). In contrast, if the ip6prefix is configured statically (as in my case), there is no chance this will ever happen, since changes will never happen unexpectedly. I think this would be much better fixed by making the client renew its lease more frequently (by lowering the valid and preferred lifetimes). The present fix will also not work for anthing else than a /64. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Since I avoid ULA like the plague, this probably won't be a problem for me and global IPv6 addresses will be served. But I'm not convinced that favoring a ULA prefix (if available) over an ip6prefix is best at all times. Nothing is favored, DHCPv6 just hands out ULAs only (if one is there). Client can still decide what it uses to connect to anywhere, besides it can't use an ULA to connect to the internet anyway. Thus flash renumbering should still work (since only the ULA-address cannot be changed immediately). Is that okay with you or do you see any other issues? Well, one thing that still worries me, is that the behavior of the DHCPv6 server is different depending on the state of the O flag. From a DHCPv6 client perspective, it shouldn't. When both M- and O-flag are set, it is up to the client to decide if it wants to use DHCPv6 or SLAAC. You've made it clear that there may be reasons not to use an adress provided by DHCPv6 and use SLAAC instead. But this should not be the only (or default) way of operation. There may be reasons other than broken IPv6 uplinks why network administrators choose to set both M- and O-flags. I think the other reasons are far more common (the lack of DHCPv6 support in Android is just one of them). Even with the changes pushed out today, odhcpd makes the assumption that the ip6prefix can't be relied upon if a ULA prefix is provided and I think that is just incorrect. First of all the O-Flag is ignored whenever the M-Flag is set. Plus there cannot be clients that only do DHCPv6 but not RAs, since DHCPv6 does not transmit any kind of routes thus a client cannot ignore RAs. There are no assumption of unreliability of a prefix, ULAs aren't used for internet communication since they are not routed. Sorry, I don't see your point. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
The problem is that you try to be smart by abusing the ability to set the address preferred lifetime lower than T1. I don't dispute that it is allowed by the RFC, but it is definitely not recommended. There is no formal requirement (not even a SHOULD) that says otherwise. The recommendation made is usually based on the basis that DHCPv6 is your only source of addresses which it isn't for us. Based on this, it should not come as an surprise that a number of clients start behaving erratically if you set T1 much higher than the preferred lifetime. Don't do that. It causes problems. You can of course continue to argue that not honouring T1 is a bug, but that will not fix any of the failing clients. Now we know that they actually don't. The clients behave well, that seemed to be a misunderstanding. The OP just tried with a version of our server which had a buggy T1 calculation. I have a real hard time understanding what makes a DHCPv6 IA_NA address any different from a RA based address wrt lifetimes. If you choose to provide both RA and DHCPv6 service to the lan clients using the same assigned prefix, then the lifetimes should be kept the same as well. Choosing between DHCPv6 and SLAAC is really up to the clients in this case. If you want to prefer one or the other from the server side, then I don't see any reason to provide both. The big difference is that as a router I can send RAs whenever I want and clients will react immediately. Most clients however do not support the same when doing DHCP and only do dumb polling based on T1/T2. So I have to be smart in some way to workaround. I would gladly get rid of DHCPv6 after all for clients but there is no good way to collect hostnames otherwise. And wrt the fear of sudden renumbering: The upstrem source, where you get these addresses assigned, will include lifetimes. Why don't you reuse those (after some basic sanitation)? If the problem is that the upstream lies to you, then I suggest fixing that instead. We do propagate them as-is through RAs. However imagine manual or automatic failover to a different ISP / connection or simply an ISP doing 6rd where your IPv6 prefix is mapped from your IPv4-address and th connection flaps and you get a different v4-address or a VPN-connection being brought up or down. In all these scenarios there needs to be a way to tell clients to stop using an address for global traffic near instantaneously otherwise they might lose connectivity. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
On 27.03.2015 10:41, Kevin Darbyshire-Bryant wrote: On 26/03/2015 23:51, Steven Barth wrote: Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support downstream delegation and its DHCPv6 features aren't well integrated if you have a dynamic prefix e.g. delegated from your ISP. I've been messing with the 'constructor' option for quite a while which is supposed to handle dynamic prefix allocation/deprecation, admittedly with my HE tunnel things aren't very (at all!) dynamic, but dnsmasq does pick up new publicly routable prefixes and start RA DHCPv6 on them automagically for me. From my /etc/dnsmasq.conf dhcp-range=lan,::100, ::F::, constructor:br-lan, ra-names, 64, 12h enable-ra Sure that works, but you can't e.g. number downstream routers with this only clients. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Hello Arjen, most likely, your DHCPv6 client implementation is faulty and you should probably file a bug for more than one reason. If the DHCPv6 server sends values for T1 and / or T2 which are valid the client must honor them and not try to be smart about lifetimes of addresses. Besides you also get addresses with higher values for preferred lifetime using RAs so you always have usable IPv6 addresses, so if your network-manager / OS behaves sanely you shouldn't have any issues. A work-around for this is setting: option ra_management 0 in the lan-section of /etc/config/dhcp which will cause most clients to not use DHCPv6 and rely on RAs only. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
This breaks clients that need fixed IPs (in my case, mostly webmail clients). I wonder why they are so sensitive to source-address changes since their old address is still valid and not deprecated so there is no need to switch. I would gladly send the DHCPv6 address with 0 preferred lifetime but Apple's DHCPv6 client has issues and discard addresses therefore the 1. I could create a patch for this, but for now I consider this a regression, rather than a feature that needs to be configurable. I fail to understand the reasons why this change, which deliberately breaks the outgoing addresses (even if only momentarily) was introduced. The reason for this change is that no host seems to support DHCPv6 reconfiguration so we cannot update clients whenever we see fit (e.g. ISP goes down / is switched / designates a different PD). Which means that in absence of that in worst case client connectivity is lost for T1 seconds. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Radvd isn't part of OpenWrt for a while. dnsmasq doesn't support downstream delegation and its DHCPv6 features aren't well integrated if you have a dynamic prefix e.g. delegated from your ISP. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
In that case, I have a lot of bug reports to file, because none of the DHCPv6 clients I tried were happy with preferred lifetimes of 1 second on their leases (which includes Windows 7, 8.1 and openSUSE 13.2). Sorry, I cannot confirm this. I just tried it with both Windows 8.1 and Debian testing (w/ network-manager) both didn't react strangely or tried to renew the lease every second. Connectivity was okay. Besides you also get addresses with higher values for preferred lifetime using RAs so you always have usable IPv6 addresses, so if your network-manager / OS behaves sanely you shouldn't have any issues. They don't have an issue with IPv6 connectivity, its the source address that is used *I* have a problem with. Unless you disable RAs there is no way to tell the client which source address to pick anyway. If some OS use the DHCPv6 addresses by default then thats by chance. A work-around for this is setting: option ra_management 0 in the lan-section of /etc/config/dhcp which will cause most clients to not use DHCPv6 and rely on RAs only. This is not an option, as the whole purpose of using DHCPv6 for address configuration is to give clients a fixed IPv6 address. This has worked correctly since Barrier Breaker was released, I see no reason why it no longer should. That still works. The client will just not use the address for outgoing traffic. I'm fine with making this configurable (current behavior as default) though and would welcome a patch for this. I could put it on my todo but don't really know when I have the time to deal with this. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question regarding UCI with IPv4 and IPv6 on lan-bridge
Try config interface 'lan' option type 'bridge' option ifname 'eth0.1 bat0' option proto 'dhcp' config interface lan6 option ifname @lan option proto dhcpv6 # option reqprefix no (uncomment if you don't need an IPv6 delegated prefix) Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DS-Lite interface is not coming up.
config interface 'wan6' option proto 'static' option ifname 'eth1' option ip6addr '2001::50' config interface 'lq' option proto 'dslite' option ip6addr '2001::100' option peeraddr '2001::200' option tunlink 'wan6' In your dslite section you define your local endpoint address to be 2001::100 however in your wan6 section you define your local IPv6 address to be 2001::50. This seems wrong. You should either set both to the same value or simply omit option ip6addr from the dslite section so it is autodetected. Also (as noted in the last mail): if you run into further issues please post the output of the command: ubus call network.interface dump so we get to see status messages from netifd. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DS-Lite interface is not coming up.
Please post: your complete /etc/config/network the output of ubus call network.interface dump so we can see what's going on on your system. Your problem description is not really exhaustive. Also note that dslite doesn't support ipaddr or netmask parameters since RFC6333 specifies fixed IPv4 addresses so these parameters do nothing. 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/2] gccgo/libgo toolchain support for OpenWrt
Hello Jeff, It's a bit of a shame it doesn't work with the current default uclibc, however have you checked if it works with musl out of the box? That being the other more embedded-friendly solution here. 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] firewall3: fix null pointer access when no target is present
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] iproute2: bump version from v3.18.0 to v3.19.0
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 3/3] netifd: Set interface device config when device has old settings
All 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 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
Re: [OpenWrt-Devel] netifd + split dns servers
Our dnsmasq init script registers /tmp/dnsmasq.d as an additional configuration dir, so you can place files there and restart it. However I'm not sure as to how much we want netifd to do dnsmasq-specific stuff or how we would do it. Of course the bad thing here again is that dnsmasq doesn't support soft-reloading and every time you restart it you lose your dns cache etc. etc. 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] iproute2: bump version to v3.18.0, add package for bridge program
Thanks, unfortunately this doesn't compile for me:
ccache_cc -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wold-style-definition -Wformat=2 -O2 -Os -pipe
-mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves
-fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -mips16
-minterlink-mips16 -DHAVE_SETNS -ffunction-sections -fdata-sections
-I../include
-I/home/steven/workspace/openwrt/staging_dir/target-mips_34kc_musl-1.1.5/usr/include/libnl-tiny
-I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\/usr/lib\ -DNO_SHARED_LIBS
-DCONFDIR=\/etc/iproute2\ -D_GNU_SOURCE -DIPROUTE2_TINY -c -o
iplink_bridge_slave.o iplink_bridge_slave.c
In file included from ../include/linux/if_bridge.h:18:0,
from iplink_bridge_slave.c:16:
../include/linux/in6.h:40:0: warning: s6_addr redefined
#define s6_addr in6_u.u6_addr8
^
In file included from iplink_bridge_slave.c:14:0:
/home/steven/workspace/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.9-linaro_musl-1.1.5/include/netinet/in.h:32:0:
note: this is the location of the previous definition
#define s6_addr __in6_union.__s6_addr
^
In file included from ../include/linux/if_bridge.h:18:0,
from iplink_bridge_slave.c:16:
../include/linux/in6.h:42:0: warning: s6_addr16 redefined
#define s6_addr16 in6_u.u6_addr16
^
In file included from iplink_bridge_slave.c:14:0:
/home/steven/workspace/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.9-linaro_musl-1.1.5/include/netinet/in.h:33:0:
note: this is the location of the previous definition
#define s6_addr16 __in6_union.__s6_addr16
^
In file included from ../include/linux/if_bridge.h:18:0,
from iplink_bridge_slave.c:16:
../include/linux/in6.h:43:0: warning: s6_addr32 redefined
#define s6_addr32 in6_u.u6_addr32
^
In file included from iplink_bridge_slave.c:14:0:
/home/steven/workspace/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.9-linaro_musl-1.1.5/include/netinet/in.h:34:0:
note: this is the location of the previous definition
#define s6_addr32 __in6_union.__s6_addr32
^
In file included from ../include/linux/if_bridge.h:18:0,
from iplink_bridge_slave.c:16:
../include/linux/in6.h:169:0: warning: IPV6_ADD_MEMBERSHIP redefined
#define IPV6_ADD_MEMBERSHIP 20
^
In file included from iplink_bridge_slave.c:14:0:
/home/steven/workspace/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.9-linaro_musl-1.1.5/include/netinet/in.h:369:0:
note: this is the location of the previous definition
#define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
^
In file included from ../include/linux/if_bridge.h:18:0,
from iplink_bridge_slave.c:16:
../include/linux/in6.h:170:0: warning: IPV6_DROP_MEMBERSHIP redefined
#define IPV6_DROP_MEMBERSHIP 21
^
In file included from iplink_bridge_slave.c:14:0:
/home/steven/workspace/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.9-linaro_musl-1.1.5/include/netinet/in.h:370:0:
note: this is the location of the previous definition
#define IPV6_DROP_MEMBERSHIPIPV6_LEAVE_GROUP
^
In file included from ../include/linux/if_bridge.h:18:0,
from iplink_bridge_slave.c:16:
../include/linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
struct in6_addr {
^
In file included from iplink_bridge_slave.c:14:0:
/home/steven/workspace/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.9-linaro_musl-1.1.5/include/netinet/in.h:24:8:
note: originally defined here
struct in6_addr
^
In file included from ../include/linux/if_bridge.h:18:0,
from iplink_bridge_slave.c:16:
../include/linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
struct sockaddr_in6 {
^
In file included from iplink_bridge_slave.c:14:0:
/home/steven/workspace/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.9-linaro_musl-1.1.5/include/netinet/in.h:36:8:
note: originally defined here
struct sockaddr_in6
^
In file included from ../include/linux/if_bridge.h:18:0,
from iplink_bridge_slave.c:16:
../include/linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
struct ipv6_mreq {
^
In file included from iplink_bridge_slave.c:14:0:
/home/steven/workspace/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.9-linaro_musl-1.1.5/include/netinet/in.h:45:8:
note: originally defined here
struct ipv6_mreq
^
builtin: recipe for target 'iplink_bridge_slave.o' failed
make[4]: *** [iplink_bridge_slave.o] Error 1
make[4]: Leaving directory
'/home/steven/workspace/openwrt/build_dir/target-mips_34kc_musl-1.1.5/iproute2-tiny/iproute2-3.18.0/ip'
Makefile:45: recipe for target 'all' failed
make[3]: *** [all] Error 2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] util-linux: fix packaging issues
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] iproute2: bump version to v3.18.0, add package for bridge program
On 05.01.2015 11:28, Russell Senior wrote: Steven == Steven Barth cy...@openwrt.org writes: Steven Thanks, unfortunately this doesn't compile for me: Can you email me your .config? I'll confess I only test-built it with uClibc. Thanks. That is usually sufficient, though we are thinking of evaluating musl as a new default libc at some point so we want to keep at least the core packages compiling with it at this point. I'm building with musl as libc and GCC 4.9 linaro as compiler (latter should be standard already) all the rest is defaults. I can send you the .config if you really want to but its cluttered with all sorts of unrelated stuff. This issue mainly looks like wrong order of inclusions or duplicate inclusion of certain headers. ___ 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] 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] [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] 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] 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
