[LEDE-DEV] missing debugging stuff for 17.01.0 release binaries
Hi! I just realized that debugging symbols have not been published along with the (stripped) release binaries for 17.01.0. This is bad because this is needed to understand e.g. the call trace dumped along with a kernel oops. OpenWrt 15.05.1 got that while LEDE 17.01.0 doesn't :( http://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/kernel-debug.tar.bz2 Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [AD] support me hacking on OpenWrt/LEDE
Hi everyone, most of you might know me for hacking on embedded stuff while having the common good in mind. Because I'm practically always out of money, I decided to setup a patreon account which can help me to gather at least the $$$ needed to pay for obligatory health insurance and such things. It'd be great if you spread the word and also give me feedback (off-list!) so I can improve my patreon page. https://www.patreon.com/dangowrt Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] missing debugging stuff for 17.01.0 release binaries
Hi! On Sun, Mar 19, 2017 at 12:46:37PM +0100, Daniel Golle wrote: > Hi! > > I just realized that debugging symbols have not been published along > with the (stripped) release binaries for 17.01.0. > This is bad because this is needed to understand e.g. the call trace > dumped along with a kernel oops. > OpenWrt 15.05.1 got that while LEDE 17.01.0 doesn't :( > > http://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/kernel-debug.tar.bz2 Anyone? The fix should be as simple as: diff --git a/phase1/config.seed.example b/phase1/config.seed.example index 06914d4..f242c17 100644 --- a/phase1/config.seed.example +++ b/phase1/config.seed.example @@ -2,3 +2,4 @@ CONFIG_BUILDBOT=y CONFIG_DEVEL=y CONFIG_CCACHE=y CONFIG_KERNEL_KALLSYMS=y +CONFIG_COLLECT_KERNEL_DEBUG=y Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
Hi Pau, On Tue, Mar 28, 2017 at 09:28:22PM +0200, Pau wrote: > Hi. > > I am using the SDK and IB from LEDE 17.01.0 release (mips_24kc). I've > been using it successfully the last days until now. I did not change > anything but I get the error: > > * opkg_install_pkg: Package luci-lib-nixio sha256sum mismatch. Either > the opkg or the package index are corrupt. Try 'opkg update'. > > Then I went to downloads.lede-project.org [1] and I see that there are > new compiled packages with date "Tue Mar 28 18:35:15 2017". > Luci-lib-nixio is one of them [2] (which now is published on the > repository with a new version). Packages from the feeds and even base-packages (think: openssl) can change after a release, just like for other distributions. The error message you see more looks like being caused by inconsistent Package index not matching the actual binaries. Maybe regenerating the index can fix that...? > > In the other hand the feeds.conf.default file included in the release > SDK points to the specific commit > a100738163585ae1edc24d832ca9bef1f34beef0 from Sat Jan 28 01:38:06 2017. > The SDK published then is not consistent with the current package binary > repositories. The SDK doesn't need to be consistent with all packages, but the fixed commit (instead of a branch) is indeed misleading (and most likely got rather political reasons, like not poluting a repo called github.com/openwrt/packages with a branch called for-lede-17.01...) > > So my question here is: what's the point for publishing a Release if the > packages included are changing? Is this the expected behavior? Definitely not the expected behaviour, but packages may and should change, eg. for bug or security fixes. Cheers Daniel > > Thanks. > > [1] > https://downloads.lede-project.org/releases/17.01.0/packages/mipsel_24kc/ > [2] > https://downloads.lede-project.org/releases/17.01.0/packages/mips_24kc/luci/luci-lib-nixio_git-17.073.42825-b47a21f-1_mips_24kc.ipk > > -- > ./p4u > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
On Tue, Mar 28, 2017 at 10:55:09PM +0200, Pau wrote: > Hi Daniel, thanks for your reply. Find my comments in-line. > > On 28/03/17 22:37, Daniel Golle wrote: > > Hi Pau, > > > > On Tue, Mar 28, 2017 at 09:28:22PM +0200, Pau wrote: > >> Hi. > >> > >> I am using the SDK and IB from LEDE 17.01.0 release (mips_24kc). I've > >> been using it successfully the last days until now. I did not change > >> anything but I get the error: > >> > >> * opkg_install_pkg: Package luci-lib-nixio sha256sum mismatch. Either > >> the opkg or the package index are corrupt. Try 'opkg update'. > >> > >> Then I went to downloads.lede-project.org [1] and I see that there are > >> new compiled packages with date "Tue Mar 28 18:35:15 2017". > >> Luci-lib-nixio is one of them [2] (which now is published on the > >> repository with a new version). > > > > Packages from the feeds and even base-packages (think: openssl) can > > change after a release, just like for other distributions. > > The error message you see more looks like being caused by inconsistent > > Package index not matching the actual binaries. Maybe regenerating > > the index can fix that...? > > I know I can manually fix it. But let me explain my corner case: > > The current SDK is compiling luci-lib-nixio which I want to include to > the firmware generated by the ImageBuilder (I want to include my local > version, not the repository one). Ok, now I understand better. So the package index of the binary feed is consistent. > > The source of this package comes from the SDK's feeds.conf.default which > points to commit "a100738163585ae1edc24d832ca9bef1f34beef0". > > As the current LEDE official repository for 17.01.0 has been updated the > luci-lib-nixio package has a newer version. In consequence the > ImageBuilder selects it instead of my local compiled package. I get that problem, and it can be solved easily by removing the git commit hash from feeds.conf in the SDK and rather use the current snapshot instead. I agree that the lack of a lede-17.01 release branch on the package feeds may cause weird and problematic situations, especially in the future once LEDE HEAD has diverged more from 17.01.x released versions. > > So it is an unexpected behavior, and it makes impossible for us to be > sure that our LibreMesh SDK will work, not even when sticking to a LEDE > release. I fail to see the drama, why would that truely prevent you from doing anything? What is the behaviour you'd expect? > > In this case luci.lib-nixio is not a critical package and we can use the > vanilla one, but the same might happen with any other package that we > are compiling with different options and we expect the IB to use it > instead of the online one. Ok, all this is expected behaviour and shouldn't prevent anyone from building their packages using the SDK and then including their binaries in the ImageBuilder. Simply speaking, if you modify (ie. fork) a package you should either rename it or pull-request your changes upstream. > > >> > >> In the other hand the feeds.conf.default file included in the release > >> SDK points to the specific commit > >> a100738163585ae1edc24d832ca9bef1f34beef0 from Sat Jan 28 01:38:06 2017. > >> The SDK published then is not consistent with the current package binary > >> repositories. > > > > The SDK doesn't need to be consistent with all packages, but the fixed > > commit (instead of a branch) is indeed misleading (and most likely got > > rather political reasons, like not poluting a repo called > > github.com/openwrt/packages with a branch called for-lede-17.01...) > > > >> > >> So my question here is: what's the point for publishing a Release if the > >> packages included are changing? Is this the expected behavior? > > > > Definitely not the expected behaviour, but packages may and should > > change, eg. for bug or security fixes. > > IMHO and as far I understand the concept of Release, if there are fixes > a new revision must be published instead of modifying the current one > (i.e 17.01.1). Once a release is published it is expected to be always > the same. Why is that? And when has it ever been like that? Binary packages have also been updated for past OpenWrt releases, especially but not exclusively to fix security issues. (e.g. HeartBleed was fixed in binary packages all the way back to 12.09 afaik) > > > > > Cheers > > > > > > Daniel > > > >> > >> Thanks. > >> > >> [1] > >> https://down
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
On Tue, Mar 28, 2017 at 11:22:42PM +, Alberto Bursi wrote: > On 03/29/2017 12:19 AM, Gui Iribarren via Lede-dev wrote: > > all we want to do is create a firmware based on a specific LEDE release, > > and not fear that if we want to rebuild the exact same firmware in two > > months (or days!), we will get a different (broken) result > > This is an issue of SDK not following properly the sources (because of > reasons detailed by others already), imho it makes more sense to fix > that than freeze everything. ACK. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
Hi James, On Tue, Mar 28, 2017 at 04:58:54PM -0600, James Feeney wrote: > I am motivated to rant again on this topic. Repeating what I said last > November, before the new release process was finalized, in response to > David Lang: > > --- > > >> There is an interesting question of how to refer to what state of each feed > >> you use for a release. Currently OpenWRT doesn't even try to do this. The > >> feed version you get is the feed version that exists at the time you last > >> pulled from the feeds. > > > Uhm - I'm a bit taken aback by that. Well, this was actually fixed by having a specific snapshot of all feeds referenced in the SDK. Which is exactly the cause of all the confusion now... > > >> This hasn't been a big problem in practice, but it does mean that you don't > >> really have a repeatable build. > > > I would have thought that that was a "show stopper". It certainly does not > > inspire confidence. > > > I say this is a "problem" and should be a high priority issue. > > >> See my other e-mail about [git] submodules for a > >> discussion on this. > > > Yes, I looked at that. It would seem to address and solve a number of > > issues. > > There would be no need for a separate "manifest", and, most importantly, > > there > > would be a git "snapshot" of the *entire* project state. If I understand, > > that also means there would be a unique git tag that would label that state, > > and could be associated with any kind of specific nickname, version, and > > build > > number. It would mean that every build was repeatable. Every build of what exactly? Do you realise that *none* of the packages from any of the feeds are actually included in the released target binaries? Strictly speaking the package feeds are simply not a part of the project making the release. > > >>> It would be possible, I suppose, that each of these linked repositories > >>> could be *required* to use the *same* versioned naming scheme. > >> > >> can't be done, these other repositories are not under our control. The most > >> we can do is reference exactly which release we use.. > > --- > > So then, nothing was done to address this issue, when developing the new > release > process, where, instead, at worst, LEDE could simply "snapshot" a "feed", and > keep that copy on github, and then *under LEDE's control*. And git submodules > are still an available solution. > > I don't know that there is any polite way to express how ridiculous I find > this > situation, of non-repeatable builds, let alone the failure to bump the version > number of the release. I might call it "unprofessional", though I'm tempted > to > be otherwise demeaning. > > Let me say again, I think that this is an important issue that the LEDE > project > needs to address and remedy. I believe that the ultimate credibility and > reputation of the LEDE project is at stake. >From my understanding the original issue which was brought up by Pau is the result of a lack of documentation how to properly use the SDK and ImageBuilder. It doesn't have much too do with that past trauma of yours, though obviously resembled it closely enough to trigger some painful memories and write an email using lots of quotation marks and emphasis to make us *see* "something". Release builds (ie. building the buildroot from source) are entirely reproducible, thanks to the long and tideous efforts of the reproducible builds team, eliminating timestamps and other obstacles. I fail to see the issue which would even remotely justifies the degree of inflated drama. I fail to see how this is unprofessional or even inconsistent or anything like that. Maybe there have been misunderstandings caused by wrong expectations caused by a lack of documentation. I also fail to see how git submodules could make things any better. Imho using git submodules, especially for meta-stuff is a very bad practise, many distributions decided against that and for good reason, see e.g. some input from puppetlinux [1]. Money quote: "All of this smells of an antipattern. Git submodules sound great initially, but the farther down this road that you go, the more work you're going to generate trying to work around the limitations of git submodules." Maybe subtrees can be better. Having an explicite manifest, like feeds.conf in the SDK, does the trick. I agree that it's a bit hidden and that practise has not been very well documented (yet). Anyway. Back to the real issue here: Imho you shouldn't use the SDK to build core packages or even any package provided in a binary feed belonging to that release and then use that version (which you have just built locally) in the ImageBuilder. Yes, you may need to build it in order to build your local packages to satisfy build dependencies. But when it comes to use the ImageBuilder, always use the upstream binary feeds and only include your hand full of local packages in a seperate feed. If you really need to modify packages already included in an up
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
On Wed, Mar 29, 2017 at 05:28:07AM +0200, Pau wrote: > On 29/03/17 02:45, Daniel Golle wrote: > > On Tue, Mar 28, 2017 at 10:55:09PM +0200, Pau wrote: > >> Hi Daniel, thanks for your reply. Find my comments in-line. > >> > >> On 28/03/17 22:37, Daniel Golle wrote: > >>> Hi Pau, > >>> > >>> On Tue, Mar 28, 2017 at 09:28:22PM +0200, Pau wrote: > >>>> Hi. > >>>> > >>>> I am using the SDK and IB from LEDE 17.01.0 release (mips_24kc). I've > >>>> been using it successfully the last days until now. I did not change > >>>> anything but I get the error: > >>>> > >>>> * opkg_install_pkg: Package luci-lib-nixio sha256sum mismatch. Either > >>>> the opkg or the package index are corrupt. Try 'opkg update'. > >>>> > >>>> Then I went to downloads.lede-project.org [1] and I see that there are > >>>> new compiled packages with date "Tue Mar 28 18:35:15 2017". > >>>> Luci-lib-nixio is one of them [2] (which now is published on the > >>>> repository with a new version). > >>> > >>> Packages from the feeds and even base-packages (think: openssl) can > >>> change after a release, just like for other distributions. > >>> The error message you see more looks like being caused by inconsistent > >>> Package index not matching the actual binaries. Maybe regenerating > >>> the index can fix that...? > >> > >> I know I can manually fix it. But let me explain my corner case: > >> > >> The current SDK is compiling luci-lib-nixio which I want to include to > >> the firmware generated by the ImageBuilder (I want to include my local > >> version, not the repository one). > > > > Ok, now I understand better. So the package index of the binary feed > > is consistent. > > > >> > >> The source of this package comes from the SDK's feeds.conf.default which > >> points to commit "a100738163585ae1edc24d832ca9bef1f34beef0". > >> > >> As the current LEDE official repository for 17.01.0 has been updated the > >> luci-lib-nixio package has a newer version. In consequence the > >> ImageBuilder selects it instead of my local compiled package. > > > > I get that problem, and it can be solved easily by removing the git > > commit hash from feeds.conf in the SDK and rather use the current > > snapshot instead. > > I agree that the lack of a lede-17.01 release branch on the package > > feeds may cause weird and problematic situations, especially in the > > future once LEDE HEAD has diverged more from 17.01.x released versions. > > Sure, it is what I did. But I liked the idea of sticking and trusting > the official feeds.conf.default included in the SDK. I just realize that a lede-17.01 branch has been created for openwrt/packages.git, openwrt/luci.git, openwrt/telephony.git and openwrt-routing/packhages.git, just openwrt-management/packages.git seems to lack a lede-17.01 release branch. > > >> > >> So it is an unexpected behavior, and it makes impossible for us to be > >> sure that our LibreMesh SDK will work, not even when sticking to a LEDE > >> release. > > > > I fail to see the drama, why would that truely prevent you from doing > > anything? What is the behaviour you'd expect? > > The drama is that I've been following OpenWRT (and now LEDE) for so many > years and stability is not (¿yet?) a word that I would use to describe it. > > As you already know in the past we were freezing the OpenWRT buildroot > so we were 100% sure that we were producing always the same release > firmware (which was kind of deeply tested by us). Now (in 2017) I'd like > to trust on LEDE releases and be sure that no new bugs are introduced. > But two months after (not even) the public announcement of 17.01.0 I see > new versions entering into the release official packages. We cannot be > testing all this stuff all the time... it's a long process. As with every release, those updates (to the respective lede-17.01 branch) should be bug- and security-fixes only and should never break compatibility of depending packages. If that's still too much movement, you can bake your own package builds and use those in the ImageBuilder by editing repositories.conf instead of using the upstream ones. > > So it is not an actual drama but I am a bit afraid. I'm really happy > with the evolution of OpenWRT and now LEDE (mainly since AA) but still I > need to see with my own eyes that a r
Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support
Hi Paul, On Fri, Mar 31, 2017 at 10:38:39PM +0200, Paul Oranje wrote: > This POE access point suited for outside usage needs an external antenna. > According FCC documentation the ENH200EXT (needs external antenna) and the > ENH200 (with internal antenna) are electrically equal to the Allnet ALL0258N. > > The stock image does not allow install of a LEDE factory image, but an > initramfs image (lede-ar71xx-generic-enh200ext-initramfs-uImage.bin) can be > loaded via u-boot recovery procedure (long press reset at power-on until all > LEDS burn). The u-boot recovery procedure boots an image named > vmlinux-art-ramdisk from 192.168.1.101. > Once booted the sysupgrade image can be flashed from the booted iniramfs LEDE. > > Only abnormality is that for some unknown reason the txpower cannot be set > higher than 16 dBm whereas the Engenius stock firmware allows a maximum of 27 > dBm. Yes, difference is software only. ALL0258N came with OpenWrt pre-flashed, hence we contributed the needed bits upstream. Also went through ODM QA with OpenWrt, so EEPROM might not be identical for ENH200 and ALL0258N (the latter was intended to run OpenWrt with ath9k as well as Atheros SDK's proprietary driver). > > Signed-off-by: Paul Oranje > --- > package/boot/uboot-envtools/files/ar71xx | 1 + > target/linux/ar71xx/base-files/etc/board.d/01_leds | 3 +- > .../linux/ar71xx/base-files/etc/board.d/02_network | 1 + > target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + > .../ar71xx/base-files/lib/upgrade/platform.sh | 6 +- > target/linux/ar71xx/config-4.4 | 1 + > .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 9 +++ > target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 + > .../ar71xx/files/arch/mips/ath79/mach-enh200ext.c | 89 ++ ^^^ Please merge this with mach-all0258n.c so we don't have tons of redundant code. Make them share most of the setup code, maybe parametrisize the LEDs so you can pass a string and then just have two MIPS_MACHINE lines at the bottom of the file. Take a look at various mach-tl-*.c files which usually are for several similar models each. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [AD] support me hacking on OpenWrt/LEDE
Hi Benni, On Mon, Apr 03, 2017 at 11:30:45AM +0200, lede-proj...@bepo.de wrote: > Hello Daniel, > > I have explore the patreon site becauce I do not know it before. Short: > I do not like this service at all (5% fee, only paypal/creditcard, ...) > > If you in Germany/Leipzig and a german citizen, so I can offer you an > Midi-Job (witch include a health insurance). That'd be amazing, obviously :) > > We use lot of openwrt (and freifunk) a couple of years (and try use LEDE > now), so it was a good style for us to payback the active community. And > IMHO better then collecting cash via patreon's "Klingelbeutel". For sure. I also try to avoid receiving payments through patreon, but only a small fraction of the people who are supporting me right now are from within the EU and hence have access to free SEPA transfers. And if people provide $$$ outside of patreon I need to do all the paper work (and when counting the hours for that 5% seems to be not too bad of a deal...) Some others offered sending bitcoin and such, which I for now refuse because I don't even know how the boureaucracy (tax-wise) works in that case, because they obviously want to remain anonymous and hence I can't know their name and address and all that... > > Our office is in Hamburg, but we want open a small office in Leipzig > this year (asap). > > Is this a option for you, or is this a stupid idea? Depends on what you want me to do. The difference here is that patreon allows me to do what I believe is important or fun to do and people can reward me for that or just support me even for reasons beyond my own understanding. A job, opposed to that, usually comes with quite different expectations of the people who provide the cash. I usually don't survive in those settings, because I'm not a very obediant person (apparently so) and I simply cannot force myself to do things which I don't believe in myself. If I try anyway, I very quickly get very depressed, sick and angry, because I truely hate the outcomes of most commercially motivated technological progress (such as selling more useless stuff, knowing more about customers, brainwashing people into mindless and ultra-dependent isolated consumers, ...) Excuses like 'but we need to make a business somehow' don't count and don't really increase my motivation... Hence I shifted my commercial activity to work in kitchens most of the time, because making good food doesn't contradict with my own will and my expectations towards food seem to correlate with the taste and expectations of the people entering the restaurant... Business-wise that didn't work well, the restaurant had to close last year due to increasing rent and labour costs (they payed minimum wage)... Anyway, all that may all sound too harsh and I don't even know what your company is doing. Maybe it's totally what I believe would be great to do and have on this planet, create a future which I'd want to live in and so on... So please tell me more :) Cheers Daniel > > Cheers > > Benni > > Am 22.03.2017 um 11:22 schrieb Daniel Golle: > > Hi everyone, > > > > most of you might know me for hacking on embedded stuff while having > > the common good in mind. Because I'm practically always out of money, > > I decided to setup a patreon account which can help me to gather at > > least the $$$ needed to pay for obligatory health insurance and such > > things. It'd be great if you spread the word and also give me feedback > > (off-list!) so I can improve my patreon page. > > > > https://www.patreon.com/dangowrt > > > > > > Cheers > > > > > > Daniel > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev > > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] update asterisk
Hi! Please add add Signed-off-by: line and your real name, then I can apply the patch for you. Please also see the (cosmetic) coments below. On Thu, Apr 20, 2017 at 12:10:24AM +0300, Knall Kopf wrote: > Hello, > can everybody update the feed/telephony.git to the newest Asterisk and Libpri > libary version ? > For security reason it should be always the newest version. > > I have attach a patch where i have do it. > (some Asterisk patches are no more requiered, i add the stun-monitor module > and i put all not used modules and config i a rest module for config and > modules) > > Can everbody explain how the BuildAsterisk13Module work ? > ... > $(eval $(call BuildAsterisk13Module,subname,title,module description,module > dependencies,conf files,module files,sound files,binary files)) > ... > > > my goal is it to build the Asterisk modules as until now > ... > $(eval $(call BuildAsterisk13Module,res-timing-pthread,pthread Timing > Interfaceres_timing_pthread,,)) > $(eval $(call BuildAsterisk13Module,res-timing-timerfd,Timerfd Timing > Interfaceres_timing_timerfd,,)) > $(eval $(call BuildAsterisk13Module,voicemail,Voicemail,voicemail related > modules,+asterisk13-res-adsi > +asterisk13-res-smdi,voicemail.conf,app_voicemail,vm-*,)) > $(eval $(call BuildAsterisk13Module,res-stun-monitor,STUN monitoring,resource > STUN Monitor,,res_stun_monitor.conf,res_stun_monitor,,)) > ... > > after this procedure all *.so that are in ipkg-install but not inside > ipkg-mips_24kc should put to a rest module > > > > > Additional the mail Address: plonk-lede...@yandex.com can be deleted because > i get no access to it. > From a658e6cd7e02f7b7c89d77bf0bac1464829a06be Mon Sep 17 00:00:00 2001 > From: Plonk Bong > Date: Tue, 18 Apr 2017 23:43:36 + > Subject: [PATCH] update-asterisk-to-current-version > > --- > net/asterisk-11.x/Makefile | 16 +++- > net/asterisk-11.x/patches/051-musl-includes.patch | 42 - > net/asterisk-13.x/Makefile | 8 +- > .../patches/004-ifdef-missing-execinfo.patch | 101 > - > .../patches/040-fix-config-options.patch | 12 --- > net/asterisk-13.x/patches/051-musl-includes.patch | 42 - > 6 files changed, 18 insertions(+), 203 deletions(-) > delete mode 100644 net/asterisk-11.x/patches/051-musl-includes.patch > delete mode 100644 net/asterisk-13.x/patches/004-ifdef-missing-execinfo.patch > delete mode 100644 net/asterisk-13.x/patches/040-fix-config-options.patch > delete mode 100644 net/asterisk-13.x/patches/051-musl-includes.patch > > diff --git a/net/asterisk-11.x/Makefile b/net/asterisk-11.x/Makefile > index 14d8aa5..d53e5e1 100644 > --- a/net/asterisk-11.x/Makefile > +++ b/net/asterisk-11.x/Makefile > @@ -9,12 +9,12 @@ > include $(TOPDIR)/rules.mk > > PKG_NAME:=asterisk11 > -PKG_VERSION:=11.22.0 > -PKG_RELEASE:=2 > +PKG_VERSION:=11.25.1 > +PKG_RELEASE:=1 > > PKG_SOURCE:=asterisk-$(PKG_VERSION).tar.gz > > PKG_SOURCE_URL:=http://downloads.asterisk.org/pub/telephony/asterisk/releases/ > -PKG_MD5SUM:=35870c34fadbd2bcb284bd8521c6e689 > +PKG_MD5SUM:=1b023b3b6230e8d7dac49afdc85a934e > > PKG_BUILD_DIR:=$(BUILD_DIR)/asterisk-$(PKG_VERSION) > PKG_BUILD_DEPENDS:=libxml2/host > @@ -467,4 +467,12 @@ $(eval $(call > BuildAsterisk11Module,res-timing-pthread,pthread Timing Interface, > $(eval $(call BuildAsterisk11Module,res-timing-timerfd,Timerfd Timing > Interface,res_timing_timerfd,)) > $(eval $(call BuildAsterisk11Module,res-xmpp,XMPP client and component > module,reference module for interfacting Asterisk directly as a client or > component with XMPP server,+libiksemel > +libopenssl,/etc/asterisk/xmpp.conf,xmpp.conf,res_xmpp,)) > $(eval $(call BuildAsterisk11Module,res-realtime,Realtime > Interface,res_realtime,)) > -$(eval $(call BuildAsterisk11Module,voicemail,Voicemail,voicemail related > modules,+asterisk11-res-adsi > +asterisk11-res-smdi,/etc/asterisk/voicemail.conf,voicemail.conf,*voicemail,vm-*)) > > +$(eval $(call BuildAsterisk11Module,voicemail,Voicemail,voicemail related > modules,+asterisk11-res-adsi > +asterisk11-res-smdi,/etc/asterisk/voicemail.conf,voicemail.conf,*voicemail,vm-*)) > + > + > + > +$(eval $(call BuildAsterisk11Module,res-stun-monitor,STUN > monitoring,resource STUN > Monitor,,/etc/asterisk/res_stun_monitor.conf,res_stun_monitor.conf,res_stun_monitor,)) > + > +$(eval $(call BuildAsterisk11Module,rest-configs,rest configs,All config > files that are not in any package,,/etc/asterisk/res_snmp.conf > /etc/asterisk/dbsep.conf /etc/asterisk/muted.conf /etc/asterisk/osp.conf > /etc/asterisk/cli.conf /etc/asterisk/vpb.conf > /etc/asterisk/res_config_sqlite.conf /etc/asterisk/sla.conf > /etc/asterisk/festival.conf /etc/asterisk/misdn.conf /etc/asterisk/say.conf > /etc/asterisk/cli_aliases.conf /etc/asterisk/res_ldap.conf > /etc/asterisk/res_curl.conf /etc/asterisk/app_skel.conf > /etc/asterisk/res_coro
[LEDE-DEV] RFC: files included in initramfs images (was: [PATCH] ramips: enable ramdisk for mt7621)
Hi Paul, I've merged your patch, however, it looks like the buildbot process still doesn't generate the desired image (despite our tests and success we've seen earlier). This is because the ubnt-erx-factory-image build artifact cannot work in the ImageBuilder and I've converted it into a nicer and more compact variant (see patch below). However, it still doesn't work for a rather odd and not as easy to fix reason: The resulting initramfs-kernel.bin as found on http://downloads.lede-project.org/snapshots/targets/ramips/mt7621/lede-ramips-mt7621-ubnt-erx-initramfs-kernel.bin is 3427 KB in size -- however, the Er-X allows only up to 3072 KB. This is because (other than the rootfs) the initramfs is still not generated individually for each board but rather contains all packages needed for all boards in the same subtarget: on MT7621 this includes several WiFi drivers and lots of things you usually won't ever need on the Er-X. Hence I suggest to change the way to initramfs is generated in general: Create a second rootfs for initramfs and have only a very minimal and not board-specific set of packages installed there. Maybe this could also include stuff usually only needed during recovery/rescue/factory situations such as a minimal web-interface which allows flashing the 'real' LEDE firmware. To control the initramfs behaviour of the build-system we could introduce a new config variable such as CONFIG_TARGET_ROOTFS_INITRAMFS_MINIMAL which defaults to y but can be disabled if people actually want the whole usual rootfs being included in the initrd as well. And we could have CONFIG_TARGET_ROOTFS_INITRAMFS_MINIMAL_EXTRA_PACKAGES to allow including packages which aren't part of the normal rootfs. I'd like to hear some opinion about that from Felix, John, Matthias, Jo-Philipp, Hauke, Yousong, et al. before I get started to implement this because it's a quite drastic change... Cheers Daniel diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index b57552a6f4..c9b2e537d4 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -3,27 +3,19 @@ # define Build/ubnt-erx-factory-image - if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) -a "$$(stat -c%s $@)" -lt "$(KERNEL_SIZE)" ]; then \ - echo '21001:6' > $(1).compat; \ - $(TAR) -cf $(1) --transform='s/^.*/compat/' $(1).compat; \ - \ - $(TAR) -rf $(1) --transform='s/^.*/vmlinux.tmp/' $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE); \ - mkhash md5 $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) > $(1).md5; \ - $(TAR) -rf $(1) --transform='s/^.*/vmlinux.tmp.md5/' $(1).md5; \ - \ - echo "dummy" > $(1).rootfs; \ - $(TAR) -rf $(1) --transform='s/^.*/squashfs.tmp/' $(1).rootfs; \ - \ - mkhash md5 $(1).rootfs > $(1).md5; \ - $(TAR) -rf $(1) --transform='s/^.*/squashfs.tmp.md5/' $(1).md5; \ - \ - echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' > $(1).version; \ - $(TAR) -rf $(1) --transform='s/^.*/version.tmp/' $(1).version; \ - \ - $(CP) $(1) $(BIN_DIR)/; \ - else \ - echo "WARNING: initramfs kernel image too big, cannot generate factory image" >&2; \ - fi + rm -rf $@.uImage $@.compat $@.rootfs $@.md5 $@.version + mv $@ $@.uImage + echo '21001:6' > $@.compat + $(TAR) -cf $@ --transform='s/^.*/compat/' $@.compat + $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp/' $@.uImage + mkhash md5 $@.uImage > $@.md5 + $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp.md5/' $@.md5 + echo "dummy" > $@.rootfs + $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp/' $@.rootfs + mkhash md5 $@.rootfs > $@.md5 + $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp.md5/' $@.md5 + echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' > $@.version + $(TAR) -rf $@ --transform='s/^.*/version.tmp/' $@.version endef define Device/11acnas @@ -166,10 +158,12 @@ TARGET_DEVICES += timecloud define Device/ubnt-erx DTS := UBNT-ERX FILESYSTEMS := squashfs - KERNEL_SIZE := 3145728 + KERNEL_SIZE := 3072k KERNEL := $(KERNEL_DTB) | uImage lzma IMAGES := sysupgrade.tar - KERNEL_INITRAMFS := $$(KERNEL) | ubnt-erx-factory-image $(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar + KERNEL_INITRAMFS := $(KERNEL_DTB) | uImage lzma | check-size $(KERNEL_SIZE) | ubnt-erx-factory-image + KERNEL_INITRAMFS_PREFIX = $$(IMAGE_PREFIX)-factory + KERNEL_INITRAMFS_SUFFIX := .tar IMAGE/sysupgrade.tar := sysupgrade-tar | append-metadata DEVICE_TITLE := Ubiquiti EdgeRouter X DEVICE_PACKAGES := -kmod-mt76 -kmod-mt7603 -kmod-mt76x2 -kmod-mt76-core -kmod-mac80211 -kmod-cfg80211 -wpad-mini -iwinfo On Thu, May 04, 2017 at 12:47:34AM +0200, Paul Spooren wrote: > Fixes #758 > > Signed-off-by: Paul Spooren > --- > targe
Re: [LEDE-DEV] RFC: files included in initramfs images (was: [PATCH] ramips: enable ramdisk for mt7621)
Hi everyone, I found another quick solution to the problem which was to reduce the amount of packages in the default profile of MT7621. See commit d17cb4a68a45 in the master branch. When it came to backport this to lede-17.01 I noticed that several boards have been added to master since and are not yet present in the lede-17.01 branch. Also the ZBT WG3526 has been split-up into a 16MB flash and 32MB flash variant and Digineo AC1200 Pro has been renamed/merged with ZBT-WG3625-16M. Should I cherry-pick all added boards to lede-17.01, including the rename of the Digineo device? Or just backport the commit changing the default packages from master and skip the boards which are not preset in lede-17.01 (which obviously makes future backporting of the commits adding those boards harder)? Cheers Daniel On Thu, May 04, 2017 at 05:35:59AM +0200, Daniel Golle wrote: > Hi Paul, > > I've merged your patch, however, it looks like the buildbot process > still doesn't generate the desired image (despite our tests and success > we've seen earlier). This is because the ubnt-erx-factory-image build > artifact cannot work in the ImageBuilder and I've converted it into > a nicer and more compact variant (see patch below). > However, it still doesn't work for a rather odd and not as easy to fix > reason: > The resulting initramfs-kernel.bin as found on > http://downloads.lede-project.org/snapshots/targets/ramips/mt7621/lede-ramips-mt7621-ubnt-erx-initramfs-kernel.bin > is 3427 KB in size -- however, the Er-X allows only up to 3072 KB. > This is because (other than the rootfs) the initramfs is still not > generated individually for each board but rather contains all packages > needed for all boards in the same subtarget: on MT7621 this includes > several WiFi drivers and lots of things you usually won't ever need > on the Er-X. > > Hence I suggest to change the way to initramfs is generated in general: > Create a second rootfs for initramfs and have only a very minimal and > not board-specific set of packages installed there. Maybe this could > also include stuff usually only needed during recovery/rescue/factory > situations such as a minimal web-interface which allows flashing the > 'real' LEDE firmware. > To control the initramfs behaviour of the build-system we could > introduce a new config variable such as > CONFIG_TARGET_ROOTFS_INITRAMFS_MINIMAL which defaults to y > but can be disabled if people actually want the whole usual rootfs > being included in the initrd as well. > And we could have CONFIG_TARGET_ROOTFS_INITRAMFS_MINIMAL_EXTRA_PACKAGES > to allow including packages which aren't part of the normal rootfs. > > I'd like to hear some opinion about that from Felix, John, Matthias, > Jo-Philipp, Hauke, Yousong, et al. before I get started to implement > this because it's a quite drastic change... > > > Cheers > > > Daniel > > > > > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index b57552a6f4..c9b2e537d4 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -3,27 +3,19 @@ > # > > define Build/ubnt-erx-factory-image > - if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) -a "$$(stat -c%s $@)" -lt > "$(KERNEL_SIZE)" ]; then \ > - echo '21001:6' > $(1).compat; \ > - $(TAR) -cf $(1) --transform='s/^.*/compat/' $(1).compat; \ > - \ > - $(TAR) -rf $(1) --transform='s/^.*/vmlinux.tmp/' > $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE); \ > - mkhash md5 $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) > $(1).md5; \ > - $(TAR) -rf $(1) --transform='s/^.*/vmlinux.tmp.md5/' $(1).md5; \ > - \ > - echo "dummy" > $(1).rootfs; \ > - $(TAR) -rf $(1) --transform='s/^.*/squashfs.tmp/' $(1).rootfs; \ > - \ > - mkhash md5 $(1).rootfs > $(1).md5; \ > - $(TAR) -rf $(1) --transform='s/^.*/squashfs.tmp.md5/' $(1).md5; > \ > - \ > - echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' > > $(1).version; \ > - $(TAR) -rf $(1) --transform='s/^.*/version.tmp/' $(1).version; \ > - \ > - $(CP) $(1) $(BIN_DIR)/; \ > - else \ > - echo "WARNING: initramfs kernel image too big, cannot generate > factory image" >&2; \ > - fi > + rm -rf $@.uImage $@.compat $@.rootfs $@.md5 $@.version > + mv $@ $@.uImage > + echo '21001:6' > $@.compat > + $(TAR) -cf $@ --transform='s
Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal
On Mon, May 08, 2017 at 09:19:42PM +0200, Zoltan HERPAI wrote: > Hi, > > On Mon, 8 May 2017, Daniel Engberg wrote: > > > Trac: > > Is it really worth keeping trac at all? What value does it add? Just > > display a page explaining that it's shutdown and forward to OpenWrt? > > There is a lot of "added value" in the tickets submitted throughout the > years, either as comments, notes, fixes or just the issue being raised, so > it's a good idea to keep it for archiving purposes. Older devices do die, > but every year or so I come across shops selling brand new WRT54G (really), > so keeping the knowledge base in an unsorted form (compared to a wiki) to > the users can be useful. Whether that's a staticized archive or running the > trac engine itself is another question. I agree that there are a lot of references to dev.openwrt.org which should remain intact. A non-interactive version would imho be sufficient, tickets which are actually still relevant should be re-opened on bugs.lede-project.org (which will become bugs.openwrt.org) A grace period of 1 month starting from the notification until the service is being shutdown (or archived read-only) would also be nice. > > Other than that, I very much welcome the groundwork for the planned merge - > thanks John, Imre and Felix for putting it together. I agree. Thanks a lot for all the work done, this is great progress! Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
Hi Edwin, On Fri, May 12, 2017 at 10:02:36AM +0200, Edwin van Drunen wrote: > As a long time user of OpenWRT and recent “LEDE convert” I would also like to > chime in on the naming and branding of the post-merge project. > > My employer and several of my industrial clients have used OpenWRT/LEDE > extensively over the past few years in many projects, ranging from routers > and access points to embedded servers and industrial controllers. > It was the small footprint combined with the versatility of the platform that > made it work and the availability of generic pre-built images for many > platforms and documentation that made it a success. > But despite the great track record of the system, there was always a bit of a > “hobbyist” feel that the OpenWRT name brought with it and a sense of > unprofessionalism being perceived by management and some end users. > Most likely this is because the name OpenWRT is strongly related to “hacking" > consumer routers (WRT54GL etc.) and the 90’s style website also didn’t help. > > When LEDE was forked and presented as a more multi-purpose embedded linux, > came with new releases quickly and with a more modern website and interface > to code and documentation, the switch was easily made. > Not having WRT in the name, implying it would be for wireless routers, but > instead using the broad term “development environment” was helping to better > describe what the platform is and give it a more professional sound. > With the new name the platform was now seen as a professional piece of > infrastructure. This quite matches the experience I've made when presenting the LEDE fork... > > In my opinion LEDE perfectly describes the combination of OpenWRT’s version > of the buildroot system, the set of patches and the Luci interface: > The entire development environment that is needed to build a generic bootable > image and software packages from source for almost any platform, with > matching pre-built SDK’s and image builders. > > OpenWRT better describes the wide range of specific system images built for > COTS products (which are mostly wireless routers) and is a more suitable name > for a final “product". > You should consider maintaining the LEDE name or somehow differentiatie > between the “development environment” and the "final product". I strongly agree here as well, I believe the "LEDE" project could release an "OpenWrt" product in reasonable time intervals and that should be targetting home routers and similar embedded systems. Cheers Daniel > > With kind regards, > Edwin van Drunen > > > Who among our resident young-timers knows XMMS? Once upon a time this > > was a household name (FOSS folks houses). Now I reckon those who use it > > as a primary player do it for nostalgia. > > > > Likewise, OpenWRT while more recognizable than LEDE, is not worth as > > much as people here paint it, and will only remain relevant as long as > > people keep using it. Market/brand concept (in retail) doesn't really apply. > > > > Indifferent what name this project ends up using, just that LEDE (Linux > > Embedded Dev. Environment) expands the scope beyond routers, and breaks > > free from the "WRT" implication of wireless routers (does LEDE still > > have any of the original WRT source release by linksys?). > > > > LEDE sounds more fitting and gives the impression of a proper distro, > > which it is, rather than an improved fork/clone of an ancient source dump. > > > > No biggie, just thought I'd chime in. Good luck all. > > > > Regards, > > A. Benz > > > > On 05/09/17 09:33, Eric Luehrsen wrote: > >> > > From a raw objective stand, OpenWrt has better market value as a brand. > > > >> > > Its longer lived on the net and more unique audibly. If we surveyed 1000 > > > >> > > somewhat technical people, then we would have way more recognition hits. > > > >> > > I realize the vote concluded already, but hopefully this thought helps > > > >> > > ease some less happy minds. > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] ramips: add support for GL-inet GL-MT300N-V2
On Fri, May 12, 2017 at 05:51:18PM -0500, L. D. Pinney wrote:
> On Fri, May 12, 2017 at 5:29 PM, Mathias Kresin wrote:
> > 12.05.2017 03:37, kyson lok:
> >>
> >> On Fri, May 12, 2017 at 6:18 AM, L. D. Pinney wrote:
>
> +&spi0 {
> + status = "okay";
> +
> + m25p80@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <1000>;
> + m25p,chunked-io = <32>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "u-boot-env";
> + reg = <0x3 0x1>;
> + read-only;
> >>>
> >>>
> >>> Is there a reason that users can not or should not write to the
> >>> uboot-env partition?
> >
> >
> > Yes, to prevent the user to shout them self into the foot. If it ain't broke
> > don't fix it.
>
> "Unix was not designed to stop you from doing stupid things, because
> that would also stop you from doing clever things."
> Doug Gwyn
>
> In this case using the uboot-envtools package...
I generally agree with that philosophy, however, in this case there are
hardly any options other shooting yourself into the foot.
The ramips-version of U-Boot doesn't really allow for any fancy things
to be done with it -- and people who really want to risk ending up
with a device which no longer boots and is only recoverable via serial
console can as well change the device-tree to have unprotected access
to the flash.
Also note that most (if not nearly all) other ramips target got the
u-boot-env partition set to be read-only for that reason.
> >>> Is this correct? other mt76x8 devices with 16MB SPI Flash use :
> >>>
> >>> partition@5 {
> >>> label = "firmware";
> >>> reg = <0x5 0xfb>;
> >>>
> >>
> >> I think it doesn't matter. I only use 15MB for firmware.
> >
> >
> > But why don't you use all available flash space? As far as I can see, there
> > isn't anything in the last 704 KB of the flash. If possible expand the
> > firmware partition to use all of the remaining flash space.
> >
> > Please update the IMAGE_SIZE in the build code to the value set here.
Yes, please use the whole flash chip and don't leave behind unused
areas.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] convention on uid/gid for packages
Hi Val, On Sat, May 13, 2017 at 06:23:29PM -0400, Val Kulkov wrote: > Is there any convention on the use of uid and gid when creating new > users or groups? Can someone point me to it, if it exists? > > I noticed that two packages, icecast and postfix, compete for the same uid=87: > > icecast's Makefile: > USERID:=icecast=87:icecast=87 > > postfix's postfix.init: > user_exists postfix || user_add postfix 87 This looks wrong to me (user_add in the init script)... > > There may be more packages competing for the same uid/gid's, I have > not fully researched it. > > I am preparing a new package, opendkim, which should be run as a > non-privileged user. For this, > USERID:=opendkim=:opendkim= seems appropriate, > but what numbers should I assign? I run into this issue before and believe that we should have a wiki page which allows registering static UIDs/GIDs at least for the packages which actually need that (ie. if a specific UID or GID is referenced in other packages, or scripts like firewall rules, ...). Grep'ing for USERID allows to automatically generate that list based on the currently available packages very easily. Examples from elsewhere for inspiration: FreeBSD got those lists https://svnweb.freebsd.org/ports/head/UIDs?view=markup https://svnweb.freebsd.org/ports/head/GIDs?view=markup linuxfromscratch got a much smaller list for essential/system UIDs/GIDs http://linuxfromscratch.org/blfs/view/svn/postlfs/users.html Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] convention on uid/gid for packages
On Mon, May 15, 2017 at 10:59:55PM +0800, Yousong Zhou wrote:
> On 15 May 2017 at 22:41, Val Kulkov wrote:
> > The auto-allocation of uid/gid emulates useradd/groupadd, picking the
> > first unused uid/gid starting from 100. This works quite well on its
> > own, but there are about three dozen packages in the packages repo
> > that come with hardcoded uid/gid's:
> >
> > find -L package/ -name Makefile -exec grep 'USERID:=' {} \;
> >
> > produces 35 or so lines indicating the assignment of hardcoded uids and
> > gids.
> >
> > At present, if someone installs five packages that use the
> > auto-allocation mechanism, uids 100-105 will be taken by the
> > auto-allocation mechanism (101 is already taken by 'network'). After
> > that, attempting to install the 'avahi' package will result in a
> > conflict:
> >USERID:=avahi=105:avahi=105
> >
> > IMO such conflicts can and must be avoided.
>
> Exactly!
>
> > Perhaps the easiest way to
> > avoid such conflicts is to maintain a list of uid/gid allocation (a la
> > FreeBSD) and have a policy in place regarding the allocation of new
> > uid/gid's. For example, the 1-999 range may be reserved for services
> > and starting from 1000 for regular users. IMO this is an important
> > step forward in creating a resilient package space environment.
> >
>
> Maintain a big list and package it in every built firmware so that
> auto-allocation can skip them? It's overkill I guess.
>
> How about just converting existing hardcoded uid/gid assignment to use
> only auto-allocation method and also drop the USERID=un=uid:gn=gid
> support from default_postinst. Will this break something
> significantly?
Yes, it will break at least one place I know where I rely on hardcoded
GIDs being adjecent for their use with the 'owner' match in iptables,
see
https://github.com/openwrt/packages/blob/master/net/gnunet/files/gnunet-gns.defaults#L36
However, differentiating DNS traffic generated by 'special DNS users'
(such as DNS servers, caches, ...) from regular DNS traffic is truly
the only application I can think of right now, I never needed to
rely on hard-coded GIDs before. If anyone knows a good and
non-intrusive alternative to the above, I'd be happy to switch to
auto-allocated UIDs/GIDs.
>
> yousong
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH/RFC] rootfs: don't enable init-scripts during rootfs generation
Init scripts are already being enabled in default_postinst. Signed-off-by: Daniel Golle --- include/rootfs.mk | 4 1 file changed, 4 deletions(-) diff --git a/include/rootfs.mk b/include/rootfs.mk index 74785cbbd3..6167306f0c 100644 --- a/include/rootfs.mk +++ b/include/rootfs.mk @@ -70,10 +70,6 @@ define prepare_rootfs exit 1; \ fi; \ done; \ - for script in ./etc/init.d/*; do \ - grep '#!/bin/sh /etc/rc.common' $$script >/dev/null || continue; \ - IPKG_INSTROOT=$(1) $$(which bash) ./etc/rc.common $$script enable; \ - done || true \ ) $(if $(SOURCE_DATE_EPOCH),sed -i "s/Installed-Time: .*/Installed-Time: $(SOURCE_DATE_EPOCH)/" $(1)/usr/lib/opkg/status) @-find $(1) -name CVS | $(XARGS) rm -rf -- 2.13.0 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Problem with commit "kernel: add hwmon for W83627EHF and family"
Hi Rafal,
On Sun, May 21, 2017 at 05:02:44PM +0200, Rafał Miłecki wrote:
> Hi,
>
> I noticed commit 0dcc36fc7ddec ("kernel: add hwmon for W83627EHF and
> family") in the LEDE tree that doesn't look OK to me.
>
> 1) Package for hwmon-w83627ehf
> Do we need it to be a package? Or could it be built-in into the kernel?
> Do we need it to be a global package? Usually hwmon drivers are
> designed for a specific device and it should be enough to have it in
> target/linux/*/modules.mk
True, but all other x86-specific hwmon modules are in
package/kernel/linux/modules as well and I'd rather wanted it to be
consistent.
>
> 2) 800-hwmon-w83627ehf-dont-claim-nct677x.patch
> I really don't like this one as it's totally unclear why we need this
> change. What's wrong with NCT6775 and the w83627ehf driver? It should
> be well described in the patch.
Sorry for the lack of a more detailed description.
The problem here is that the W83627EHF driver also claims the NCT677x
hardware but doesn't support all features (according to
Philip Prindeville). I reckon he can provide more information regarding
which features which are available when using the nct6776 driver are
missing in the w83627ehf driver on NCT677x hardware.
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Planning v17.01.2
Hi Jo, On Wed, May 24, 2017 at 10:34:20PM +0200, Jo-Philipp Wich wrote: > Hi, > > I'd like to start preparing the v17.01.2 release during the upcoming > weekend with the goal to release final binaries within the next week > (~May 29th till June 3rd). > > Changes that shall be part of 17.01.2 should be merged until Sunday, the > 28th. > > You can find the current list of changes since v17.01.1 at > https://lede-project.org/releases/17.01/changelog-17.01.2 > > The most notable change is a security fix affecting the builtin dropbear > SSH server. While the default configuration does not appear to be > vulnerable, we still should provide updated images as soon as possible. > > > If you want specific fixes cherry-picked/backported to lede-17.01, > please mention them in a reply to this mail. I'd like to see commit ed62d91f4b5296a4aa883ce975d76f590ef4e910 from Nick Lowe hostapd: add legacy_rates option to disable 802.11b data rates commit 1a16cb9c67f0d2c530914aec31c721b75f03a908 from Matthias Schiffer mac80211, hostapd: always explicitly set beacon interval included as that fixes co-existence of AP+mesh interface combination which was previously broken. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal V3
On Mon, May 29, 2017 at 09:03:57AM +0200, John Crispin wrote: > (resend, this time as plain text) > > Hi, > > here is a V3 of the remerge proposal, I tried to fold all the comments > people made into it, if anything is missing let me know. Please remeber that > post remerge anything can be voted on, so cluttering the proposal with many > details will delay the remerge even more. > > Ideally we manage to vote during this week. +1 ACK ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] MT7688 SPI confusion
Hi! I'm currently trying to get SPI with two devices connected to work on MT7688 and noticed that the spi-mt7621 driver got a pretty weird work-around going on: if CS# is set it does only half-duplex transfers which if CS# is not set it does full-duplex. John has then disabled full-duplex alltogether on the Chaos Calmer branch [1]. What I'm trying to achieve is to use WrtNode2R's spi-bridge [2] to communicate with the STM32 MCU running RT-Thread. This somehow works in Chaos Calmer when using WrtNode modified tree [3] but doesn't work well on LEDE git HEAD... Any ideas? Apart from the spi-based rpc/console the Wrtnode2R comes with a flash tool for the STM32 [4] -- it would of course be much nicer to have a SPI backend for stm32flash to achieve the same thing. To be able to implement that I'd like to first understand what is needed to get SPI fixed so that the not-very-beautiful existing tooling can be replaced. Any experience with more than one SPI slave connected to MT76xx SoCs, stm32flash via SPI and general ideas/inspiration on bridging with RTOS running on MCUs next to an embedded Linux SoC is more than welcome :) Cheers Daniel [1]: commit 877ee7d7f54847b4e95c1feb6de0f5413e2fe7a1 Author: John Crispin Date: Tue Apr 19 21:01:34 2016 + ralink: add spi fix the fullduplex on CS1 is broken. remove the fullduplex support and run on plain half duplex on both CS lines. Signed-off-by: John Crispin git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49201 3c298f89-4303-0410-b956-a3cf2f4a3e73 [2]: https://github.com/WRTnode/openwrt-packages/blob/master/wrtnode/spi-bridge/src/main.c [3]: https://github.com/WRTnode/openwrt [4]: https://github.com/WRTnode/openwrt-packages/blob/master/wrtnode/WRTnode2r-stm32/src/main.c#L57 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] enable Banana Pi OTG
On Sat, Jun 10, 2017 at 02:53:53PM +0200, Gerhard Bertelsmann wrote: > Hi, > > the Banana Pi has a USB OTG capable port. This seems to be not enabled > or choosable with 'make menuconfig'. I had a quick look in the > makefiles but didn't find the central place where USB_GADGET_SUPPORT > is enabled. > > Could somebody put me in the right direction to enable USB OTG > for SUNXI unde Lede ? I'm not sure whether the OTG drivers are supported in the kernel, but you can give it a shot by adding the 'usbgadget' feature to the FEATURES variable in target/linux/sunxi/Makefile you may need to package the kernel module in charge of gadget mode on that hardware... Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] solar wifi AP designs
Hi! I use EPSolar Tracer MPPT controllers here, the older RN series got a 3.3V-level TTL serial port for which I've written a small tool which allows easy integration with collectd: https://github.com/dangowrt/tracertools/ (package can be found on github.com/openwrt/packages as well) The slightly newer BN series is different because it got an RS-485 port and speaks proper Modbus, ie. you can use collectd-mod-modbus to query the controller and won't need any specific tools (but an RS-485 tansceiver and a proper UART with RTS/CTS signals to drive it -- I didn't find any USB-to-serial solutions which are as realiable as an in-SoC UART and won't randomly stop working after a couple of weeks) collectd.conf for 'true' Modbus capable 'BN' series controllers: https://pastebin.com/tzGWi5tX The BN series is also nicer because you can attach more power than the controller can take, so eg. have up to 350Wp connected to a 10A controller and still be fine in winter without burning the MPPT in summer... A screenshot taken from a slightly larger system: http://picpaste.com/solar-fSkWIMVQ.png I admit that a 10A+ controller with a pricetag starting around EUR 70 is too much to just drop it with a small panel somewhere on a tree to power a single router -- for those cases I've sometimes used TP-LINK MR2030 with a 5V USB powerbank and simple step-down converter to charge it directly form a solar panel (obviously without MPPT nor monitoring). It will be fine in the summer, it won't survive the long nights in winter (also because those crappy batteries don't like extreme temperaturs). So I look forward to see a nice and small solution for 5A Elektra is currently working on. And I'd love to see it charing lithium batteries recycled form old laptops rather than lead-acid Watch her talk about that: https://www.youtube.com/watch?v=NLP4MxQp8kk Cheers Daniel On Sat, Jun 10, 2017 at 01:01:00PM +, Vieno Foo wrote: > At the local hackspace we changed some WRT54GL to do PoE. Power the WRT > via a 12 V battery and have the same voltage on the output. Input > voltage = output voltage. > The battery could be replaced by a solar panel or a combination of both. ;-) > > http://picpaste.com/IMG_20170605_064049.jpg > > kind regards > txt.file > > Eric Luehrsen: > > On 06/04/2017 08:46 PM, Dave Taht wrote: > >> I keep finding nicely integrated solar/battery/camera designs like these > >> > >> https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Delectronics&field-keywords=solar+wifi&rh=n%3A172282%2Ck%3Asolar+wifi > >> > >> But what I'd like is just something with solar and battery that could > >> function as an AP, that was well supported by lede. Ideas? > >> > > A router that runs on a 12V supply > > > > - > > https://www.amazon.com/TP-Link-Archer-C7-Wireless-Gigabit/dp/B00BUSDVBQ/ref=sr_1_2?ie=UTF8&qid=1496629045&sr=8-2&keywords=tp+link+archer+c7 > > > > Good old fashioned lead acid battery > > > > - > > https://www.amazon.com/Interstate-Batteries-SLA1116-Lead-Battery/dp/B004KNPIWS/ref=sr_1_4?ie=UTF8&qid=1496628899&sr=8-4&keywords=Interstate+Batteries > > > > 12V Solar Panel > > > > - > > http://www.homedepot.com/p/Nature-Power-22-Watt-Amorphous-Solar-Panel-Charging-Kit-with-8-Amp-Charge-Controller-for-12-Volt-Systems-42022/300854090?MERCH=REC-_-PIPHorizontal1_rr-_-204759893-_-300854090-_-N > > > > Duct Tape :-) > > > > - > > http://www.homedepot.com/p/NATIONAL-1-89-in-x-40-yd-Utility-Grade-Duct-Tape-Silver-1118105/202352331 > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev > > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] CONFIG_BRIDGE_VLAN_FILTERING
I noticed that the Linux built-in bridge now supports filtering by VLAN tags. This can be much more efficient than using ebtables for the same task, hence I wonder if there is any reason to keep this disabled or if there is interest in enabling it (I'd evaluate the space requirements on most space-critical platforms). Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 1/2] base-files: allocate uid/gid starting from 65536
On Fri, Jun 16, 2017 at 10:30:14AM -, Karl Palsson wrote:
>
>
> I fairly strong feel that this change brings no value to the
> table.
I disagree. For now, the two allocation schemes (hardcoded vs.
dynamic) are competing for the same address space. This can
result in a hard-coded UID/GID to be already allocated to a
package using the dynamic allocation method. Shifting the
dynamic allocation to the range starting from 65536 solves
that problem in a convenient way.
Hence I support Yousong's change.
Cheers
Daniel
>
> Sincerely,
> Karl Palsson
>
> Yousong Zhou wrote:
> > There already exist static assignment of uid/gid 65533 in
> > packages feed and we have nobody/nogroup taking 65534 as their
> > ids. Let's change the pid of dynamic assignment to start from
> > 65536 so that the two assignment scheme will not collide with
> > each other
> >
> > While at it, fix the scan command checking existence of uid/gid
> >
> > Signed-off-by: Yousong Zhou
> > ---
> > package/base-files/Makefile | 2 +-
> > package/base-files/files/lib/functions.sh | 8
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/package/base-files/Makefile
> > b/package/base-files/Makefile index c669ff0ac6..54c157611f
> > 100644
> > --- a/package/base-files/Makefile
> > +++ b/package/base-files/Makefile
> > @@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
> > include $(INCLUDE_DIR)/version.mk
> >
> > PKG_NAME:=base-files
> > -PKG_RELEASE:=173
> > +PKG_RELEASE:=174
> > PKG_FLAGS:=nonshared
> >
> > PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
> > diff --git a/package/base-files/files/lib/functions.sh
> > b/package/base-files/files/lib/functions.sh index
> > 2b6415a200..81ef84b8ef 100755
> > --- a/package/base-files/files/lib/functions.sh
> > +++ b/package/base-files/files/lib/functions.sh
> > @@ -306,8 +306,8 @@ group_add_next() {
> > gid=$(grep -s "^${1}:" ${IPKG_INSTROOT}/etc/group | cut -d: -f3)
> > [ -n "$gid" ] && return $gid
> > gids=$(cat ${IPKG_INSTROOT}/etc/group | cut -d: -f3)
> > - gid=100
> > - while [ -n "$(echo $gids | grep $gid)" ] ; do
> > + gid=65536
> > + while [ -n "$(echo "$gids" | grep "^$gid$")" ] ; do
> > gid=$((gid + 1))
> > done
> > group_add $1 $gid
> > @@ -334,8 +334,8 @@ user_add() {
> > local rc
> > [ -z "$uid" ] && {
> > uids=$(cat ${IPKG_INSTROOT}/etc/passwd | cut -d: -f3)
> > - uid=100
> > - while [ -n "$(echo $uids | grep $uid)" ] ; do
> > + uid=65536
> > + while [ -n "$(echo "$uids" | grep "^$uid$")" ] ; do
> > uid=$((uid + 1))
> > done
> > }
> > --
> > 2.12.2
> >
> >
> > ___
> > Lede-dev mailing list
> > Lede-dev@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 1/2] base-files: allocate uid/gid starting from 65536
On Fri, Jun 16, 2017 at 12:15:19PM -, Karl Palsson wrote: > > Daniel Golle wrote: > > On Fri, Jun 16, 2017 at 10:30:14AM -, Karl Palsson wrote: > > > > > > > > > I fairly strong feel that this change brings no value to the > > > table. > > > > I disagree. For now, the two allocation schemes (hardcoded vs. > > dynamic) are competing for the same address space. This can > > result in a hard-coded UID/GID to be already allocated to a > > package using the dynamic allocation method. Shifting the > > dynamic allocation to the range starting from 65536 solves that > > problem in a convenient way. Hence I support Yousong's change. > > > > This doesn't fix that. There's absolutely nothing here that stops > someone using a hardcoded uid/gid of 65536 or so either. This > just changes one magic number to be a different magic number. => > no gain. The subtle difference here is that there are for now no hardcoded UIDs/GIDs above 65536 and we can easily establish a convention that all static allocations should be below 65536. Starting from 100 is just obviously created a problem for now, and there is no non-violent solution as not all packages can easily be converted to use dynamic allocations. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] build: Fix not altering KERNELRELEASE for external kernel
Not completely related, but it came to my mind a couple of days ago
and maybe you can share your opinion:
Shouldn't we also be setting CONFIG_LOCALVERSION if *not* using an
external kernel, to indicate that this is *not* a vanilla kernel.org
codebase but actually got tons of OpenWrt/LEDE patches on top...?
See also
https://www.kernel.org/releases.html#distribution-kernels
On Sun, Jun 18, 2017 at 11:27:51PM +0200, Hauke Mehrtens wrote:
> When an external kernel tree is used the version should not get
> modified by the LEDE build scripts. This was added by Florian some time
> ago.
> The commit 0aed054becb21439 ("build: add KERNEL_MAKE and
> KERNEL_MAKE_FLAGS variables and move to kernel.mk") breaks this feature
> introduced in b6746a6ffb73 ("include: Do not alter KERNELRELEASE for
> external/git kernels").
>
> Signed-off-by: Hauke Mehrtens
> ---
> include/kernel.mk | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/include/kernel.mk b/include/kernel.mk
> index 464c94572e..7674f0dadc 100644
> --- a/include/kernel.mk
> +++ b/include/kernel.mk
> @@ -108,11 +108,10 @@ KERNEL_MAKE_FLAGS := \
> CONFIG_SHELL="$(BASH)" \
> $(if $(findstring c,$(OPENWRT_VERBOSE)),V=1,V='') \
> $(if $(PKG_BUILD_ID),LDFLAGS_MODULE=--build-id=0x$(PKG_BUILD_ID)) \
> - KERNELRELEASE=$(LINUX_VERSION) \
> cmd_syscalls=
>
> ifeq ($(call qstrip,$(CONFIG_EXTERNAL_KERNEL_TREE))$(call
> qstrip,$(CONFIG_KERNEL_GIT_CLONE_URI)),)
> - KERNEL_MAKEOPTS += \
> + KERNEL_MAKE_FLAGS += \
> KERNELRELEASE=$(LINUX_VERSION)
> endif
>
> --
> 2.11.0
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] procd: cherry-pick fixes into lede-17.01 branch
Hi! I've created a lede-17.01 branch for procd so fixes can be cherry-picked from master onto that branch. I suggest to pick the commits listed below: 453116e system: introduce new attribute board_name e5b963a preinit: define _GNU_SOURCE e5ff8ca upgraded: cmake: Find and include uloop.h f367ec6 hotplug: fix a memory leak in handle_button_complete() 796ba3b service/service_stopped(): fix a use-after-free 79bbe6d system: return legacy board name e7bb2c8 upgraded: define __GNU_SOURCE 992b796 rcS: add missing fcntl.h include d42b21e procd/rcS: Use /dev/null as stdin 1247db1 procd: Log initscript output prefixed with script name 8d720b2 procd: Don't use syslog before its initialization 2555474 procd: Add missing \n in debug message 8f218f5 procd: service gets deleted when its last instance is freed I would **not** pick: 63789e5 init: add support for sysupgrades triggered from preinit 5b1fb35 Remove code that has become unnecessary after sysupgrade changes 5918b6d upgraded: add support for passing a "command" argument to stage2 056d8dd upgraded: link dynamically, chroot during exec 7c6cf55 system: always support staged sysupgrade e0098d4 service/instance: add an auto start option abedd7f procd: update modprobe path Unless someone objects within 1 week from now, I take it as a passive consensus and will update the lede-17.01 branch as well as the procd package Makefile on the lede-17.01 branch. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] procd: cherry-pick fixes into lede-17.01 branch
Hi Florian, On Tue, Jun 20, 2017 at 09:00:30AM -0700, Florian Fainelli wrote: > On 06/20/2017 08:58 AM, Jo-Philipp Wich wrote: > > Hi, > > > > in principle I do not have any objections but I am not sure if we should > > really backport the sysupgrade changes yet. Are we sure that thestaged > > sysupgrade works as intended and was it properly tested? > > Based on the list that Daniel provided it seems to me like he is > actually excluding the staged upgrade changes from his cherry-pick list > unless I read that wrong. No, you are right. I excluded everything sysupgrade-related and the instance no-autostart feature. And the modprobe path wasn't changed on lede-17.01 which also excludes the corresponding changed from procd. This list are basically only bug-fixes with the exception of the the board_name addition to ubus call system board -- this is needed for the to-be-implemented auto-updater and I see it as a high-level bug that the board_name wasn't part of the original API. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] procd: cherry-pick fixes into lede-17.01 branch
On Tue, Jun 20, 2017 at 10:04:05AM -0700, Florian Fainelli wrote: > On 06/20/2017 07:52 AM, Daniel Golle wrote: > > Hi! > > > > I've created a lede-17.01 branch for procd so fixes can be > > cherry-picked from master onto that branch. > > I suppose that works, but I would be a bit concerned that we may have to > do the same thing with other "sub" projects that are maintained (netifd, > ubox etc.) and that maybe just putting the different patches under > package/*/*/patches may be equally easy to manage. I think in terms of managability creating a patches folder and putting files there is about as easy as creating a git branch. The advantage of the git branch is that one can more easily compare between the different branches, ie. see the diff between lede-17.01 and master. But true, it requires a git clone and the hash of the sourcefile on the download mirror also changes each time. However, I generally think it's worth the effort, but my preference of the branch-based solution is not a very strong opinion. Anyone else has an opinion whether creating a lede-17.01 branch for each sub-project vs. adding patches to a 'patches' folder belonging to that package inside the source.git tree should be prefered? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] uhttpd: fix PKG_BUILD_DEPENDS
uhttpd refered to ustream-ssl as PKG_BUILD_DEPENDS. While this intuitively seems like the correct thing to do, it turns out not to have the desired effect: PKG_BUILD_DEPENDS needs to list the resulting package name (ie. one of libustream-*) and not the source package name. This seems a bit ugly, as PKG_BUILD_DEPENDS should actually really reference source package names if you asked me. However, to fix things for now, use libustream-mbedtls to fix scripts/feeds and parallel builds which otherwise fail to build uhttpd. Reported-by: Paul Spooren Signed-off-by: Daniel Golle --- package/network/services/uhttpd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/services/uhttpd/Makefile b/package/network/services/uhttpd/Makefile index 3d483b692d..12896a1bb2 100644 --- a/package/network/services/uhttpd/Makefile +++ b/package/network/services/uhttpd/Makefile @@ -18,7 +18,7 @@ PKG_MIRROR_HASH:=2ac4ba8dc0b349d72174aac9ff693a73a214295a9890fe3d2a8eedcad54d06e PKG_MAINTAINER:=Felix Fietkau PKG_LICENSE:=ISC -PKG_BUILD_DEPENDS = ustream-ssl +PKG_BUILD_DEPENDS = libustream-mbedtls include $(INCLUDE_DIR)/package.mk include $(INCLUDE_DIR)/cmake.mk -- 2.13.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] uhttpd: fix PKG_BUILD_DEPENDS
On Thu, Jun 22, 2017 at 03:01:10PM +0200, Jo-Philipp Wich wrote: > Hi, > > that fix seems wrong to me as build depends must specify source packages. > This should be solved in buildroot instead. I fully agree with you :) So this needs to be addressed in scripts/feeds and scripts/metadata.pm and probably in more places. I'm not familiar with Perl at all. Is there Anyone with more insight into those scripts willing to have a look at the issue? > > ~ Jo > > > Am 22.06.2017 um 02:07 schrieb Daniel Golle : > > > > uhttpd refered to ustream-ssl as PKG_BUILD_DEPENDS. While this > > intuitively seems like the correct thing to do, it turns out not to > > have the desired effect: PKG_BUILD_DEPENDS needs to list the resulting > > package name (ie. one of libustream-*) and not the source package name. > > This seems a bit ugly, as PKG_BUILD_DEPENDS should actually really > > reference source package names if you asked me. > > However, to fix things for now, use libustream-mbedtls to fix > > scripts/feeds and parallel builds which otherwise fail to build uhttpd. > > > > Reported-by: Paul Spooren > > Signed-off-by: Daniel Golle > > --- > > package/network/services/uhttpd/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/package/network/services/uhttpd/Makefile > > b/package/network/services/uhttpd/Makefile > > index 3d483b692d..12896a1bb2 100644 > > --- a/package/network/services/uhttpd/Makefile > > +++ b/package/network/services/uhttpd/Makefile > > @@ -18,7 +18,7 @@ > > PKG_MIRROR_HASH:=2ac4ba8dc0b349d72174aac9ff693a73a214295a9890fe3d2a8eedcad54d06e > > PKG_MAINTAINER:=Felix Fietkau > > PKG_LICENSE:=ISC > > > > -PKG_BUILD_DEPENDS = ustream-ssl > > +PKG_BUILD_DEPENDS = libustream-mbedtls > > > > include $(INCLUDE_DIR)/package.mk > > include $(INCLUDE_DIR)/cmake.mk > > -- > > 2.13.1 > > > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Need for kernel/drivers/media tree
Hi Erik, have a look at video.mk which already packages some V4L2 modules. Most likely you'll only have to add a couple of lines to package the modules you need (supposedly dvb-core, some dvb-frontends and a USB device). Let me know if you need more help. Cheers Daniel On Fri, Jun 23, 2017 at 03:10:53PM +0200, Erik Adler wrote: > Hallo, > > i am working on "PCTV-Broadway" (ramips-RT3052-Hauppauge Broadway). > This device need driver for dvb devices on usb, this is contained in the > kernel. > Can you help and make a "media.mk" in the lede-source-tree in the > "/package/linux/modules" directory? > > MfG > > Erik Adler (Igel) > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Fw: Faulty in video.mk?
There is nothing wrong there. Kernel modules move location from time to time and we support different kernel versions within the same build tree. Hence we got some logic to easily express whether and where a module exists. in this case "@ge4.4" means "if kernel version is _g_reater than or _e_qual to 4.4" This could use some cleanup as we don't have any targets using kernels older than 4.4 left anyway... On Mon, Jun 26, 2017 at 07:04:50AM +0200, Erik Adler wrote: > The attachment is a .gif ... Sorry. > > > Gesendet: Montag, 26. Juni 2017 um 07:02 Uhr > > Von: "Erik Adler" > > An: lede-dev@lists.infradead.org > > Betreff: Faulty in video.mk? > > > > Hai ;-), > > > > is this correct? - See the attachment. > > > > The file is: > > > > https://github.com/lede-project/source/blob/master/package/kernel/linux/modules/video.mk > > > > MfG > > > > Erik Adler > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] fstools fixes backport to lede-17.01
Hi!
I'm about to push a lede-17.01 branch for fstools. These are the
changes I'd pick from the master branch:
f038a61 libfstools: fix matching device name
c43ae11 fstools: use -Wno-format-truncation instead of
-Wno-error=format-truncation
633a8d0 libfstools: fix multiple volume_identify usages with the same volume
a19f2b3 build: disable the format-truncation warning error to fix gcc 7 build
errors
88d48d5 libfstools: silence mkfs.{ext4,f2fs}
92b4c2c libfstools: add basic documentation of mount functions
7d78836 add missing includes
I'd skip the new mountd/autofs support which was added after the 17.01
release:
20c16fc cmake: Make blockd link against libjson-c
98bbb5a blockd: add automounting support
Please comment within the next 7 days, silence will be taken as passive
agreement.
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] block: support /dev/xvd* nodes
On Wed, Jul 12, 2017 at 07:14:04AM -0400, W. Michael Petullo wrote:
> From bc848f9f3d0ffb9aa114c7faa3916f059f5616b2 Mon Sep 17 00:00:00 2001
> From: "W. Michael Petullo"
> Date: Wed, 12 Jul 2017 07:02:18 -0400
> Subject: [PATCH] block: support /dev/xvd* nodes
> To: LEDE Development List
>
> Xen provides paravirtualized block devices which most often appear as
> /dev/xvd*. This patch adds this pattern to those known to the block
> utilitiy. These devices require a kernel compiled with the xen-blkfront
> driver.
Having a closer look I just noticed that there are no XEN options set
for x86/64 kernel. Maybe this should be changed, or is the the x86/64
subtarget useful as a Xen domU right now?
If not, it'd be great if you can test and suggest the necessary config
changes to achieve this as well.
>
> Signed-off-by: W. Michael Petullo
> ---
> block.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/block.c b/block.c
> index d5c3937..3e4cfb5 100644
> --- a/block.c
> +++ b/block.c
> @@ -530,6 +530,7 @@ static void cache_load(int mtd)
> _cache_load("/dev/hd*");
> _cache_load("/dev/md*");
> _cache_load("/dev/vd*");
> + _cache_load("/dev/xvd*");
> _cache_load("/dev/mapper/*");
> }
>
> --
> 2.13.0
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/4] x86: Drop stray subtarget "epia"
On Sat, Jul 15, 2017 at 06:47:58PM +0200, Baptiste Jonglez wrote: > From: Baptiste Jonglez > > This subtarget was added by 961c0eac, probably by mistake. It does > not contain anything beside a kernel config. Ouh, sorry, that was indeed committed by mistake (unless there is any unexpected public interest in having a VIA EPIA sepecific sub-target, I think it's safe to assume there isn't). Acked-by: Daniel Golle > > Cc: Daniel Golle > Signed-off-by: Baptiste Jonglez > --- > target/linux/x86/epia/config-4.4 | 213 > --- > 1 file changed, 213 deletions(-) > delete mode 100644 target/linux/x86/epia/config-4.4 > > diff --git a/target/linux/x86/epia/config-4.4 > b/target/linux/x86/epia/config-4.4 > deleted file mode 100644 > index a9bcd2af15..00 > --- a/target/linux/x86/epia/config-4.4 > +++ /dev/null > @@ -1,213 +0,0 @@ > -# CONFIG_3C515 is not set > -CONFIG_ACPI=y > -CONFIG_ACPI_AC=y > -CONFIG_ACPI_BATTERY=y > -CONFIG_ACPI_BUTTON=y > -# CONFIG_ACPI_CMPC is not set > -# CONFIG_ACPI_CONTAINER is not set > -# CONFIG_ACPI_CUSTOM_DSDT is not set > -# CONFIG_ACPI_DEBUG is not set > -# CONFIG_ACPI_DOCK is not set > -# CONFIG_ACPI_EC_DEBUGFS is not set > -# CONFIG_ACPI_FAN is not set > -# CONFIG_ACPI_I2C_OPREGION is not set > -# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set > -CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y > -# CONFIG_ACPI_PCI_SLOT is not set > -CONFIG_ACPI_PROCESSOR=y > -# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set > -# CONFIG_ACPI_PROCFS_POWER is not set > -# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set > -# CONFIG_ACPI_SBS is not set > -CONFIG_ACPI_THERMAL=y > -CONFIG_ACPI_VIDEO=y > -# CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -# CONFIG_AGP_INTEL is not set > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -CONFIG_AGP_VIA=y > -# CONFIG_APPLE_GMUX is not set > -CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y > -# CONFIG_ASUS_LAPTOP is not set > -# CONFIG_BACKLIGHT_ADP8860 is not set > -# CONFIG_BACKLIGHT_ADP8870 is not set > -# CONFIG_BACKLIGHT_APPLE is not set > -CONFIG_BACKLIGHT_CLASS_DEVICE=y > -CONFIG_BACKLIGHT_GENERIC=y > -CONFIG_BACKLIGHT_LCD_SUPPORT=y > -# CONFIG_BACKLIGHT_SAHARA is not set > -CONFIG_BLK_DEV_SR=y > -# CONFIG_BLK_DEV_SR_VENDOR is not set > -CONFIG_CC_OPTIMIZE_FOR_SIZE=y > -CONFIG_CPU_IDLE_GOV_MENU=y > -# CONFIG_DELL_SMO8800 is not set > -CONFIG_DMA_SHARED_BUFFER=y > -CONFIG_DMI=y > -# CONFIG_DMIID is not set > -CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y > -# CONFIG_DMI_SYSFS is not set > -CONFIG_DRM=y > -# CONFIG_DRM_AST is not set > -CONFIG_DRM_BOCHS=y > -# CONFIG_DRM_CIRRUS_QEMU is not set > -# CONFIG_DRM_GMA500 is not set > -# CONFIG_DRM_I2C_CH7006 is not set > -# CONFIG_DRM_I2C_NXP_TDA998X is not set > -# CONFIG_DRM_I2C_SIL164 is not set > -# CONFIG_DRM_I810 is not set > -# CONFIG_DRM_I915 is not set > -# CONFIG_DRM_I915_FBDEV is not set > -# CONFIG_DRM_I915_KMS is not set > -# CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set > -CONFIG_DRM_KMS_FB_HELPER=y > -CONFIG_DRM_KMS_HELPER=y > -# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set > -# CONFIG_DRM_MGA is not set > -# CONFIG_DRM_MGAG200 is not set > -# CONFIG_DRM_NOUVEAU is not set > -# CONFIG_DRM_PTN3460 is not set > -# CONFIG_DRM_QXL is not set > -# CONFIG_DRM_R128 is not set > -# CONFIG_DRM_RADEON is not set > -# CONFIG_DRM_SAVAGE is not set > -# CONFIG_DRM_SIS is not set > -# CONFIG_DRM_TDFX is not set > -# CONFIG_DRM_TTM is not set > -# CONFIG_DRM_UDL is not set > -CONFIG_DRM_VIA=y > -# CONFIG_DRM_VMWGFX is not set > -# CONFIG_EFI is not set > -# CONFIG_EISA is not set > -# CONFIG_EL3 is not set > -CONFIG_FB=y > -CONFIG_FB_CFB_COPYAREA=y > -CONFIG_FB_CFB_FILLRECT=y > -CONFIG_FB_CFB_IMAGEBLIT=y > -CONFIG_FB_CMDLINE=y > -# CONFIG_FB_I810 is not set > -CONFIG_FB_SYS_COPYAREA=y > -CONFIG_FB_SYS_FILLRECT=y > -CONFIG_FB_SYS_IMAGEBLIT=y > -# CONFIG_FB_VESA is not set > -CONFIG_FB_VIA=y > -# CONFIG_FB_VIA_DIRECT_PROCFS is not set > -CONFIG_FB_VIA_X_COMPATIBILITY=y > -# CONFIG_FONTS is not set > -CONFIG_FONT_8x16=y > -CONFIG_FONT_8x8=y > -CONFIG_FONT_SUPPORT=y > -CONFIG_FRAMEBUFFER_CONSOLE=y > -CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y > -# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set > -# CONFIG_FUJITSU_LAPTOP is not set > -# CONFIG_GEOS is not set > -CONFIG_GPIO_GENERIC_PLATFORM=y > -# CONFIG_GPIO_F7188X is not set > -CONFIG_GPIO_VX855=y > -# CONFIG_GPI
Re: [LEDE-DEV] [PATCH] hostapd: set mcast_rate in mesh mode
On Thu, May 11, 2017 at 08:56:50AM +0200, Sven Eckelmann wrote:
> From: Sven Eckelmann
>
> The wpa_supplicant code for IBSS allows to set the mcast rate. It is
> recommended to increase this value from 1 or 6 Mbit/s to something higher
> when using a mesh protocol on top which uses the multicast packet loss as
> indicator for the link quality.
>
> This setting was unfortunately not applied for mesh mode. But it would be
> beneficial when wpa_supplicant would behave similar to IBSS mode and set
> this argument during mesh join like authsae already does. At least it is
> helpful for companies/projects which are currently switching to 802.11s
> (without mesh_fwding and with mesh_ttl set to 1) as replacement for IBSS
> because newer drivers seem to support 802.11s but not IBSS anymore.
I do think this is needed, however, also note that 802.11s doesn't do
legacy CCK rates by spec. Hence the lowest possible rate is 6 Mbit/s
also on 2.4 GHz (and has always been 6 MBit/s for 5 GHz).
everyone: Should we merge this patch now?
>
> Signed-off-by: Sven Eckelmann
> Tested-by: Simon Wunderlich
> ---
> .../patches/463-add-mcast_rate-to-11s.patch| 68
> ++
> 1 file changed, 68 insertions(+)
> create mode 100644
> package/network/services/hostapd/patches/463-add-mcast_rate-to-11s.patch
>
> diff --git
> a/package/network/services/hostapd/patches/463-add-mcast_rate-to-11s.patch
> b/package/network/services/hostapd/patches/463-add-mcast_rate-to-11s.patch
> new file mode 100644
> index 00..9cf9d51ff7
> --- /dev/null
> +++ b/package/network/services/hostapd/patches/463-add-mcast_rate-to-11s.patch
> @@ -0,0 +1,68 @@
> +From: Sven Eckelmann
> +Date: Thu, 11 May 2017 08:21:45 +0200
> +Subject: [PATCH] set mcast_rate in mesh mode
> +
> +The wpa_supplicant code for IBSS allows to set the mcast rate. It is
> +recommended to increase this value from 1 or 6 Mbit/s to something higher
> +when using a mesh protocol on top which uses the multicast packet loss as
> +indicator for the link quality.
> +
> +This setting was unfortunately not applied for mesh mode. But it would be
> +beneficial when wpa_supplicant would behave similar to IBSS mode and set
> +this argument during mesh join like authsae already does. At least it is
> +helpful for companies/projects which are currently switching to 802.11s
> +(without mesh_fwding and with mesh_ttl set to 1) as replacement for IBSS
> +because newer drivers seem to support 802.11s but not IBSS anymore.
> +
> +Signed-off-by: Sven Eckelmann
> +Tested-by: Simon Wunderlich
> +
> +--- a/src/drivers/driver.h
> b/src/drivers/driver.h
> +@@ -1230,6 +1230,7 @@ struct wpa_driver_mesh_join_params {
> + #define WPA_DRIVER_MESH_FLAG_SAE_AUTH 0x0004
> + #define WPA_DRIVER_MESH_FLAG_AMPE 0x0008
> + unsigned int flags;
> ++int mcast_rate;
> + };
> +
> + /**
> +--- a/src/drivers/driver_nl80211.c
> b/src/drivers/driver_nl80211.c
> +@@ -8764,6 +8764,18 @@ static int nl80211_put_mesh_id(struct nl
> + }
> +
> +
> ++static int nl80211_put_mcast_rate(struct nl_msg *msg, int mcast_rate)
> ++{
> ++if (mcast_rate > 0) {
> ++wpa_printf(MSG_DEBUG, " * mcast_rate=%.1f",
> ++ (double)mcast_rate / 10);
> ++return nla_put_u32(msg, NL80211_ATTR_MCAST_RATE, mcast_rate);
> ++}
> ++
> ++return 0;
> ++}
> ++
> ++
> + static int nl80211_put_mesh_config(struct nl_msg *msg,
> +struct wpa_driver_mesh_bss_params *params)
> + {
> +@@ -8819,6 +8831,7 @@ static int nl80211_join_mesh(struct i802
> + nl80211_put_basic_rates(msg, params->basic_rates) ||
> + nl80211_put_mesh_id(msg, params->meshid, params->meshid_len) ||
> + nl80211_put_beacon_int(msg, params->beacon_int) ||
> ++nl80211_put_mcast_rate(msg, params->mcast_rate) ||
> + nl80211_put_dtim_period(msg, params->dtim_period))
> + goto fail;
> +
> +--- a/wpa_supplicant/mesh.c
> b/wpa_supplicant/mesh.c
> +@@ -380,6 +380,7 @@ int wpa_supplicant_join_mesh(struct wpa_
> + os_memset(¶ms, 0, sizeof(params));
> + params.meshid = ssid->ssid;
> + params.meshid_len = ssid->ssid_len;
> ++params.mcast_rate = ssid->mcast_rate;
> + ibss_mesh_setup_freq(wpa_s, ssid, ¶ms.freq);
> + wpa_s->mesh_ht_enabled = !!params.freq.ht_enabled;
> + wpa_s->mesh_vht_enabled = !!params.freq.vht_enabled;
> --
> 2.11.0
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Opkg: add --no-configure option patch.
Hi everyone! On Sat, Feb 18, 2017 at 08:10:22AM +, Kevin Darbyshire-Bryant wrote: > > On 18 Feb 2017, at 00:06, daniel wrote: > > > > And I also do not want opkg to invoke the init scripts of the just upgraded > > packages until I have finished all my checks and stuff. > > > > I thought it might be useful for others too, if opkg has this option that > > let > > you control the upgrade process a bit more. > > I think this is a useful tweak for very little code increase. I was > working on my own patches for dnsmasq the other day and found the > opkg install 'copying & auto starting' behaviour annoying as it > (initially) confused my testing. I bumped into this submission while browsing through patchwork and it partially solves another problem I have: The need to generate images using the ImageBuilder which do have certain packages installed with their init scripts being disabled (uci-defaults and the rest of default-postinst should be processed in that cause though)... I went on and simply set an environment variable which can be checked for in the postinst script which inherits it. In that way I didn't need to patch opkg. Could such a solution be helpful to you as well? Because if so, that would simply be a matter of convention, similar to PKG_UPGRADE (see package/base-files/files/lib/functions.sh) > > > > > What do you think ? > >> On 02/17/2017 06:17 AM, Jonas Gorski wrote: > >> Hi, > >> > >>> On 16 February 2017 at 02:14, Daniel Danzberger wrote: > >>> Calling opkg with --no-configure prevents opkg > >>> from running the configuration of the package (postinstall scripts ..etc) > >>> > >>> This way opkg will only install the package, without restarting the > >>> service for example. > >> > >> What's the use case for this? When would I want to do that? > >> > >>> Signed-off-by: Daniel Danzberger > >> > >> > >> Regards > >> Jonas > >> > > > > -- > > Regards > > > > Daniel Danzberger > > embeDD GmbH, Breitenweg 10, CH-6370 Stans > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] busybox: move traceroute applets to /bin
busybox currently installs traceroute and traceroute6 into /usr/bin which prevents their 'full' iputils variants from being installed. Move those applets to /bin so they can coexist with their iputils siblings using the same PATH convention already applied for coreutils and other drop-in 'full' versions. Refresh existing patch while at it. Signed-off-by: Daniel Golle --- package/utils/busybox/patches/230-add_nslookup_lede.patch | 8 .../patches/500-move-traceroute-applets-to-bin.patch| 13 + 2 files changed, 13 insertions(+), 8 deletions(-) create mode 100644 package/utils/busybox/patches/500-move-traceroute-applets-to-bin.patch diff --git a/package/utils/busybox/patches/230-add_nslookup_lede.patch b/package/utils/busybox/patches/230-add_nslookup_lede.patch index 976960cf1a..e394dfb9b9 100644 --- a/package/utils/busybox/patches/230-add_nslookup_lede.patch +++ b/package/utils/busybox/patches/230-add_nslookup_lede.patch @@ -17,8 +17,6 @@ Signed-off-by: Jo-Philipp Wich 2 files changed, 921 insertions(+) create mode 100644 networking/nslookup_lede.c -diff --git a/Makefile.flags b/Makefile.flags -index 65021de25..096ab7756 100644 --- a/Makefile.flags +++ b/Makefile.flags @@ -134,6 +134,12 @@ else @@ -34,9 +32,6 @@ index 65021de25..096ab7756 100644 # libpam may use libpthread, libdl and/or libaudit. # On some platforms that requires an explicit -lpthread, -ldl, -laudit. # However, on *other platforms* it fails when some of those flags -diff --git a/networking/nslookup_lede.c b/networking/nslookup_lede.c -new file mode 100644 -index 0..c6c90ddf3 --- /dev/null +++ b/networking/nslookup_lede.c @@ -0,0 +1,915 @@ @@ -955,6 +950,3 @@ index 0..c6c90ddf3 + + return rc; +} --- -2.11.0 - diff --git a/package/utils/busybox/patches/500-move-traceroute-applets-to-bin.patch b/package/utils/busybox/patches/500-move-traceroute-applets-to-bin.patch new file mode 100644 index 00..7fa06a68c7 --- /dev/null +++ b/package/utils/busybox/patches/500-move-traceroute-applets-to-bin.patch @@ -0,0 +1,13 @@ +--- a/networking/traceroute.c b/networking/traceroute.c +@@ -239,8 +239,8 @@ + //config: Add option -I to use ICMP ECHO instead of UDP datagrams. + + /* Needs socket(AF_INET, SOCK_RAW, IPPROTO_ICMP), therefore BB_SUID_MAYBE: */ +-//applet:IF_TRACEROUTE(APPLET(traceroute, BB_DIR_USR_BIN, BB_SUID_MAYBE)) +-//applet:IF_TRACEROUTE6(APPLET(traceroute6, BB_DIR_USR_BIN, BB_SUID_MAYBE)) ++//applet:IF_TRACEROUTE(APPLET(traceroute, BB_DIR_BIN, BB_SUID_MAYBE)) ++//applet:IF_TRACEROUTE6(APPLET(traceroute6, BB_DIR_BIN, BB_SUID_MAYBE)) + + //kbuild:lib-$(CONFIG_TRACEROUTE) += traceroute.o + //kbuild:lib-$(CONFIG_TRACEROUTE6) += traceroute.o -- 2.13.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] busybox: move passwd applet to /bin
busybox currently installs passwd into /usr/bin which prevents its
'full' shadow-utils variant from being installed.
Move the passwd applet to /bin to avoid that collision.
shadow also provides /usr/bin/login which doesn't collide with busybox
as the busybox login applet is installed at /bin/login.
Signed-off-by: Daniel Golle
---
.../utils/busybox/patches/510-move-passwd-applet-to-bin.patch | 11 +++
1 file changed, 11 insertions(+)
create mode 100644
package/utils/busybox/patches/510-move-passwd-applet-to-bin.patch
diff --git a/package/utils/busybox/patches/510-move-passwd-applet-to-bin.patch
b/package/utils/busybox/patches/510-move-passwd-applet-to-bin.patch
new file mode 100644
index 00..b19d1c9a39
--- /dev/null
+++ b/package/utils/busybox/patches/510-move-passwd-applet-to-bin.patch
@@ -0,0 +1,11 @@
+--- a/loginutils/passwd.c
b/loginutils/passwd.c
+@@ -23,7 +23,7 @@
+ //config: With this option passwd will refuse new passwords which are
"weak".
+
+ //applet:/* Needs to be run by root or be suid root - needs to change
/etc/{passwd,shadow}: */
+-//applet:IF_PASSWD(APPLET(passwd, BB_DIR_USR_BIN, BB_SUID_REQUIRE))
++//applet:IF_PASSWD(APPLET(passwd, BB_DIR_BIN, BB_SUID_REQUIRE))
+
+ //kbuild:lib-$(CONFIG_PASSWD) += passwd.o
+
--
2.13.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] boot error on dwr-921 (mt7620n)
Hi Giuseppe,
On Sun, Jul 30, 2017 at 09:26:15PM +0200, Giuseppe Lippolis wrote:
> Dear community,
> I'm trying to port openwrt/lede on the dlink dwr921 (mt7620n arch).
>
> Currently I get a kernel panic after the OS fail to find the wmac eeprom
> location.
> At the moment I use in the dts something clearly wrong:
> ðernet {
> mtd-mac-address = <&config 0xe2ac>;
> mediatek,portmap = "w";
> };
>
> &wmac {
> ralink,mtd-eeprom = <&config 0xe000>;
> };
>
> I'm quite sure the wmac eeprom is located in the "config" flash partition.
> What shall I search to find the proper address of the required section?
Look for the word 0x7620 at an even offset, that's the start of the
EEPROM.
> Here the complete bootlog:
> ...
You are on the right spot, the log confirms that the eeprom partition
or offset is certainly wrong.
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] rt2x00: port remaining patches for mac80211 from 4.13-rc6
Convert patches for RT3883 and RT3663 as well as support for external PA on MT7620 to use the changed calling convention for rt2.*_read(...) functions. Signed-off-by: Daniel Golle --- ...rt2800lib-add-channel-configuration-function-.patch | 18 +- ...rt2800lib-add-RFCSR-initialization-for-RT3883.patch | 12 ++-- ...rt2800mmio-add-a-workaround-for-spurious-TX_F.patch | 2 +- ...-rt2x00-add-support-for-external-PA-on-MT7620.patch | 6 +++--- 4 files changed, 19 insertions(+), 19 deletions(-) diff --git a/package/kernel/mac80211/patches/600-05-rt2x00-rt2800lib-add-channel-configuration-function-.patch b/package/kernel/mac80211/patches/600-05-rt2x00-rt2800lib-add-channel-configuration-function-.patch index 890ae8a1db..1d6e312037 100644 --- a/package/kernel/mac80211/patches/600-05-rt2x00-rt2800lib-add-channel-configuration-function-.patch +++ b/package/kernel/mac80211/patches/600-05-rt2x00-rt2800lib-add-channel-configuration-function-.patch @@ -50,7 +50,7 @@ Signed-off-by: Gabor Juhos + + rt2800_rfcsr_write(rt2x00dev, 13, 0x12); + -+ rt2800_rfcsr_read(rt2x00dev, 1, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 1); + rt2x00_set_field8(&rfcsr, RFCSR1_RX0_PD, 0); + rt2x00_set_field8(&rfcsr, RFCSR1_TX0_PD, 0); + rt2x00_set_field8(&rfcsr, RFCSR1_RX1_PD, 0); @@ -87,7 +87,7 @@ Signed-off-by: Gabor Juhos + + rt2800_freq_cal_mode1(rt2x00dev); + -+ rt2800_rfcsr_read(rt2x00dev, 30, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 30); + if (!conf_is_ht40(conf)) + rfcsr &= ~(0x06); + else @@ -110,7 +110,7 @@ Signed-off-by: Gabor Juhos + rt2800_rfcsr_write(rt2x00dev, 34, 0x20); + + /* loopback RF_BS */ -+ rt2800_rfcsr_read(rt2x00dev, 36, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 36); + if (rf->channel <= 14) + rt2x00_set_field8(&rfcsr, RFCSR36_RF_BS, 1); + else @@ -158,13 +158,13 @@ Signed-off-by: Gabor Juhos + + rt2800_rfcsr_write(rt2x00dev, 50, 0x86); + -+ rt2800_rfcsr_read(rt2x00dev, 51, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 51); + if (rf->channel <= 14) + rt2800_rfcsr_write(rt2x00dev, 51, 0x75); + else + rt2800_rfcsr_write(rt2x00dev, 51, 0x51); + -+ rt2800_rfcsr_read(rt2x00dev, 52, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 52); + if (rf->channel <= 14) + rt2800_rfcsr_write(rt2x00dev, 52, 0x45); + else @@ -194,25 +194,25 @@ Signed-off-by: Gabor Juhos +((info->default_power2 & 0xe0) >> 1); + rt2800_bbp_write(rt2x00dev, 109, bbp); + -+ rt2800_bbp_read(rt2x00dev, 110, &bbp); ++ bbp = rt2800_bbp_read(rt2x00dev, 110); + bbp &= 0x0f; + bbp |= (info->default_power3 & 0xe0) >> 1; + rt2800_bbp_write(rt2x00dev, 110, bbp); + -+ rt2800_rfcsr_read(rt2x00dev, 57, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 57); + if (rf->channel <= 14) + rt2800_rfcsr_write(rt2x00dev, 57, 0x6e); + else + rt2800_rfcsr_write(rt2x00dev, 57, 0x3e); + + /* Enable RF tuning */ -+ rt2800_rfcsr_read(rt2x00dev, 3, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 3); + rt2x00_set_field8(&rfcsr, RFCSR3_VCOCAL_EN, 1); + rt2800_rfcsr_write(rt2x00dev, 3, rfcsr); + + udelay(2000); + -+ rt2800_bbp_read(rt2x00dev, 49, &bbp); ++ bbp = rt2800_bbp_read(rt2x00dev, 49); + /* clear update flag */ + rt2800_bbp_write(rt2x00dev, 49, bbp & 0xfe); + rt2800_bbp_write(rt2x00dev, 49, bbp); diff --git a/package/kernel/mac80211/patches/600-10-rt2x00-rt2800lib-add-RFCSR-initialization-for-RT3883.patch b/package/kernel/mac80211/patches/600-10-rt2x00-rt2800lib-add-RFCSR-initialization-for-RT3883.patch index a4967c6474..a542c35327 100644 --- a/package/kernel/mac80211/patches/600-10-rt2x00-rt2800lib-add-RFCSR-initialization-for-RT3883.patch +++ b/package/kernel/mac80211/patches/600-10-rt2x00-rt2800lib-add-RFCSR-initialization-for-RT3883.patch @@ -134,7 +134,7 @@ Signed-off-by: Gabor Juhos + rt2800_rfcsr_write(rt2x00dev, 33, 0x32); + } + -+ rt2800_rfcsr_read(rt2x00dev, 2, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 2); + rt2x00_set_field8(&rfcsr, RFCSR2_RESCAL_BP, 0); + rt2x00_set_field8(&rfcsr, RFCSR2_RESCAL_EN, 1); + rt2800_rfcsr_write(rt2x00dev, 2, rfcsr); @@ -142,23 +142,23 @@ Signed-off-by: Gabor Juhos + rt2x00_set_field8(&rfcsr, RFCSR2_RESCAL_EN, 0); + rt2800_rfcsr_write(rt2x00dev, 2, rfcsr); + -+ rt2800_rfcsr_read(rt2x00dev, 1, &rfcsr); ++ rfcsr = rt2800_rfcsr_read(rt2x00dev, 1); + rt2x00_set_field8(&rfcsr, RFCSR1_RF_BLOCK_EN, 1); + rt2800_rfcsr_write(rt2x00dev, 1, rfcsr); + -+
Re: [LEDE-DEV] RFC [PATCH] odhcpd: don't enable server mode on dhcp lan
Hi Karl, On Thu, Aug 31, 2017 at 05:17:38PM +, Karl Palsson wrote: > Instead of blindly enabling the odhcpd v6 server and RA server on the > lan port, only do that if the lan port isn't set to DHCP. > > This prevents the unhelpful case of a device being a dhcpv4 client and > v6 server on the same ethernet port. Generating UCI from presumingly already generated UCI has proven to be a bad practise in the past. See inline for an alternative approach. > > Signed-off-by: Karl Palsson > -- > > Should other protocols be excluded? The list on > https://lede-project.org/docs/user-guide/network_configuration > is rather long. Are there other modes worth considering? > > --- > package/network/services/odhcpd/files/odhcpd.defaults | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/package/network/services/odhcpd/files/odhcpd.defaults > b/package/network/services/odhcpd/files/odhcpd.defaults > index e184da90acbb..152e63dd18b6 100644 > --- a/package/network/services/odhcpd/files/odhcpd.defaults > +++ b/package/network/services/odhcpd/files/odhcpd.defaults > @@ -2,13 +2,23 @@ > uci -q get dhcp.odhcpd && exit 0 > touch /etc/config/dhcp > > +LANPROTO=$(uci -q get network.lan.proto) Imho it'd be nicer to read this via ``` . /usr/share/libubox/jshn.sh json_load "$(cat /etc/board.json)" json_select network json_select lan json_get_vars protocol json_select .. json_select .. ``` > +MODE=server > + > +case "$LANPROTO" in > +"dhcp") > + echo "odhcpd: Not enabling server mode on a dhcp lan!" > /dev/kmsg > + MODE=disabled > + ;; > +esac > + > uci batch < set dhcp.odhcpd=odhcpd > set dhcp.odhcpd.maindhcp=0 > set dhcp.odhcpd.leasefile=/tmp/hosts/odhcpd > set dhcp.odhcpd.leasetrigger=/usr/sbin/odhcpd-update > set dhcp.odhcpd.loglevel=4 > -set dhcp.lan.dhcpv6=server > -set dhcp.lan.ra=server > +set dhcp.lan.dhcpv6=$MODE > +set dhcp.lan.ra=$MODE > commit dhcp > EOF > -- > 2.4.11 > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] rt2x00: port remaining patches for mac80211 from 4.13-rc6
Hi Hauke, On Thu, Sep 14, 2017 at 12:02:21AM +0200, Hauke Mehrtens wrote: > On 08/25/2017 12:02 AM, Daniel Golle wrote: > > Convert patches for RT3883 and RT3663 as well as support for > > external PA on MT7620 to use the changed calling convention for > > rt2.*_read(...) functions. > > > > Signed-off-by: Daniel Golle > > --- > > ...rt2800lib-add-channel-configuration-function-.patch | 18 > > +- > > ...rt2800lib-add-RFCSR-initialization-for-RT3883.patch | 12 ++-- > > ...rt2800mmio-add-a-workaround-for-spurious-TX_F.patch | 2 +- > > ...-rt2x00-add-support-for-external-PA-on-MT7620.patch | 6 +++--- > > 4 files changed, 19 insertions(+), 19 deletions(-) > > Hi Daniel, > > I already integrated these fixes in the version I send to the mailing list. I realized that shortly after... After having run builds based on your staging tree on several targets I'd say to give it a shot, afaik there haven't been any significant changes up to the point that v4.13 was released, so it can hit the LEDE tree based on v4.13. Thanks for the great work! Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Update to util-linux 2.30.1 breaks x86_64 squashfs-combined
On Fri, Sep 29, 2017 at 12:20:08PM +0200, Felix Fietkau wrote: > On 2017-09-11 02:33, Philip Prindeville wrote: > > Changing the subject from the previous thread as it turned out to not have > > to do with sysupgrade at all. > > > > What I can tell is this, having added some tracing to fstools. > > > > We get to the call to system() in rootdisk_volume_init(): > > > > https://git.lede-project.org/?p=project/fstools.git;a=blob;f=libfstools/rootdisk.c;h=dd00c1b4e5b4aa9b748610fa3e93d301a67101a7;hb=HEAD#l269 > > > > and it never seems to return. The value of “str” is “mkfs.f2fs -q -l > > rootfs_data /dev/loop0”. > > > > What would cause this to hang rather than return an error? > I've used sysrq to trace this and found out that it's hanging in the > getrandom system call, which could be used through util-linux library > code. That also explains why the update broke it. > > I will prepare a patch that forces util-linux to stick to /dev/urandom > instead - that should hopefully fix this for good. mkfs.f2fs also uses getrandom(3) and hangs there for some minutes when creating the initial snapshot... ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] revisited: Nanostation m5 XW ethernet patch gone
Hi Felix! Hi everyone! It looks like Tiziano is right and this patch did get lost somehow. At least I can't find any work-arounds regarding PHY hangs committed in neither target/linux/generic/files/* nor target/linux/ar71xx/files/*. The thread on lede-dev also seems to have stagnated after http://lists.infradead.org/pipermail/lede-dev/2016-December/004406.html Felix, you said you had a more clean patch for this in your staging tree? I'm asking because I might have just hit that bug once again on UBNT-NM-XW, ie. uid=004dd043, driver=Atheros AR8216/AR8236/AR8316... Anyone? I've also had a lot of problems with that bug on XW hardware and have since simply tried to avoid it (the hardware). Now that also non-loco NanoStations are only available in their XW-version I'd be happy to finally have a reliable work-around for that hardware problem. Cheers Daniel - Forwarded message from Tiziano Bacocco - Date: Mon, 6 Feb 2017 16:34:24 +0100 From: Tiziano Bacocco To: openwrt-de...@lists.openwrt.org Subject: [OpenWrt-Devel] Nanostation m5 XW ethernet patch gone Hello everyone Could this patch http://gerrit.aredn.org/#/c/57 be merged in trunk? I've just tested it with trunk and it works properly on my nanostation loco m5 xw , the PHY chip is correctly reset every like 8 hours or so and no connectivity loss since then Bug report: https://dev.openwrt.org/ticket/19085 System log after applying patch Sun Feb 5 23:40:02 2017 kern.info kernel: [716206.656361] br-lan: port 1(eth0) entered forwarding state Sun Feb 5 23:40:02 2017 daemon.notice netifd: Network device 'eth0' link is up Sun Feb 5 23:40:04 2017 kern.info kernel: [716208.654021] br-lan: port 1(eth0) entered forwarding state Mon Feb 6 05:05:21 2017 kern.info kernel: [735725.556613] ag71xx_check_reset: expected: 004d, got: Mon Feb 6 05:05:21 2017 kern.info kernel: [735725.562190] ag71xx_gpio_reset triggered Mon Feb 6 05:05:21 2017 kern.info kernel: [735725.571328] eth0: link down Mon Feb 6 05:05:21 2017 daemon.notice netifd: Network device 'eth0' link is down Mon Feb 6 05:05:21 2017 kern.info kernel: [735725.574702] br-lan: port 1(eth0) entered disabled state Mon Feb 6 05:05:23 2017 kern.info kernel: [735727.567752] eth0: link up (100Mbps/Full duplex) Mon Feb 6 05:05:23 2017 kern.info kernel: [735727.572533] br-lan: port 1(eth0) entered forwarding state Mon Feb 6 05:05:23 2017 kern.info kernel: [735727.578224] br-lan: port 1(eth0) entered forwarding state Mon Feb 6 05:05:23 2017 daemon.notice netifd: Network device 'eth0' link is up I'm not commenting to the bug report because i' both unable to register and to comment because trac complains that i'm spamming, my ip address range is 89.202.181.128 - 89.202.181.143 ___ openwrt-devel mailing list openwrt-de...@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel - End forwarded message - ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] merge: add OpenWrt branding
On Tue, Oct 24, 2017 at 03:07:04PM +0200, Jo-Philipp Wich wrote: > Hi, > > comments inline. > > > Signed-off-by: Imre Kaloz > > Given the fact that we explicitely wanted to avoid @openwrt.org mails > and that this was one of the discussion points leading to the split I > find it delicate to seal the merging commit with exactly such a S-o-b. > > Combined with ... > > $ git log --author "Imre Kaloz " --format=%cD -1 > Tue, 18 Oct 2016 11:42:06 +0200 > > ... this looks to me like nothing was learned from past experiences and > that all that matters here is having the own name attached to the work > being done. I agree. Despite the domain name being handed over it still looks like the openwrt.org infrastructure is the hands of a single person, which was the precise cause for the fork... What about handing this AS over to the SPI as well? Or at least have several admin-c registered? (I'm aware that this might not be the best moment to discuss this, we all could have thought about that a bit earlier...) [daniel@box ~]$ host -t MX openwrt.org openwrt.org mail is handled by 10 mail.openwrt.org. [daniel@box ~]$ host mail.openwrt.org. mail.openwrt.org has address 78.24.191.176 [daniel@box ~]$ whois 78.24.191.176 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '78.24.191.176 - 78.24.191.191' % Abuse contact for '78.24.191.176 - 78.24.191.191' is 'ab...@atw.co.hu' inetnum:78.24.191.176 - 78.24.191.191 netname:HU-ATW-OPENWRT descr: OpenWrt project country:HU admin-c:BIK4-RIPE tech-c: BIK4-RIPE mnt-by: MNT-ATW status: ASSIGNED PA created:2009-06-17T08:51:36Z last-modified: 2009-06-17T08:51:36Z source: RIPE # Filtered person: Bertalan Imre Kaloz address:Berkocsis utca 18. address:H-1084 Budapest address:Hungary phone: +36 70 3136791 nic-hdl:BIK4-RIPE mnt-by: MNT-ATW created:2009-06-17T08:51:36Z last-modified: 2009-06-17T08:51:36Z source: RIPE % Information related to '78.24.188.0/22AS41075' route: 78.24.188.0/22 descr: ATW Internet Kft. descr: Budapest, Hungary origin: AS41075 mnt-by: MNT-ATW created:2014-12-03T11:50:32Z last-modified: 2014-12-03T11:50:32Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.90 (ANGUS) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH rpcd v2] sys: fix passwd path
Hi Roman,
On Sun, Nov 26, 2017 at 12:02:14PM +0200, Roman Yeryomin wrote:
> Changes from v1:
> - use pointer to reduce compile size
>
> Signed-off-by: Roman Yeryomin
> ---
> sys.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/sys.c b/sys.c
> index 40f49ca..122191b 100644
> --- a/sys.c
> +++ b/sys.c
> @@ -78,6 +78,7 @@ rpc_cgi_password_set(struct ubus_context *ctx, struct
> ubus_object *obj,
> struct blob_attr *tb[__RPC_P_MAX];
> ssize_t n;
> int ret;
> + char *passwd = "/bin/passwd";
'const' seems appropriate here.
>
> blobmsg_parse(rpc_password_policy, __RPC_P_MAX, tb,
> blob_data(msg), blob_len(msg));
> @@ -85,7 +86,7 @@ rpc_cgi_password_set(struct ubus_context *ctx, struct
> ubus_object *obj,
> if (!tb[RPC_P_USER] || !tb[RPC_P_PASSWORD])
> return UBUS_STATUS_INVALID_ARGUMENT;
>
> - if (stat("/usr/bin/passwd", &s))
> + if (stat(passwd, &s))
> return UBUS_STATUS_NOT_FOUND;
>
> if (!(s.st_mode & S_IXUSR))
> @@ -119,7 +120,7 @@ rpc_cgi_password_set(struct ubus_context *ctx, struct
> ubus_object *obj,
> if (ret < 0)
> return rpc_errno_status();
>
> - if (execl("/usr/bin/passwd", "/usr/bin/passwd",
> + if (execl(passwd, passwd,
> blobmsg_data(tb[RPC_P_USER]), NULL))
> return rpc_errno_status();
>
> --
> 2.11.0
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fixing of image file names
Hi Moritz,
thanks for stepping forward and adressing this issue.
It'd be good to include the two assertions added to your list beelow.
On Tue, Nov 28, 2017 at 07:05:23PM +0100, Moritz Warning wrote:
> Hi,
>
> I noticed that there are some image file names that do not follow the
> "common" name scheme.
> Is it ok to change it? I would like to submit a patch.
>
> Some examples:
> - all lower case image names
> - lede-ipq806x-EA8500-squashfs-sysupgrade.tar =>
> lede-ipq806x-ea8500-squashfs-sysupgrade.tar
> - revision between -
> - lede-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin =>
> lede-mvebu-linksys-wrt1900ac-v2-squashfs-sysupgrade.bin
> - region specific images with region identifiers (us, eu, il, ...)
> - lede-ramips-rt305x-wnce2001-squashfs-factory-northamerica.bin =>
> lede-ramips-rt305x-wnce2001-us-squashfs-factory.bin
> - separate images for each version
> - lede-brcm47xx-mips74k-linksys-e1000-v1-v2-v2.1-squashfs.bin =>
> lede-brcm47xx-mips74k-linksys-e1000-v1-squashfs.bin, ...
- board_name (in target userspace) == profile (in imagebuilder) == DTS name
- image_filename ==
${distro}-${target}-${subtarget}-${board_name}-${fstype}-${imgtype}
that would make identifying sysupgrade images much more straight
forward (and hence automatizable).
See also
https://github.com/aparcar/attendedsysupgrade-server/issues/80
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fixing of image file names
On Tue, Nov 28, 2017 at 08:16:33PM +0100, Moritz Warning wrote:
> Ok,
>
> looks like I should make a patch. :P
>
> On 11/28/2017 07:24 PM, Daniel Golle wrote:
> > Hi Moritz,
> >
> > thanks for stepping forward and adressing this issue.
> > It'd be good to include the two assertions added to your list beelow.
> >
> > On Tue, Nov 28, 2017 at 07:05:23PM +0100, Moritz Warning wrote:
> >> Hi,
> >>
> >> I noticed that there are some image file names that do not follow the
> >> "common" name scheme.
> >> Is it ok to change it? I would like to submit a patch.
> >>
> >> Some examples:
> >> - all lower case image names
> >> - lede-ipq806x-EA8500-squashfs-sysupgrade.tar =>
> >> lede-ipq806x-ea8500-squashfs-sysupgrade.tar
> >> - revision between -
> >> - lede-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin =>
> >> lede-mvebu-linksys-wrt1900ac-v2-squashfs-sysupgrade.bin
> >> - region specific images with region identifiers (us, eu, il, ...)
> >> - lede-ramips-rt305x-wnce2001-squashfs-factory-northamerica.bin =>
> >> lede-ramips-rt305x-wnce2001-us-squashfs-factory.bin
> >> - separate images for each version
> >> - lede-brcm47xx-mips74k-linksys-e1000-v1-v2-v2.1-squashfs.bin =>
> >> lede-brcm47xx-mips74k-linksys-e1000-v1-squashfs.bin, ...
> >
> > - board_name (in target userspace) == profile (in imagebuilder) == DTS name
> What is the target userspace and what does DTS mean?
`ubus call system board` contains the board_name
DTS name is the device-tree source filename, e.g.
`sun7i-a20-bananapi-m1-plus.dts`
Non-legacy (ie. device-tree-based) targets already partially enforce
this rule, but it's by no means consitent (yet)...
>
> >
> > - image_filename ==
> > ${distro}-${target}-${subtarget}-${board_name}-${fstype}-${imgtype}
> >
> > that would make identifying sysupgrade images much more straight
> > forward (and hence automatizable).
> >
> > See also
> > https://github.com/aparcar/attendedsysupgrade-server/issues/80
> >
> >
> > Cheers
> >
> >
> > Daniel
> >
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fixing of image file names
On Wed, Nov 29, 2017 at 09:33:39AM +0100, Mathias Kresin wrote:
> 28.11.2017 19:24, Daniel Golle:
> > Hi Moritz,
> >
> > thanks for stepping forward and adressing this issue.
> > It'd be good to include the two assertions added to your list beelow.
> >
> > On Tue, Nov 28, 2017 at 07:05:23PM +0100, Moritz Warning wrote:
> > > Hi,
> > >
> > > I noticed that there are some image file names that do not follow the
> > > "common" name scheme.
> > > Is it ok to change it? I would like to submit a patch.
> > >
> > > Some examples:
> > > - all lower case image names
> > >- lede-ipq806x-EA8500-squashfs-sysupgrade.tar =>
> > > lede-ipq806x-ea8500-squashfs-sysupgrade.tar
> > > - revision between -
> > >- lede-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin =>
> > > lede-mvebu-linksys-wrt1900ac-v2-squashfs-sysupgrade.bin
> > > - region specific images with region identifiers (us, eu, il, ...)
> > > - lede-ramips-rt305x-wnce2001-squashfs-factory-northamerica.bin =>
> > > lede-ramips-rt305x-wnce2001-us-squashfs-factory.bin
> > > - separate images for each version
> > >- lede-brcm47xx-mips74k-linksys-e1000-v1-v2-v2.1-squashfs.bin =>
> > > lede-brcm47xx-mips74k-linksys-e1000-v1-squashfs.bin, ...
> >
> > - board_name (in target userspace) == profile (in imagebuilder) == DTS
> > name
> >
> > - image_filename ==
> > ${distro}-${target}-${subtarget}-${board_name}-${fstype}-${imgtype}
> >
> > that would make identifying sysupgrade images much more straight
> > forward (and hence automatizable).
> >
> > See also
> > https://github.com/aparcar/attendedsysupgrade-server/issues/80
>
> I would like to propose something different which basically aims the same.
>
> 1. fix the compatible strings in the DTS files
> 2. use the compatible string from the DTS in userspace (boardname)
> 3. use the compatible string for the image filename (board_name in above
> example)
There was only board_name (with underscore), no boardname (without
underscore) in the example... (?)
>
> The DTS compatible string is supposed to be unique across the whole kernel
> and this way we can prevent duplicates in big targets like ramips.
>
> The compatible string includes the vendor, which will make it way easier to
> find a particular image in directories with a lot of images. In theory, it
> should be even possible to provide all images in a single directory without
> target/subtarget prefix.
>
> Since the underscore isn't a valid character in compatible strings, we can
> use it in the image filename as replacement for the comma to split vendor
> from boardname.
>
> Due to the sync of runtime boardname and the boardname used in the image
> filename, it should be possible to guess the used image filename more
> reliably as requested.
I used '-' to replace the ',' chars in
https://git.lede-project.org/?p=project/procd.git;a=commitdiff;h=453116e08e6a9349374bbff427b75f57ce5387c9
However, it was based on a mere feeling... I wouldn't mind changing it
to '_' instead.
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: config_generate: keep ipv6 interface in sync
On Wed, Dec 06, 2017 at 05:58:18PM +0100, Matthias Schiffer wrote:
> On 12/06/2017 12:40 AM, Roman Yeryomin wrote:
> > On 2017-12-05 21:52, Hans Dedecker wrote:
> >> On Tue, Dec 5, 2017 at 5:22 PM, Roman Yeryomin wrote:
> >>> It's better not to configure ifname separately since they
> >>> are tied together.
> >>>
> >>> Signed-off-by: Roman Yeryomin
> >>> ---
> >>> package/base-files/files/bin/config_generate | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/package/base-files/files/bin/config_generate
> >>> b/package/base-files/files/bin/config_generate
> >>> index a8311fc595..d7a6829d77 100755
> >>> --- a/package/base-files/files/bin/config_generate
> >>> +++ b/package/base-files/files/bin/config_generate
> >>> @@ -113,7 +113,7 @@ generate_network() {
> >>> set network.$1.proto='dhcp'
> >>> delete network.${1}6
> >>> set network.${1}6='interface'
> >>> - set network.${1}6.ifname='$ifname'
> >>> + set network.${1}6.ifname='@${1}'
> >>> set network.${1}6.proto='dhcpv6'
> >>> EOF
> >>> ;;
> >>> --
> >>> 2.14.1
> >> NACK
> >>
> >> This makes the IPv6 interface dependant on the operational status of
> >> the IPv4 interface; meaning the IPv6 interface will not be started if
> >> the IPv4 interface does not get an IP address.
> >> Especially this would break wan connectivity if the wan link only
> >> supports IPv6
> >>
> >
> > Hmm... right, will just ${1} be better?
> >
> > Regards,
> > Roman
>
> No, there is no real interface called 'wan', so it will simply not work at
> all. Logical netifd interface names can only be used in alias
> configurations, but aliases always add a depenency on the 'up' state of the
> aliased interface (so aliases are mostly useful for interfaces that
> actually depend on each other, like a interface depending on a lower
> interface.
>
> If you want two configurations not to depend on each other, as we usually
> want for IPv4/IPv6 setup, the current version '$ifname' is exactly right.
> It is also the clearest solution semantically: IPv4 and IPv6 uplink are two
> independent configurations that just share the same physical link in the
> most common setups.
In case the interface-name changes dynamically during runtime (such as
for L2TPv3, ...) we could introduce a common parent with proto 'none'
and then have two child interfaces wan4 and wan6 which refer to the
common parent using the '@' notation.
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] netifd: always send DHCPv4 hostname
Hi Mathias,
On Fri, Dec 08, 2017 at 09:35:26AM +0100, Mathias Kresin wrote:
> udhcpc doesn't send a hostname by default. Use the system hostname if
> nothing else is specified, to always send a hostname.
>
> It syncs the behaviour to odhcpc, which always sends a hostname.
Could we somehow allow to deliberately not send any hostname?
ISC dhcpcd allows setting it to 'null' or 'localhost' for that
purpose.
There are two possible uses for not sending the hostname in the DHCP
request:
i) expecting the hostname to be assigned by the DHCP server
ii) minimizing the amount of identifyable bits being sent, e.g.
when connecting to public networks
Cheers
Daniel
>
> Signed-off-by: Mathias Kresin
> ---
> package/network/config/netifd/files/lib/netifd/proto/dhcp.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
> b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
> index ea02d68..143e445 100755
> --- a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
> +++ b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
> @@ -40,6 +40,7 @@ proto_dhcp_setup() {
> append dhcpopts "-x $opt"
> done
>
> + [ -z "$hostname" ] && hostname="$(cat /proc/sys/kernel/hostname)"
> [ "$broadcast" = 1 ] && broadcast="-B" || broadcast=
> [ "$release" = 1 ] && release="-R" || release=
> [ -n "$clientid" ] && clientid="-x 0x3d:${clientid//:/}" ||
> clientid="-C"
> --
> 2.7.4
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] new RBM33G board
Hi Dan, On Mon, Dec 25, 2017 at 10:50:41AM -0700, dan wrote: > Guys, new product from mikrotik. RBM33G. Has a MT7621A CPU w/ 16MB > of flash, 256MB RAM, and pcie m.2. > > This thing has 2 mini pci2 slots and 3 gigabit ethernet port and looks > nearly perfect for a dual radio, quad channel mesh box. Sounds promissing :) And the price is also quite convincing... > > I see that there are some devices with this cpu already supported by > lede. Any chance someone has got their hands on this unit and know if > the bootloader is usable ie if LEDE will run on it? If not, anyone > take bounties to 'port' LEDE to a specific board? MT7621 is generally quite straight forward, all boards I've seen for now use MTK's SDK U-Boot which could even be replaced quite easily in case it is locked down or anything. Porting LEDE hence shouldn't be very hard, I estimate that to be one hack-evening for it to be running somehow, two days to include support for a non-intrusive initial flash method (support vendors web-ui firmware format, tftp/recovery or find a backdoor). I'd be up to do that for getting the hardware + you-name-it. Cheers Daniel > > Thanks. > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH/RFC] hostapd: update to git snapshot of 2017-12-21
The following patches were merged upstream: 000-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch replaced by commit 0e3bd7ac6 001-Prevent-reinstallation-of-an-already-in-use-group-ke.patch replaced by commit cb5132bb3 002-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch replaced by commit 87e2db16b 003-Prevent-installation-of-an-all-zero-TK.patch replaced by commit 53bb18cc8 004-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch replaced by commit 0adc9b28b 005-TDLS-Reject-TPK-TK-reconfiguration.patch replaced by commit ff89af96e 006-WNM-Ignore-WNM-Sleep-Mode-Response-without-pending-r.patch replaced by commit adae51f8b 007-FT-Do-not-allow-multiple-Reassociation-Response-fram.patch replaced by commit 2a9c5217b 008-WPA-Extra-defense-against-PTK-reinstalls-in-4-way-ha.patch replaced by commit a00e946c1 009-Clear-PMK-length-and-check-for-this-when-deriving-PT.patch replaced by commit b488a1294 010-Optional-AP-side-workaround-for-key-reinstallation-a.patch replaced by commit 6f234c1e2 011-Additional-consistentcy-checks-for-PTK-component-len.patch replaced by commit a6ea66530 012-Clear-BSSID-information-in-supplicant-state-machine-.patch replaced by commit c0fe5f125 013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch replaced by commit 114f2830d New patches added: 010-disable-dpp-with-internal-crypto.patch add ifdef'ery also around dpp headers to avoid openssl includes Some patches had to be modified to work with changed upstream source: 380-disable_ctrl_iface_mib.patch add more ifdef'ery plus some minor knits needed for other patches to apply which are not worth being explicitely listed here. For SAE key management in mesh mode, use the newly introduce sae_password parameter instead of the psk parameter to also support SAE keys which would fail the checks applied on the psk field (ie. length and such). Signed-off-by: Daniel Golle --- package/network/services/hostapd/Makefile | 8 +- package/network/services/hostapd/files/hostapd.sh | 6 +- ...-Avoid-key-reinstallation-in-FT-handshake.patch | 154 - ...nstallation-of-an-already-in-use-group-ke.patch | 244 - ...ection-of-GTK-IGTK-reinstallation-of-WNM-.patch | 182 --- ...03-Prevent-installation-of-an-all-zero-TK.patch | 73 -- ...Fix-PTK-rekeying-to-generate-a-new-ANonce.patch | 56 - .../005-TDLS-Reject-TPK-TK-reconfiguration.patch | 124 --- ...WNM-Sleep-Mode-Response-without-pending-r.patch | 35 --- ...llow-multiple-Reassociation-Response-fram.patch | 68 -- ...efense-against-PTK-reinstalls-in-4-way-ha.patch | 34 --- ...ength-and-check-for-this-when-deriving-PT.patch | 53 - ...-side-workaround-for-key-reinstallation-a.patch | 221 --- .../010-disable-dpp-with-internal-crypto.patch | 44 ...consistentcy-checks-for-PTK-component-len.patch | 100 - ...-information-in-supplicant-state-machine-.patch | 25 --- ...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 --- .../hostapd/patches/110-no_eapol_fix.patch | 2 +- .../services/hostapd/patches/200-multicall.patch | 48 ++-- .../services/hostapd/patches/300-noscan.patch | 4 +- .../hostapd/patches/310-rescan_immediately.patch | 2 +- .../hostapd/patches/330-nl80211_fix_set_freq.patch | 2 +- .../patches/350-nl80211_del_beacon_bss.patch | 8 +- .../hostapd/patches/360-ctrl_iface_reload.patch| 10 +- .../hostapd/patches/370-ap_sta_support.patch | 16 +- .../patches/380-disable_ctrl_iface_mib.patch | 53 +++-- .../patches/390-wpa_ie_cap_workaround.patch| 4 +- .../patches/400-wps_single_auth_enc_type.patch | 4 +- .../hostapd/patches/420-indicate-features.patch| 4 +- .../hostapd/patches/430-hostapd_cli_ifdef.patch| 4 +- .../services/hostapd/patches/450-scan_wait.patch | 12 +- ...ant-add-new-config-params-to-be-used-with.patch | 12 +- ...80211-use-new-parameters-during-ibss-join.patch | 4 +- .../patches/463-add-mcast_rate-to-11s.patch| 6 +- .../hostapd/patches/464-fix-mesh-obss-check.patch | 2 +- .../hostapd/patches/600-ubus_support.patch | 44 ++-- 36 files changed, 183 insertions(+), 1520 deletions(-) delete mode 100644 package/network/services/hostapd/patches/000-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch delete mode 100644 package/network/services/hostapd/patches/001-Prevent-reinstallation-of-an-already-in-use-group-ke.patch delete mode 100644 package/network/services/hostapd/patches/002-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch delete mode 100644 package/network/services/hostapd/patches/003-Prevent-installation-of-an-all-zero-TK.patch delete mode 100644 package/network/services/hostapd/patches/004-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch delete mode 100644 package/network/services/hostapd/patches/005-TDLS-Reject-TPK-TK-reconfiguration.patch delete mode 10064
[LEDE-DEV] [PATCH] base-files: quote values when evaluating uevent
When sourcing /sys/class/block/*/uevent values have to be quoted as
they may contain spaces (e.g. in PARTNAME).
Fix this by pre-processing with sed before sourcing.
Signed-off-by: Daniel Golle
---
package/base-files/files/lib/upgrade/common.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index 71cffc8587..616131c89c 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -134,8 +134,7 @@ export_bootdevice() {
esac
if [ -e "$uevent" ]; then
- . "$uevent"
-
+ eval "$(sed "s/=\(.*\)/=\'\1\'/" < "$uevent")"
export BOOTDEV_MAJOR=$MAJOR
export BOOTDEV_MINOR=$MINOR
return 0
@@ -150,7 +149,7 @@ export_partdevice() {
local uevent MAJOR MINOR DEVNAME DEVTYPE
for uevent in /sys/class/block/*/uevent; do
- . "$uevent"
+ eval "$(sed "s/=\(.*\)/=\'\1\'/" < "$uevent")"
if [ $BOOTDEV_MAJOR = $MAJOR -a $(($BOOTDEV_MINOR + $offset)) =
$MINOR -a -b "/dev/$DEVNAME" ]; then
export "$var=$DEVNAME"
return 0
--
2.16.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ar71xx: add support for Gainstrong Oolite V5.2
The Oolite V5.2 is a dual-radio system-on-a-module.
Specs:
- QCA9531 @ 550MHz with integrated 2T2R 802.11bgn
- 64 MB DDR2 RAM
- 16 MB SPI NOR Flash (W25Q128FV)
- 1+4x 10/100 Mbps Ethernet
- QCA9887 1T1R 802.11ac
Signed-off-by: Daniel Golle
---
.../linux/ar71xx/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 ++
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 11 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-gs-oolite.c | 41 ++
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/generic/config-default | 1 +
target/linux/ar71xx/image/generic.mk | 10 ++
12 files changed, 73 insertions(+)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index f131b3b633..002ad977b7 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -322,6 +322,7 @@ ar71xx_setup_interfaces()
;;
dir-615-i1|\
omy-g1|\
+ oolite-v5.2|\
r6100|\
smart-300|\
tl-wdr6500-v2|\
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8284550e92..f7bffe8232 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -67,6 +67,7 @@ case "$FIRMWARE" in
cf-e380ac-v1|\
cf-e380ac-v2|\
dlan-pro-1200-ac|\
+ oolite-v5.2|\
sr3200|\
xd3200)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index a255b83802..0dfb278792 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -850,6 +850,9 @@ ar71xx_board_detect() {
*"Oolite V1.0")
name="oolite"
;;
+ *"Oolite V5.2")
+ name="oolite-v5.2"
+ ;;
*"PB42")
name="pb42"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 8f56d1a8f6..23e45e941f 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -391,6 +391,7 @@ platform_check_image() {
omy-x1|\
onion-omega|\
oolite|\
+ oolite-v5.2|\
re355|\
re450|\
rut900|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 068b83ce8a..d2c4472cd3 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -123,6 +123,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_USB150 is not set
# CONFIG_ATH79_MACH_GS_MINIBOX_V1 is not set
# CONFIG_ATH79_MACH_GS_OOLITE is not set
+# CONFIG_ATH79_MACH_GS_OOLITE_V5_2 is not set
# CONFIG_ATH79_MACH_HIVEAP_121 is not set
# CONFIG_ATH79_MACH_HIWIFI_HC6361 is not set
# CONFIG_ATH79_MACH_HORNET_UB is not set
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index e495f6b4c2..dd5c63dcd5 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -121,6 +121,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_USB150 is not set
# CONFIG_ATH79_MACH_GS_MINIBOX_V1 is not set
# CONFIG_ATH79_MACH_GS_OOLITE is not set
+# CONFIG_ATH79_MACH_GS_OOLITE_V5_2 is not set
# CONFIG_ATH79_MACH_HIVEAP_121 is not set
# CONFIG_ATH79_MACH_HIWIFI_HC6361 is not set
# CONFIG_ATH79_MACH_HORNET_UB is not set
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 248bffb1f5..e7fc8db78c 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -878,6 +878,17 @@ config ATH79_MACH_GS_OOLITE
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_GS_OOLITE_V5_2
+ bool "GS Oolite V5.2 support"
+ select SOC_QCA953X
+ select ATH79_DEV_AP9X_PCI if PCI
+ select ATH79_DEV_ETH
+ select ATH79_DEV_GPIO_BUTTONS
+ select ATH79_DEV_LEDS_GPIO
+ select ATH79_DEV_M25P80
+ select ATH79_DEV_USB
+ select ATH79_DEV_WMAC
+
config ATH79_MACH_HIVEAP_121
bool "Aerohive HiveAP-121 support"
Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server
Hi! On Thu, Feb 15, 2018 at 08:51:23AM -0700, Philip Prindeville wrote: > > > > This is just about the default configuration, it's not a choice between > > conflicting compile time options with varying security implications. While > > key authentication may be best practice, allowing SSH password logins isn't > > on the level of reimplementing LuCI in PHP 4. The change is *literally* a > > handful of sed commands, why can't advanced users take care of that > > themselves? Why do we want to make it easier to build a soft-bricking image > > than it is today? > > > Conversely, why can’t advanced users have a clear, standardized way of doing > this? That they’re “advanced” doesn’t mean they don’t also appreciate > convenience, an easy way to save and export/import configurations, etc. > > In a perfect world, no one should ever have to build with patches, anything > in files/, cherry-picked commits, etc. Everything would be expressed in the > .config (or kernel-config). > > And again, not every box would be bricked. Like I said, all of mine have > serial consoles and most of them have VGA. > > > > > > How about adding a configuration flag to menuconfig for OpenSSH, which runs > > said sed commands if the flag is set (disabled by default, for the reasons > > above). It makes it easier to set for those who want it, and it will also > > be saved in a diffconfig output if they set that. > > > Did exactly that in the original PR but it was vetoed. Watching this going back and forth I must admit that there is no good way of handling config-overlay provisioning of images. (or is there?) The informal idea of the workflow goes like buildroot -> imagebuilder -> run-time while in each phase only the truely neccessary choices are made and provisioning of the image happening using the imagebuilder FILES= parameter (ie. when rootfs is created, after packages are installed). Obviously this approach does have flaws, to illustrate that, lets look at the options you got in order to achieve your goal in that model: - keep a synced copy of the file and pass it to imagebuilder using FILES=... - have an additional package which sed-patches the config file in post-install *and* run-time in case of the openssh package being updated via opkg - have a local VARIANT=nopwdauth of the openssh package which PROVIDES=... the former and has a deviating default config shipped. All three don't look particularly 'clean' to me... Even if you had abstracted all or at least the part of the opensshd configuration necessary for you in UCI, there would be no particularly more clean option to divert from the defaults -- you'd end up with /etc/config/opensshd.opkg-new every time you update openssh via opkg unless you implement a way to migrate updated config options (which is what we do for some very fundamental packages because users may decide to keep the configuration when using sysupgrade, so also there config-migration has to be taken care of, but for opkg we just don't care) My feeling is still that 'keeping it flat' by simply overloading that one file using the FILES= statement of either imagebuilder or buildroot and having that local config kept in-sync is still the best option you got -- for now the increased complexity and maintainance of any of the infrastructural changes which came up to better model such use-cases don't seem to really be worth it (in terms of actually solving the problem). The deep problem we are looking it imho is the fact that UCI in its current form is insufficient. It doesn't model the difference of generic configuration (think: dhcp) which is applied for any service implementing that functionality (think: dnsmasq, odhcpd, isc-dhcp) and implementation-specific configuration (think: the odhcpd section inside the dhcp config vs. dropbear having its indidivual config). It also doesn't model on which layer a configuration change was made (distribution/build-time, uci-defaults/firstboot, provisioning, management or user) neither the scope of the change (global, target-platform, device-type-specific, organisational structures or individual boxes). Not even mentioning the disadvantages of UCI's 'dynamic typing' when on the other hand, ubus and json got defined basic types. And the debate about anonymous config sections still causes pts for many of us... These and many other reasons made people talk about replacing UCI with something more modern for almost a decade -- it's simplicity and popularity with users, however, made UCI survive up to now. Maybe we should have a configuration/modelling/management/provisioning track at the upcoming OpenWrt Summit...? Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] revisited: Nanostation m5 XW ethernet patch gone
Hi! I just witnessed the Ethernet issue returning on OpenWrt snapshot on Ubiquiti NanoStation M5 XW (NSM5-XW): ag71xx.0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd043, driver=Atheros AR8216/AR8236/AR8316] After about three days uptime eth0 links were lost and could be recovered by resetting the device. The device is connected to another ubnt XW device (NB NBM5) which also runs OpenWrt. The logs didn't show anything suspicious. How should I debug the situation next time it occurrs? Cheers Daniel On Thu, Oct 19, 2017 at 02:03:35PM -0700, Joe Ayers wrote: > Was the fix included in the Generic PHY? If not, possible some of the > following are still using the generic and therefore would still have > the bug?: > > NBE/PBE-M5-300 XW: ag71xx ag71xx.0: connected to PHY at > ag71xx-mdio.0:01 [uid=004dd023, driver=Generic PHY] > NSM5-loco-XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01 > [uid=004dd023, driver=Generic PHY] > Airgrid M5 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01 > [uid=004dd023, driver=Generic PHY] > NBM5/16 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01 > [uid=004dd023, driver=Generic PHY] > NBM5/19 XW: ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:01 > [uid=004dd023, driver=Generic PHY] > > There was a bounty source on this defect -- how to get the original > OpenWRT defect closed? > > Regards, > Joe AE6XE > > > > > On Thu, Oct 19, 2017 at 12:58 PM, Felix Fietkau wrote: > > > > Hi Daniel, > > > > The patch that you mentioned is not related to your issue at all, since > > it only deals with the AT8032 PHY, which the NanoStation M does not > > have. Maybe you can provide a more detailed description of what symptoms > > you're seeing. > > > > I did indeed clean up the AT8032 mess and solved it in the PHY driver > > (controlled by platform data) instead of adding GPIO toggle hackery to > > the Ethernet driver. > > > > - Felix > > > > On 2017-10-19 20:20, Daniel Golle wrote: > > > Hi Felix! > > > Hi everyone! > > > > > > It looks like Tiziano is right and this patch did get lost somehow. > > > At least I can't find any work-arounds regarding PHY hangs committed in > > > neither target/linux/generic/files/* nor target/linux/ar71xx/files/*. > > > > > > The thread on lede-dev also seems to have stagnated after > > > http://lists.infradead.org/pipermail/lede-dev/2016-December/004406.html > > > > > > Felix, you said you had a more clean patch for this in your staging > > > tree? > > > > > > I'm asking because I might have just hit that bug once again on > > > UBNT-NM-XW, ie. uid=004dd043, driver=Atheros AR8216/AR8236/AR8316... > > > > > > Anyone? I've also had a lot of problems with that bug on XW hardware > > > and have since simply tried to avoid it (the hardware). Now that also > > > non-loco NanoStations are only available in their XW-version I'd be > > > happy to finally have a reliable work-around for that hardware problem. > > > > > > > > > Cheers > > > > > > > > > Daniel > > > > > > > > > - Forwarded message from Tiziano Bacocco - > > > > > > Date: Mon, 6 Feb 2017 16:34:24 +0100 > > > From: Tiziano Bacocco > > > To: openwrt-de...@lists.openwrt.org > > > Subject: [OpenWrt-Devel] Nanostation m5 XW ethernet patch gone > > > > > > Hello everyone > > > Could this patch http://gerrit.aredn.org/#/c/57 be merged in trunk? > > > I've just tested it with trunk and it works properly on my nanostation > > > loco > > > m5 xw , the PHY chip is correctly reset every like 8 hours or so and no > > > connectivity loss since then > > > > > > Bug report: > > > https://dev.openwrt.org/ticket/19085 > > > > > > System log after applying patch > > > Sun Feb 5 23:40:02 2017 kern.info kernel: [716206.656361] br-lan: port > > > 1(eth0) entered forwarding state > > > Sun Feb 5 23:40:02 2017 daemon.notice netifd: Network device 'eth0' link > > > is up > > > Sun Feb 5 23:40:04 2017 kern.info kernel: [716208.654021] br-lan: port > > > 1(eth0) entered forwarding state > > > Mon Feb 6 05:05:21 2017 kern.info kernel: [735725.556613] > > > ag71xx_check_reset: expected: 004d, got: > > > Mon Feb 6 05:05:21 2017 kern.info kernel: [735725.562190] > > > ag71xx_gpio_reset triggered > > > Mon Feb 6 05:05:21 2017 kern.info kernel: [735725.571328]
[LEDE-DEV] [PATCH] hostapd: update to git snapshot of 2018-03-13
Update hostapd sources to current git snapshot to get rid of local patches and pave the road towards using WPA3 features. For SAE key management in mesh mode, use the newly introduce sae_password parameter instead of the psk parameter to also support SAE keys which would fail the checks applied on the psk field (ie. length and such). The following patches were merged upstream: 000-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch replaced by commit 0e3bd7ac6 001-Prevent-reinstallation-of-an-already-in-use-group-ke.patch replaced by commit cb5132bb3 002-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch replaced by commit 87e2db16b 003-Prevent-installation-of-an-all-zero-TK.patch replaced by commit 53bb18cc8 004-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch replaced by commit 0adc9b28b 005-TDLS-Reject-TPK-TK-reconfiguration.patch replaced by commit ff89af96e 006-WNM-Ignore-WNM-Sleep-Mode-Response-without-pending-r.patch replaced by commit adae51f8b 007-FT-Do-not-allow-multiple-Reassociation-Response-fram.patch replaced by commit 2a9c5217b 008-WPA-Extra-defense-against-PTK-reinstalls-in-4-way-ha.patch replaced by commit a00e946c1 009-Clear-PMK-length-and-check-for-this-when-deriving-PT.patch replaced by commit b488a1294 010-Optional-AP-side-workaround-for-key-reinstallation-a.patch replaced by commit 6f234c1e2 011-Additional-consistentcy-checks-for-PTK-component-len.patch replaced by commit a6ea66530 012-Clear-BSSID-information-in-supplicant-state-machine-.patch replaced by commit c0fe5f125 013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch replaced by commit 114f2830d Some patches had to be modified to work with changed upstream source: 380-disable_ctrl_iface_mib.patch add more ifdef'ery plus some minor knits needed for other patches to apply which are not worth being explicitely listed here. Signed-off-by: Daniel Golle --- Compile tested: ar71xx/generic, ramips/mt7621 Run tested: ramips/mt7621 (MT7603E+MT7612E) package/network/services/hostapd/Makefile | 8 +- package/network/services/hostapd/files/hostapd.sh | 6 +- ...-Avoid-key-reinstallation-in-FT-handshake.patch | 154 - ...nstallation-of-an-already-in-use-group-ke.patch | 244 - ...ection-of-GTK-IGTK-reinstallation-of-WNM-.patch | 182 --- ...03-Prevent-installation-of-an-all-zero-TK.patch | 73 -- ...Fix-PTK-rekeying-to-generate-a-new-ANonce.patch | 56 - .../005-TDLS-Reject-TPK-TK-reconfiguration.patch | 124 --- ...WNM-Sleep-Mode-Response-without-pending-r.patch | 35 --- ...llow-multiple-Reassociation-Response-fram.patch | 68 -- ...efense-against-PTK-reinstalls-in-4-way-ha.patch | 34 --- ...ength-and-check-for-this-when-deriving-PT.patch | 53 - ...-side-workaround-for-key-reinstallation-a.patch | 221 --- ...consistentcy-checks-for-PTK-component-len.patch | 100 - ...-information-in-supplicant-state-machine-.patch | 25 --- ...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 --- .../hostapd/patches/110-no_eapol_fix.patch | 2 +- .../services/hostapd/patches/200-multicall.patch | 48 ++-- .../services/hostapd/patches/300-noscan.patch | 4 +- .../hostapd/patches/310-rescan_immediately.patch | 2 +- .../hostapd/patches/330-nl80211_fix_set_freq.patch | 2 +- .../patches/350-nl80211_del_beacon_bss.patch | 10 +- .../hostapd/patches/360-ctrl_iface_reload.patch| 10 +- .../hostapd/patches/370-ap_sta_support.patch | 18 +- .../patches/380-disable_ctrl_iface_mib.patch | 53 +++-- .../patches/390-wpa_ie_cap_workaround.patch| 4 +- .../patches/400-wps_single_auth_enc_type.patch | 4 +- .../hostapd/patches/420-indicate-features.patch| 4 +- .../hostapd/patches/430-hostapd_cli_ifdef.patch| 4 +- .../services/hostapd/patches/450-scan_wait.patch | 12 +- ...ant-add-new-config-params-to-be-used-with.patch | 12 +- ...80211-use-new-parameters-during-ibss-join.patch | 4 +- .../patches/463-add-mcast_rate-to-11s.patch| 6 +- .../hostapd/patches/464-fix-mesh-obss-check.patch | 2 +- .../hostapd/patches/600-ubus_support.patch | 52 +++-- 35 files changed, 147 insertions(+), 1524 deletions(-) delete mode 100644 package/network/services/hostapd/patches/000-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch delete mode 100644 package/network/services/hostapd/patches/001-Prevent-reinstallation-of-an-already-in-use-group-ke.patch delete mode 100644 package/network/services/hostapd/patches/002-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch delete mode 100644 package/network/services/hostapd/patches/003-Prevent-installation-of-an-all-zero-TK.patch delete mode 100644 package/network/services/hostapd/patches/004-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch delete mode 100644 package/network/services/hostapd/patches/005-TDLS-Reject-TPK-TK-reconfiguration.patch d
Re: [LEDE-DEV] [PATCH] hostapd: update to git snapshot of 2018-03-13
Runs nice and stable since this post. Should I just push it? Tested on: ramips/mt7621, ar71xx/generic On Thu, Mar 15, 2018 at 01:29:03AM +0100, Daniel Golle wrote: > Update hostapd sources to current git snapshot to get rid of local > patches and pave the road towards using WPA3 features. > > For SAE key management in mesh mode, use the newly introduce > sae_password parameter instead of the psk parameter to also support > SAE keys which would fail the checks applied on the psk field (ie. > length and such). > > The following patches were merged upstream: > 000-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch > replaced by commit 0e3bd7ac6 > 001-Prevent-reinstallation-of-an-already-in-use-group-ke.patch > replaced by commit cb5132bb3 > 002-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch > replaced by commit 87e2db16b > 003-Prevent-installation-of-an-all-zero-TK.patch > replaced by commit 53bb18cc8 > 004-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch > replaced by commit 0adc9b28b > 005-TDLS-Reject-TPK-TK-reconfiguration.patch > replaced by commit ff89af96e > 006-WNM-Ignore-WNM-Sleep-Mode-Response-without-pending-r.patch > replaced by commit adae51f8b > 007-FT-Do-not-allow-multiple-Reassociation-Response-fram.patch > replaced by commit 2a9c5217b > 008-WPA-Extra-defense-against-PTK-reinstalls-in-4-way-ha.patch > replaced by commit a00e946c1 > 009-Clear-PMK-length-and-check-for-this-when-deriving-PT.patch > replaced by commit b488a1294 > 010-Optional-AP-side-workaround-for-key-reinstallation-a.patch > replaced by commit 6f234c1e2 > 011-Additional-consistentcy-checks-for-PTK-component-len.patch > replaced by commit a6ea66530 > 012-Clear-BSSID-information-in-supplicant-state-machine-.patch > replaced by commit c0fe5f125 > 013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch > replaced by commit 114f2830d > > Some patches had to be modified to work with changed upstream source: > 380-disable_ctrl_iface_mib.patch > add more ifdef'ery > plus some minor knits needed for other patches to apply which are not > worth being explicitely listed here. > > Signed-off-by: Daniel Golle > --- > Compile tested: ar71xx/generic, ramips/mt7621 > Run tested: ramips/mt7621 (MT7603E+MT7612E) > > package/network/services/hostapd/Makefile | 8 +- > package/network/services/hostapd/files/hostapd.sh | 6 +- > ...-Avoid-key-reinstallation-in-FT-handshake.patch | 154 - > ...nstallation-of-an-already-in-use-group-ke.patch | 244 > - > ...ection-of-GTK-IGTK-reinstallation-of-WNM-.patch | 182 --- > ...03-Prevent-installation-of-an-all-zero-TK.patch | 73 -- > ...Fix-PTK-rekeying-to-generate-a-new-ANonce.patch | 56 - > .../005-TDLS-Reject-TPK-TK-reconfiguration.patch | 124 --- > ...WNM-Sleep-Mode-Response-without-pending-r.patch | 35 --- > ...llow-multiple-Reassociation-Response-fram.patch | 68 -- > ...efense-against-PTK-reinstalls-in-4-way-ha.patch | 34 --- > ...ength-and-check-for-this-when-deriving-PT.patch | 53 - > ...-side-workaround-for-key-reinstallation-a.patch | 221 --- > ...consistentcy-checks-for-PTK-component-len.patch | 100 - > ...-information-in-supplicant-state-machine-.patch | 25 --- > ...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 --- > .../hostapd/patches/110-no_eapol_fix.patch | 2 +- > .../services/hostapd/patches/200-multicall.patch | 48 ++-- > .../services/hostapd/patches/300-noscan.patch | 4 +- > .../hostapd/patches/310-rescan_immediately.patch | 2 +- > .../hostapd/patches/330-nl80211_fix_set_freq.patch | 2 +- > .../patches/350-nl80211_del_beacon_bss.patch | 10 +- > .../hostapd/patches/360-ctrl_iface_reload.patch| 10 +- > .../hostapd/patches/370-ap_sta_support.patch | 18 +- > .../patches/380-disable_ctrl_iface_mib.patch | 53 +++-- > .../patches/390-wpa_ie_cap_workaround.patch| 4 +- > .../patches/400-wps_single_auth_enc_type.patch | 4 +- > .../hostapd/patches/420-indicate-features.patch| 4 +- > .../hostapd/patches/430-hostapd_cli_ifdef.patch| 4 +- > .../services/hostapd/patches/450-scan_wait.patch | 12 +- > ...ant-add-new-config-params-to-be-used-with.patch | 12 +- > ...80211-use-new-parameters-during-ibss-join.patch | 4 +- > .../patches/463-add-mcast_rate-to-11s.patch| 6 +- > .../hostapd/patches/464-fix-mesh-obss-check.patch | 2 +- > .../hostapd/patches/600-ubus_support.patch | 52 +++-- > 35 files changed, 147 insertions(+), 1524 deletions(-) > delete mode 100644 > package/network/services/hostapd/patches/000-hostapd-Avoid-key-reinstallation
[LEDE-DEV] [PATCH] busybox: update to version 1.28.1
Addresses CVE-2017-15873 and CVE-2017-15874.
Patch 600-cve-2017-16544.patch replaced by upstream fix.
Some smaller changes mostly related to the elimination of
getops's opt_complementary were needed for other patches.
Signed-off-by: Daniel Golle
---
package/utils/busybox/Makefile | 6 ++--
.../busybox/patches/200-udhcpc_reduce_msgs.patch | 4 +--
.../patches/201-udhcpc_changed_ifindex.patch | 2 +-
.../patches/203-udhcpc_renew_no_deconfig.patch | 2 +-
.../busybox/patches/230-add_nslookup_lede.patch| 5 ++--
.../utils/busybox/patches/250-date-k-flag.patch| 31 +--
.../patches/510-move-passwd-applet-to-bin.patch| 2 +-
.../utils/busybox/patches/600-cve-2017-16544.patch | 35 --
8 files changed, 26 insertions(+), 61 deletions(-)
delete mode 100644 package/utils/busybox/patches/600-cve-2017-16544.patch
diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile
index 623fbd5896..85ceaa5cd2 100644
--- a/package/utils/busybox/Makefile
+++ b/package/utils/busybox/Makefile
@@ -8,14 +8,14 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=busybox
-PKG_VERSION:=1.27.2
-PKG_RELEASE:=3
+PKG_VERSION:=1.28.1
+PKG_RELEASE:=1
PKG_FLAGS:=essential
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=https://www.busybox.net/downloads \
http://sources.buildroot.net
-PKG_HASH:=9d4be516b61e6480f156b11eb42577a13529f75d3383850bb75c50c285de63df
+PKG_HASH:=98fe1d3c311156c597cd5cfa7673bb377dc552b6fa20b5d3834579da3b13652e
PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam
PKG_BUILD_PARALLEL:=1
diff --git a/package/utils/busybox/patches/200-udhcpc_reduce_msgs.patch
b/package/utils/busybox/patches/200-udhcpc_reduce_msgs.patch
index 5f64c19d05..a47c4fcc10 100644
--- a/package/utils/busybox/patches/200-udhcpc_reduce_msgs.patch
+++ b/package/utils/busybox/patches/200-udhcpc_reduce_msgs.patch
@@ -1,6 +1,6 @@
--- a/networking/udhcp/dhcpc.c
+++ b/networking/udhcp/dhcpc.c
-@@ -706,6 +706,7 @@ static int bcast_or_ucast(struct dhcp_pa
+@@ -711,6 +711,7 @@ static int bcast_or_ucast(struct dhcp_pa
static NOINLINE int send_discover(uint32_t xid, uint32_t requested)
{
struct dhcp_packet packet;
@@ -8,7 +8,7 @@
/* Fill in: op, htype, hlen, cookie, chaddr fields,
* random xid field (we override it below),
-@@ -723,6 +724,7 @@ static NOINLINE int send_discover(uint32
+@@ -728,6 +729,7 @@ static NOINLINE int send_discover(uint32
*/
add_client_options(&packet);
diff --git a/package/utils/busybox/patches/201-udhcpc_changed_ifindex.patch
b/package/utils/busybox/patches/201-udhcpc_changed_ifindex.patch
index 727f69409c..51b15a73cc 100644
--- a/package/utils/busybox/patches/201-udhcpc_changed_ifindex.patch
+++ b/package/utils/busybox/patches/201-udhcpc_changed_ifindex.patch
@@ -1,6 +1,6 @@
--- a/networking/udhcp/dhcpc.c
+++ b/networking/udhcp/dhcpc.c
-@@ -1442,6 +1442,12 @@ int udhcpc_main(int argc UNUSED_PARAM, c
+@@ -1417,6 +1417,12 @@ int udhcpc_main(int argc UNUSED_PARAM, c
/* silence "uninitialized!" warning */
unsigned timestamp_before_wait = timestamp_before_wait;
diff --git a/package/utils/busybox/patches/203-udhcpc_renew_no_deconfig.patch
b/package/utils/busybox/patches/203-udhcpc_renew_no_deconfig.patch
index 7b77d2970b..f8e6640389 100644
--- a/package/utils/busybox/patches/203-udhcpc_renew_no_deconfig.patch
+++ b/package/utils/busybox/patches/203-udhcpc_renew_no_deconfig.patch
@@ -1,6 +1,6 @@
--- a/networking/udhcp/dhcpc.c
+++ b/networking/udhcp/dhcpc.c
-@@ -1112,7 +1112,6 @@ static void perform_renew(void)
+@@ -1124,7 +1124,6 @@ static void perform_renew(void)
state = RENEW_REQUESTED;
break;
case RENEW_REQUESTED: /* impatient are we? fine, square 1 */
diff --git a/package/utils/busybox/patches/230-add_nslookup_lede.patch
b/package/utils/busybox/patches/230-add_nslookup_lede.patch
index 14c0e87b33..acfc788d19 100644
--- a/package/utils/busybox/patches/230-add_nslookup_lede.patch
+++ b/package/utils/busybox/patches/230-add_nslookup_lede.patch
@@ -34,7 +34,7 @@ Signed-off-by: Jo-Philipp Wich
# However, on *other platforms* it fails when some of those flags
--- /dev/null
+++ b/networking/nslookup_lede.c
-@@ -0,0 +1,915 @@
+@@ -0,0 +1,914 @@
+/*
+ * nslookup_lede - musl compatible replacement for busybox nslookup
+ *
@@ -782,8 +782,7 @@ Signed-off-by: Jo-Philipp Wich
+ applet_long_options = nslookup_longopts;
+#endif
+
-+ opt_complementary = "q::";
-+ opts = getopt32(argv, "+q:*p:+r:+t:+s",
++ opts = getopt32(argv, "+q:*p:+r:+t:+s" "\0" "q::",
+ &type_strings, &default_port,
+ &default_retry, &default_timeout);
+
diff --git a/package/utils/busybox/patches/250-date-k-flag.patch
b/package/utils/bu
Re: [LEDE-DEV] [PATCH] brcm2708: add squashfs rootfs image
On Tue, Mar 27, 2018 at 07:42:18PM +0200, Christian Lamparter wrote: > This patch adds a image with squashfs as the root filesystem. > A rootfs_data partition will be generated on the first boot > and placed inside the rootfs partition (just after the squashfs > image). > > advantages: > - it is possible to migrate from an existing -ext4 >installation and back via sysupgrade. > - existing partition layout will not be lost. > - slightly smaller image size. > - support for attendedsysupgrade > > disadvantages: > - needs f2fs + tools as well. This is because fs-tools decides on the >blocksize of the sdcard. So either f2fs or ext4 can get choosen as >the rootfs_data filesystem (depends on the size of the root partition). > - rootfs_data is placed into the rootfs partition. This makes >it difficult for tools that expect a /dev/mmc0pX device. >It also makes it difficult for data recovery tools since they >might not expect to find a embedded partition or will be >confused. > > For people with existing build configurations: make sure to include mkf2fs > and f2fsck package into the image... Otherwise the new -squashfs image will > boot of a ram-overlay and won't keep the configurations after a reboot. > > Cc: Álvaro Fernández Rojas > Cc: Paul Spooren > Cc: Daniel Golle > Signed-off-by: Christian Lamparter Acked-by: Daniel Golle ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] hostapd: update to git snapshot of 2018-04-08
And import patch to allow 802.11s mesh on DFS channels, see also http://lists.infradead.org/pipermail/hostap/2018-April/038418.html Signed-off-by: Daniel Golle --- package/network/services/hostapd/Makefile | 6 +- ...1-mesh-factor-out-mesh-join-function.patch | 219 ++ ...2-mesh-factor-out-rsn-initialization.patch | 115 + ...0103-mesh-relocate-RSN-init-function.patch | 41 ...ompletion-callback-to-complete-mesh-.patch | 73 ++ ...ountry-setting-to-mesh-configuration.patch | 32 +++ ...rnel-driver-DFS-handler-in-userspace.patch | 48 ...annel-attributes-before-running-Mesh.patch | 33 +++ ...ce-type-to-mesh-before-setting-inter.patch | 36 +++ .../0109-mesh-set-mesh-center-frequency.patch | 22 ++ ...-mesh-interface-on-dfs-event-handler.patch | 138 +++ ...hannels-to-be-selected-if-dfs-is-ena.patch | 79 +++ ...-mesh-to-send-channel-switch-request.patch | 25 ++ ...-do-not-allow-pri-sec-channel-switch.patch | 27 +++ ...ot-allow-scan-result-to-swap-pri-sec.patch | 24 ++ ...sh-do-not-use-offchan-mgmt-tx-on-DFS.patch | 40 ...120-disable_bridge_packet_workaround.patch | 2 +- .../hostapd/patches/200-multicall.patch | 26 +-- .../services/hostapd/patches/300-noscan.patch | 4 +- .../patches/310-rescan_immediately.patch | 2 +- .../patches/330-nl80211_fix_set_freq.patch| 2 +- .../patches/340-reload_freq_change.patch | 6 +- .../patches/350-nl80211_del_beacon_bss.patch | 10 +- .../hostapd/patches/370-ap_sta_support.patch | 4 +- .../patches/380-disable_ctrl_iface_mib.patch | 20 +- .../patches/390-wpa_ie_cap_workaround.patch | 4 +- ...dd-new-config-params-to-be-used-with.patch | 2 +- ...-use-new-parameters-during-ibss-join.patch | 4 +- .../patches/463-add-mcast_rate-to-11s.patch | 24 +- .../patches/464-fix-mesh-obss-check.patch | 2 +- .../hostapd/patches/600-ubus_support.patch| 34 +-- 31 files changed, 1028 insertions(+), 76 deletions(-) create mode 100644 package/network/services/hostapd/patches/0101-mesh-factor-out-mesh-join-function.patch create mode 100644 package/network/services/hostapd/patches/0102-mesh-factor-out-rsn-initialization.patch create mode 100644 package/network/services/hostapd/patches/0103-mesh-relocate-RSN-init-function.patch create mode 100644 package/network/services/hostapd/patches/0104-mesh-use-setup-completion-callback-to-complete-mesh-.patch create mode 100644 package/network/services/hostapd/patches/0105-mesh-reflect-country-setting-to-mesh-configuration.patch create mode 100644 package/network/services/hostapd/patches/0106-mesh-inform-kernel-driver-DFS-handler-in-userspace.patch create mode 100644 package/network/services/hostapd/patches/0107-mesh-apply-channel-attributes-before-running-Mesh.patch create mode 100644 package/network/services/hostapd/patches/0108-mesh-set-interface-type-to-mesh-before-setting-inter.patch create mode 100644 package/network/services/hostapd/patches/0109-mesh-set-mesh-center-frequency.patch create mode 100644 package/network/services/hostapd/patches/0110-mesh-consider-mesh-interface-on-dfs-event-handler.patch create mode 100644 package/network/services/hostapd/patches/0111-mesh-Allow-DFS-channels-to-be-selected-if-dfs-is-ena.patch create mode 100644 package/network/services/hostapd/patches/0112-mesh-allow-mesh-to-send-channel-switch-request.patch create mode 100644 package/network/services/hostapd/patches/0113-mesh-do-not-allow-pri-sec-channel-switch.patch create mode 100644 package/network/services/hostapd/patches/0114-mesh-do-not-allow-scan-result-to-swap-pri-sec.patch create mode 100644 package/network/services/hostapd/patches/0115-mesh-do-not-use-offchan-mgmt-tx-on-DFS.patch diff --git a/package/network/services/hostapd/Makefile b/package/network/services/hostapd/Makefile index f279168031..983249c4ec 100644 --- a/package/network/services/hostapd/Makefile +++ b/package/network/services/hostapd/Makefile @@ -11,9 +11,9 @@ PKG_RELEASE:=1 PKG_SOURCE_URL:=http://w1.fi/hostap.git PKG_SOURCE_PROTO:=git -PKG_SOURCE_DATE:=2018-03-26 -PKG_SOURCE_VERSION:=64624f31cf81dc6164462fa153ee7a5909e21183 -PKG_MIRROR_HASH:=2c9e2548b1e6bbafe1b4e545543999b587bbd31a85eba69d54ffced8d7394f30 +PKG_SOURCE_DATE:=2018-04-09 +PKG_SOURCE_VERSION:=fa617ee6a0b2d39e6372c93ef9437caa3bd9065a +PKG_MIRROR_HASH:=5e6f20153c3405ac905f89fea8a614a57e9ba19583b2de2777179381a74aa7b1 PKG_MAINTAINER:=Felix Fietkau PKG_LICENSE:=BSD-3-Clause diff --git a/package/network/services/hostapd/patches/0101-mesh-factor-out-mesh-join-function.patch b/package/network/services/hostapd/patches/0101-mesh-factor-out-mesh-join-function.patch new file mode 100644 index 00..7671d1e96c --- /dev/null +++ b/package/network/services/hostapd/patches/0101-mesh-factor-out-mesh-join-function.patch @@ -0,0 +1,219 @@ +From 91c0f3f6a9ecae3c9106bef8a8606fab0792dd28 Mon Sep 17 00:00:00 2001 +From: Peter Oh +Date: Thu, 12 Apr 2018 02
[LEDE-DEV] Project proposal: The GNUnet of autonomous Things
Hi! I want to suggest a project to be (partially) funded by prpl's OpenWrt project grant. Abstract: Implement a secure autotonomous IoT hub using OpenWrt/LEDE's ubus service and the GNUnet P2P framework. Introduction: Despite the ongoing hype about the so-called Internet of Things, the current practise is rather chaotic and severe structural flaws of IoT devices became a common occurance, including easy-to-remote-exploit vulnerabilities and brain-dead mistakes such as a hard-coded DNS server address rendering thousands of IoT connected devices unusable now that the server is no longer being operated. Given the continous history of quite predictable security and privacy-related catastrophies in the still quite infantile IoT-sphere, taking a step back, a radical shift of praradigms, away from the patterns of Web/Cloud-based infrastrucure will help providing a much more secure and reliable user experience and thereby increase trust in future networked applications. Recent examples of typical problems related to the missing security model and centralized control servers: http://metropolitan.fi/entry/ddos-attack-halts-heating-in-finland-amidst-winter Or hard-coded server addresses: http://www.out-law.com/en/articles/2016/october/singapore-telco-visits-customers-homes-to-secure-devices-after-cyberattack/ Or missing security by default: http://www.bbc.com/news/technology-37750798 >From a coders point of view, the lack of a vendor-neutral abstraction of low-bandwidth peripherals makes it hard to develop general purpose applications which do not depend on a specific hardware or middleware. This projects suggest a from bottom-to-top redesign addressing the diversity of components and local access methods (ranging from in-kernel-only drivers to almost pure userland implementations), connectivity (NAT traversal, discovery, ...) as well as security and privacy-related concerns. As a first measure, a generic integration of low-bandwidth peripherals such as simple sensors and actors using the OpenWrt/LEDE core infrastructure will provide a great improvement to access and manage local IoT features. This may then be used by various higher level applications, such as data-logging/monitoring, WebUI or machine-to-machine communication. As dependence on centralized services providing remote access has shown to be problematic in terms of security and privacy as well as reliability, direct connectivity or application-agnostic indirect routing using well-known P2P techniques can bring about more interoperatibility and sustainability. GNUnet provides (among with many other things) a modular toolkit for P2P, ranging from a NAT-aware multi-transport, cryptographically addressed general purpose overlay network to pub/sub, filesharing and real-time conversation services. In a second phase of the project, this core infrastructure is going to be used to provide secure, reliable and privacy-aware remote access to IoT features on typical OpenWrt/LEDE target hardware. Using GNUnet implies inheriting all the advantages of a secure P2P infrastructure which has seen 12 years of intense research and several iterations of architectural revolutions within that long time. Having a remote-access method for ubus which already provides it's own set tools to work in a wide range of environments (think: behind NAT, using low-level transports such as UDP, TCP, HTTP and proper HTTPS over IPv4/v6 as well as raw bluetooth and wifi injection sockets for local area coverage) and got it's own built-in security mechanisms as well as management structures (think: a distributed personal PKI) also seems to be a very good match, especially due to the modular nature of GNUnet which allows using only the parts needed on resource constraint hardware. Obviously this may be also very useful for any kind of remote-management or other sort of remote-access to ubus and/or rpcd. GNUnet is extremely portable, works on a great variety UNIX-like systems as well as Windows and can be compiled using LLVM, thus be turned into a in-browser JavaScript-monster using enscriptem, see https://gnunet.io/ for an early example of an in-browser version of GNUnet's anonymous filesharing service. In the past 2 years I ported to OpenWrt/LEDE, contributed fixes as well as features back upstream and became a member of the GNUnet e.V. association, mainly having applications like the above in mind. In a third phase, a set of services utilizing that infrastructure such as a plugin for collectd (data logging), a programmable monitor/alarm service polling properties and emmit events and action triggers listing for events and controlling actors is going to be built. Project schedule (I) As a first step towards better integration of typical IoT USE-cases into OpenWrt/LEDE, a ubus service allowing access to low-bandwidth peripherals shall be created. It's modular design shall allow for plugins providing access to various different APIs and low-level busses. Plugins may expose read and
Re: [LEDE-DEV] Project proposal: The GNUnet of autonomous Things
Hi Hauke, On Fri, Nov 18, 2016 at 01:30:37PM +0100, Hauke Mehrtens wrote: > Hi Daniel, > > This sounds interesting. > > I have some questions regarding phase 1. > > 1. Do you want to have an API to switch for example a smart plug on and > off and an other call to get the temperature from a temperature sensor? I want to have a service sitting on ubus for both, low-bandwidth read and write operations (ie. sensors and actors) > > 2. Should this more focus on local IoT sensors line a temperature sensor > connected via I2C or more on remote sensors like a smart plug connected > via ZigBee? I think both would be cool. I'd start with local stuff (I2C, GPIO) as that's what I got most experience with. However, the plugin API should allow to write bindings for > > 3. What would be the difference to for example IoTvity, openHAB and > other existing solutions? It's going to be vendor-neutral, tiny and integrates well with other stuff we already got on OpenWrt/LEDE (ie. it uses libubox, ubus, ...). I'm going to write the service in C and expect the core to be only a few dozens kilobytes in (binary) size. > > It would also be nice to have better 6LoWPAN integration in LEDE / > OpenWrt to make it easy to configure 6LoWPAN on top of ZigBee or BLE and > then route the IP traffic to the local network or the Internet like a > normal network interface in LEDE. This is probably unrelated to your > proposal. I'm not really the biggest friend of the idea to have every microcontroller exposed on the IPv6 ARPA internet, however, if well firewalled and isolated from the rest of the world, it could still be more interoperable to have IP rather than using media-specific sockets for the hub and devices to communicate. Cheers Daniel > > Hauke > > On 11/17/2016 12:39 PM, Daniel Golle wrote: > > Hi! > > > > I want to suggest a project to be (partially) funded by prpl's OpenWrt > > project grant. > > > > Abstract: > > Implement a secure autotonomous IoT hub using OpenWrt/LEDE's ubus > > service and the GNUnet P2P framework. > > > > Introduction: > > Despite the ongoing hype about the so-called Internet of Things, the > > current practise is rather chaotic and severe structural flaws of IoT > > devices became a common occurance, including easy-to-remote-exploit > > vulnerabilities and brain-dead mistakes such as a hard-coded DNS server > > address rendering thousands of IoT connected devices unusable now that > > the server is no longer being operated. > > Given the continous history of quite predictable security and > > privacy-related catastrophies in the still quite infantile IoT-sphere, > > taking a step back, a radical shift of praradigms, away from the > > patterns of Web/Cloud-based infrastrucure will help providing a much > > more secure and reliable user experience and thereby increase trust in > > future networked applications. > > > > Recent examples of typical problems related to the missing security > > model and centralized control servers: > > http://metropolitan.fi/entry/ddos-attack-halts-heating-in-finland-amidst-winter > > > > Or hard-coded server addresses: > > http://www.out-law.com/en/articles/2016/october/singapore-telco-visits-customers-homes-to-secure-devices-after-cyberattack/ > > > > Or missing security by default: > > http://www.bbc.com/news/technology-37750798 > > > > From a coders point of view, the lack of a vendor-neutral abstraction > > of low-bandwidth peripherals makes it hard to develop general purpose > > applications which do not depend on a specific hardware or middleware. > > > > This projects suggest a from bottom-to-top redesign addressing the > > diversity of components and local access methods (ranging from > > in-kernel-only drivers to almost pure userland implementations), > > connectivity (NAT traversal, discovery, ...) as well as security and > > privacy-related concerns. As a first measure, a generic integration of > > low-bandwidth peripherals such as simple sensors and actors using the > > OpenWrt/LEDE core infrastructure will provide a great improvement to > > access and manage local IoT features. This may then be used by > > various higher level applications, such as data-logging/monitoring, > > WebUI or machine-to-machine communication. > > > > As dependence on centralized services providing remote access has > > shown to be problematic in terms of security and privacy as well as > > reliability, direct connectivity or application-agnostic indirect > > routing using well-known P2P techniques can bring about more > > interoperatibilit
Re: [LEDE-DEV] [PATCH] tools: upslug2: Utilize existing bz2 archive
Hi Felix, On Thu, Dec 01, 2016 at 11:47:08AM +0100, Felix Fietkau wrote: > On 2016-11-23 22:00, Florian Fainelli wrote: > > http://downloads.openwrt.org/sources has a copy of the sources, but under > > tar.bz2 file format, so utilize this one since the SVN server is down. > > > > This showed up with attempting an orion target build. > > > > Signed-off-by: Florian Fainelli > Since upslug2 is not used by the build, I would suggest removing it from > tools/ instead. The NSLU2 devices are not widely used anymore... They are certainly are bit outdated, however, I recently flashed a LEDE snapshot to an IXP4xx based SLUG and it worked like a charme and now provides a small samba fileserver in a friend's place with very poor connectivity -- other than most of today's NAT boxes the slug actually got an RTC and the battery even still works up to today ;) Well, I had to enable upslug2 also for the ixp4xx target to be able to actually flash the device... (despite the popularity of the device 10 years ago OpenWrt/LEDE could be the last resort when it comes to tools and a working OS for that hardware). The slug was the first hackable Linux-based ARM box available to consumers world wide for an affordable price. They come up with RedBoot/ecos, thus can be un-bricked using this tool without the need to attach a serial console. There used to be a whole cluster of specialized distributions which apparently have all been abandonned; I consider that whole story to be an important piece of history which happened in parallel with the WRT54G and shouldn't just be neglected as 'yet another piece of outdated gear'. Actually, there are still quite a number of them in the wild -- and imho they provide an interesting edge- case being the smallest and most obscure (Intel's xscale ARM implemented with *big endian*) platform supported by the most minimalistic embedded Linux distro out there. Many people started embedded hacking with those boxes and are familiar with the expected performance (hence the name 'slug') and constraints. Code which even works well on the slug should work pretty well on practically all platforms today. Just my 2cts... Cheers Daniel > > - Felix > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
Hi Sukru, On Tue, Nov 22, 2016 at 08:52:57PM +, Sukru Senli wrote: > Hi Daniel, > > Regarding (Phase 2 - ubus rpc proxy), I had opened a thread in October: > https://lists.openwrt.org/pipermail/openwrt-devel/2016-October/042252.html > > Currently we are working on a solution where multiple OpenWrt devices share a > common ubus which allows us to control all devices from a single point. > > Our initial development is based on websockets (we have replaced uhttpd with > our websocket solution). ACL is still handled by rpcd. > > Once we are done with the initial development, we are planning to share the > code with the community so that anyone who is interested can try it out and > provide feedback and/or contribute. > > As the next step we were planning to investigate another approach where > websockets are not used for proxying but instead a lower level ubus proxying, > ubus monitor, and ubus ACLs (instead of rpcd) are used. > > If you agree that we are trying to achieve the same goal here, maybe we > should see how we can cooperate. I was following your posts and do believe there is quite some overlap. It would thus be feasible to generalize the common parts (ubus call proxy, ubus service proxy, ubus remote monitor) by agreeing on a shared interface the actual implementations shall use. In that way, people can choose whether they want WebSockets, TR-069 or a suitable P2P framework depending on their specific needs. Has anything of your current approach at IOPSYS been made available publicly (eg. on github?) >From what I can tell there is also some overlap with Felix' proposed System Configuration Abstraction Layer, just that my envisioned use exceeds system configuration as it includes sensors, events and actors rather than just access to a configuration model. Cheers Daniel > > Regards, > Sukru > > ____ > From: openwrt-devel [openwrt-devel-boun...@lists.openwrt.org] on behalf of > Daniel Golle [dan...@makrotopia.org] > Sent: Thursday, November 17, 2016 12:39 PM > To: open...@lists.prplfoundation.org; lede-dev@lists.infradead.org; > openwrt-de...@lists.openwrt.org; gnunet-develop...@gnu.org > Cc: Kathy Giori > Subject: [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things > > Hi! > > I want to suggest a project to be (partially) funded by prpl's OpenWrt > project grant. > > Abstract: > Implement a secure autotonomous IoT hub using OpenWrt/LEDE's ubus > service and the GNUnet P2P framework. > > Introduction: > Despite the ongoing hype about the so-called Internet of Things, the > current practise is rather chaotic and severe structural flaws of IoT > devices became a common occurance, including easy-to-remote-exploit > vulnerabilities and brain-dead mistakes such as a hard-coded DNS server > address rendering thousands of IoT connected devices unusable now that > the server is no longer being operated. > Given the continous history of quite predictable security and > privacy-related catastrophies in the still quite infantile IoT-sphere, > taking a step back, a radical shift of praradigms, away from the > patterns of Web/Cloud-based infrastrucure will help providing a much > more secure and reliable user experience and thereby increase trust in > future networked applications. > > Recent examples of typical problems related to the missing security > model and centralized control servers: > http://metropolitan.fi/entry/ddos-attack-halts-heating-in-finland-amidst-winter > > Or hard-coded server addresses: > http://www.out-law.com/en/articles/2016/october/singapore-telco-visits-customers-homes-to-secure-devices-after-cyberattack/ > > Or missing security by default: > http://www.bbc.com/news/technology-37750798 > > From a coders point of view, the lack of a vendor-neutral abstraction > of low-bandwidth peripherals makes it hard to develop general purpose > applications which do not depend on a specific hardware or middleware. > > This projects suggest a from bottom-to-top redesign addressing the > diversity of components and local access methods (ranging from > in-kernel-only drivers to almost pure userland implementations), > connectivity (NAT traversal, discovery, ...) as well as security and > privacy-related concerns. As a first measure, a generic integration of > low-bandwidth peripherals such as simple sensors and actors using the > OpenWrt/LEDE core infrastructure will provide a great improvement to > access and manage local IoT features. This may then be used by > various higher level applications, such as data-logging/monitoring, > WebUI or machine-to-machine communication. > > As dependence on centralized services providing remote access has > show
Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
Hi Felix, On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote: > On 2016-12-01 16:05, Daniel Golle wrote: > > Hi Sukru, > > > > On Tue, Nov 22, 2016 at 08:52:57PM +, Sukru Senli wrote: > >> Hi Daniel, > >> > >> Regarding (Phase 2 - ubus rpc proxy), I had opened a thread in October: > >> https://lists.openwrt.org/pipermail/openwrt-devel/2016-October/042252.html > >> > >> Currently we are working on a solution where multiple OpenWrt devices > >> share a common ubus which allows us to control all devices from a single > >> point. > >> > >> Our initial development is based on websockets (we have replaced uhttpd > >> with our websocket solution). ACL is still handled by rpcd. > >> > >> Once we are done with the initial development, we are planning to share > >> the code with the community so that anyone who is interested can try it > >> out and provide feedback and/or contribute. > >> > >> As the next step we were planning to investigate another approach where > >> websockets are not used for proxying but instead a lower level ubus > >> proxying, ubus monitor, and ubus ACLs (instead of rpcd) are used. > >> > >> If you agree that we are trying to achieve the same goal here, maybe we > >> should see how we can cooperate. > > > > I was following your posts and do believe there is quite some overlap. > > It would thus be feasible to generalize the common parts (ubus call > > proxy, ubus service proxy, ubus remote monitor) by agreeing on a shared > > interface the actual implementations shall use. In that way, people > > can choose whether they want WebSockets, TR-069 or a suitable P2P > > framework depending on their specific needs. > > Has anything of your current approach at IOPSYS been made available > > publicly (eg. on github?) > > > > From what I can tell there is also some overlap with Felix' proposed > > System Configuration Abstraction Layer, just that my envisioned use > > exceeds system configuration as it includes sensors, events and actors > > rather than just access to a configuration model. > If it makes sense, I'd be open to extending my abstraction layer to make > it suitable for your use case as well. > Feel free to propose changes to it if you like. Having a first deeper look at scal I believe that access to sensors and actors could be implemented inside scal similar to the existing shell and system backends. That would be nice, as then scal would make things available on ubus and provide the ACL mechanics. I'll have a deeper look and play with it to see whether that can work. Ideally, data collection (think: interface counters and such things which need to be polled) and triggering events (think: link status updates) should also be made accessible. A local database which exceeds UCI state as suggested by Luka could also be very useful, eg. for renewable energy or other applications where loss of connectivity should never imply loss of collected data. Cheers Daniel > > - Felix > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [OpenWrt] Project proposal: The GNUnet of autonomous Things
Hi Arturo, On Sat, Dec 03, 2016 at 03:58:17AM +0100, Arturo Rinaldi wrote: > Hello folks, > > as Kathy mentioned as first answer to Daniel, a proper setup running GNUnet > on our boards could give us a boost in the IoT world. During the last years I'm pretty sure we are practically at this point already. Try opkg install gnunet-gns-flat (and maybe some more transports, such as gnunet-transport-wlan or gnunet-transport-http_client) Once you got that, you can easily use it to tunnel access to conventional TCP/IP services via GNUnet using gnunet-exit and gnunet-vpn, which are already well-integrated with the OpenWrt packaging I created to have GNUnet participate in BattleMesh during the past years. > we have developed a new approach to the arduino "bridge" interaction with > CIAO : > > http://www.arduino.org/learning/tutorials/advanced-guides/ciao Interesting and indeed similar to the lower layers of the GNUnet stack. I'll definitely have a deeper look at it. > > this is of course requires the use of Python as high level language since > it is designed around it but transparent to any kind of connectors. If I > understand well from this first email exchange, since *ubus* will be the > running engine of the new it is a completely native approach being it an > underlying running service of OpenWRT. Am I wrong or didn't John show Yes, and combined with Felix' SCAL project it will allow atomic ACLs and integrate with different middle-ware models. The exact machanics of remote access are *not* part of this unified stack, this is where freedom to use netconf, TR-069 or any other kind of remote management stack on top comes in -- I personally imagine something less centralized than current Web technologies as e.g. local machine to machine communication shouldn't ever depend on the availability of an external entitity of connectivity (ie. I still want to be able to locally control my heating system and have different systems of a smart home interact even in case of failing internet connectivity). This is why I see GNUnet in that place, because it comes with both, local area and wide area transports. > something similar that night at C-base in Berlin as first attempt of > creating a sort of new approach to the bridge itself ? I reckon this was related to Mediatek's LinkIT approach, but I do not remember the details. John? > > This leads me to think about the possibility to use this solution in > combination with *lininoIO*, our new approach for exposing the MCU gpio(s) > as filesystem devices and using them to interact with sensors, actuators > and so on (it was one of the topics of my talk in Berlin). Would this be a > reasonable approach for you ? Please let us know what you think about it > and in case we'll discuss it in the scheduled call. I imagine this to be a possible backend in the ubus/scal approach I'm envisioning. I'll have a deeper look at lininoIO so we can talk about that in more detail soon. Cheers Daniel > > Best Regards > > Arturo > > 2016-12-01 16:51 GMT+01:00 Felix Fietkau : > > > On 2016-12-01 16:38, Daniel Golle wrote: > > > Hi Felix, > > > > > > On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote: > > >> On 2016-12-01 16:05, Daniel Golle wrote: > > >> > I was following your posts and do believe there is quite some overlap. > > >> > It would thus be feasible to generalize the common parts (ubus call > > >> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a > > shared > > >> > interface the actual implementations shall use. In that way, people > > >> > can choose whether they want WebSockets, TR-069 or a suitable P2P > > >> > framework depending on their specific needs. > > >> > Has anything of your current approach at IOPSYS been made available > > >> > publicly (eg. on github?) > > >> > > > >> > From what I can tell there is also some overlap with Felix' proposed > > >> > System Configuration Abstraction Layer, just that my envisioned use > > >> > exceeds system configuration as it includes sensors, events and actors > > >> > rather than just access to a configuration model. > > >> If it makes sense, I'd be open to extending my abstraction layer to make > > >> it suitable for your use case as well. > > >> Feel free to propose changes to it if you like. > > > > > > Having a first deeper look at scal I believe that access to sensors > > > and actors could be implemented inside scal similar to the existing > > > shell and system backends. That would be nice, as then scal would
Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
Hi Felix,
On Thu, Dec 01, 2016 at 04:51:30PM +0100, Felix Fietkau wrote:
> On 2016-12-01 16:38, Daniel Golle wrote:
> > Hi Felix,
> >
> > On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
> >> On 2016-12-01 16:05, Daniel Golle wrote:
> >> > I was following your posts and do believe there is quite some overlap.
> >> > It would thus be feasible to generalize the common parts (ubus call
> >> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a shared
> >> > interface the actual implementations shall use. In that way, people
> >> > can choose whether they want WebSockets, TR-069 or a suitable P2P
> >> > framework depending on their specific needs.
> >> > Has anything of your current approach at IOPSYS been made available
> >> > publicly (eg. on github?)
> >> >
> >> > From what I can tell there is also some overlap with Felix' proposed
> >> > System Configuration Abstraction Layer, just that my envisioned use
> >> > exceeds system configuration as it includes sensors, events and actors
> >> > rather than just access to a configuration model.
> >> If it makes sense, I'd be open to extending my abstraction layer to make
> >> it suitable for your use case as well.
> >> Feel free to propose changes to it if you like.
> >
> > Having a first deeper look at scal I believe that access to sensors
> > and actors could be implemented inside scal similar to the existing
> > shell and system backends. That would be nice, as then scal would
> > make things available on ubus and provide the ACL mechanics.
> Nice. Maybe we can reinterpret the acronym as "System Communication
> Abstraction Layer". I'd be fine with renaming it to something else as
> well, I just didn't find a better name for it yet.
>
> I think a good approach would be to add a dlopen plugin API to the json
> plugin itself, so you can use json files to parameterize access to
> sensors and other devices.
To me the question remains whether access to devices should happen
directly inside those scal-json-plugins or if it'd be better to
expose a service on ubus ("urthings") handling them (which was my
original plan) and then have scal access them via ubus. The latter
would come with the advantage that other local services (think:
collectd) could also access them via that urthings service instead of
having to go through scal.
I'd be glad to here more opinions, because this obviously has to be
decided early in the design of the IoT integration approach. Find
me on IRC (dangole@freenode) in the next couple of hours, maybe we
can collect some ideas about the edges to be cut before the meeting
at 3pm CET.
>
> Event handling could also be scripted through .json files using json_script.
I thought of it like that, similar to how procd's hotplug json_scripts
look like. In addition I thought about adding ubus input and output
support to collectd (so events can be triggered depending on conditions
defined over polled sensors), but maybe something much simpler and more
thightly designed for that specific job -- polling sensors, (maybe)
caching & monitoring/triggering events -- could also be sufficient.
However, I reckon this can be decided at a later stage, and as I'm
already quite familiar with collectd, I'd just go ahead and create
a ubus plugin there and who ever is unhappy with that may suggest
what ever else could be better.
Cheers
Daniel
>
> > I'll have a deeper look and play with it to see whether that can
> > work.
> >
> > Ideally, data collection (think: interface counters and such things
> > which need to be polled) and triggering events (think: link status
> > updates) should also be made accessible.
> >
> > A local database which exceeds UCI state as suggested by Luka could
> > also be very useful, eg. for renewable energy or other applications
> > where loss of connectivity should never imply loss of collected data.
> Makes sense.
>
> - Felix
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
Hi Hauke,
On Mon, Dec 05, 2016 at 01:54:20PM +0100, Hauke Mehrtens wrote:
> On 2016-12-05 11:57, Daniel Golle wrote:
> > Hi Felix,
> >
> > On Thu, Dec 01, 2016 at 04:51:30PM +0100, Felix Fietkau wrote:
> > > On 2016-12-01 16:38, Daniel Golle wrote:
> > > > Hi Felix,
> > > >
> > > > On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
> > > >> On 2016-12-01 16:05, Daniel Golle wrote:
> > > >> > I was following your posts and do believe there is quite some
> > > >> > overlap.
> > > >> > It would thus be feasible to generalize the common parts (ubus call
> > > >> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a
> > > >> > shared
> > > >> > interface the actual implementations shall use. In that way, people
> > > >> > can choose whether they want WebSockets, TR-069 or a suitable P2P
> > > >> > framework depending on their specific needs.
> > > >> > Has anything of your current approach at IOPSYS been made available
> > > >> > publicly (eg. on github?)
> > > >> >
> > > >> > From what I can tell there is also some overlap with Felix' proposed
> > > >> > System Configuration Abstraction Layer, just that my envisioned use
> > > >> > exceeds system configuration as it includes sensors, events and
> > > >> > actors
> > > >> > rather than just access to a configuration model.
> > > >> If it makes sense, I'd be open to extending my abstraction layer to
> > > >> make
> > > >> it suitable for your use case as well.
> > > >> Feel free to propose changes to it if you like.
> > > >
> > > > Having a first deeper look at scal I believe that access to sensors
> > > > and actors could be implemented inside scal similar to the existing
> > > > shell and system backends. That would be nice, as then scal would
> > > > make things available on ubus and provide the ACL mechanics.
> > > Nice. Maybe we can reinterpret the acronym as "System Communication
> > > Abstraction Layer". I'd be fine with renaming it to something else as
> > > well, I just didn't find a better name for it yet.
> > >
> > > I think a good approach would be to add a dlopen plugin API to the
> > > json
> > > plugin itself, so you can use json files to parameterize access to
> > > sensors and other devices.
> >
> > To me the question remains whether access to devices should happen
> > directly inside those scal-json-plugins or if it'd be better to
> > expose a service on ubus ("urthings") handling them (which was my
> > original plan) and then have scal access them via ubus. The latter
> > would come with the advantage that other local services (think:
> > collectd) could also access them via that urthings service instead of
> > having to go through scal.
>
> I would like to have an API which can be used locally easily not just from
> remote, I haven't found the time to look into scal .
> Like a Luci web UI to switch on and off your lamps and also some API so that
> others can easily integrate own application running on the device which are
> managing and controlling the things. Probably people will also run
> applications to connect the devices to existing clouds with existing
> interfaces.
I agree. Having a simple service on ubus allowing to expose sensors and
actors is still the best first-step which everything else can later on
build-upon. Using and, if necessary, extending SCAL to allow remote
access to specific objects exposed by that service shouldn't be too hard
either.
>
> > I'd be glad to here more opinions, because this obviously has to be
> > decided early in the design of the IoT integration approach. Find
> > me on IRC (dangole@freenode) in the next couple of hours, maybe we
> > can collect some ideas about the edges to be cut before the meeting
> > at 3pm CET.
> >
> > >
> > > Event handling could also be scripted through .json files using
> > > json_script.
> >
> > I thought of it like that, similar to how procd's hotplug json_scripts
> > look like. In addition I thought about adding ubus input and output
> > support to collectd (so events can be triggered depending on conditions
> > defined over polled sensors), but maybe something much simpler and more
> > thightly designed for that specific job -- p
Re: [LEDE-DEV] Release planning
Hi!
On Wed, Dec 21, 2016 at 08:13:00PM +0100, Jo-Philipp Wich wrote:
> ...
> # Open questions
>
> - Are there any outstanding changes?
>
> Is there important changes we should wait for before branching the
> release? Is there pending stuff in the staging trees which should
> absolutely go into the first release?
I believe that all targets should at least use the new image building
code to the point that we can nuke the old (sub-)target profiles.
I've just now touched sunxi (backporting ~ 350 patches to get better
support for H3 and thus the NanoPi NEO board) and there is quite a lot
to do there:
- convert target/sunxi/image/Makefile to new style and clean up
board-naming mess, currently we got:
* profile name = U-Boot name (e.g. orangepi_plus)
This name is currently also used to name OpenWrt/LEDE images
* DTS filename (e.g. sun8i-h3-orangepi-plus)
* /proc/device-tree/model, /proc/device-tree/compatible
* sunxi_board_name() (e.g. organgepi-plus)
## consistent board names are needed for future sysupgrade
- rewrite SDcard generation to support dynamicly sized partitions
instead of hard-coding the rootfs size. probably it makes sense to
unify SDcard generation code from bcm2708, mxs, sunxi and other
platforms with similar requirements into a shared script.
- use single-partition rootfs-split like x86 does
=> unlocks F2FS overlay and factory reset support
For obvious reasons the sunxi target hasn't seen much love since the
fork, and the same might apply for other targets which are maintained
by OpenWrt/non-LEDE devs. With regard to the upcoming release, how
should we deal with that situation?
In the imho likely future re-merge of the LEDE and OpenWrt git trees,
all remaining OpenWrt devs will be given commit access which will allow
them to contribute and maintain things. However, I think we at least
need a dead-line for that to happen or ship the LEDE release either
without those targets or fix them up ourselves.
Apparently we already got quite a lot of different sunxi boards here at
the CCC in Hamburg, so maybe this could be a single evening
joint-effort to lift the target to use state-of-the-art image
generation and have the result tested on as much hardware as possible.
However, I'll mostly be focusing on getting the oxnas target fit for
release, the target is still stuck on kernel 4.1: currently, NAND
doesn't work on some devices on kernel 4.4 whereas the same driver
works great on kernel 4.1 -- the problem is most likely hiding
somewhere else, pinmux or even probe order... Fixing that for 4.4 would
allow to support all oxnas boards in the upcoming release.
Another way could be backporting the new oxnas support which recently
made it into the kernel and port the remaining drivers (ehci-glue,
stmmac-glue, sata, pmic/leon, ...) to work on top of that. This would
come with the advantage that most code is built so that it can be
shared and used also be used for the older ox810se, thus allowing to
support that subtarget in future in LEDE as well.
>
> - When do we want to branch?
>
> Personally I'd like to branch before Christmas so that we can use the
> free time for building images (it takes about 8 days and ~2TB of space
> to build all targets and all packages).
Imho beginning of January, making it a 2017.01 is a good date for
branching.
>
> - How do we want to code name the release?
>
> Imho we should avoid naming it the same as master ("Reboot") to
> prevent future confusion. Maybe we could simply name it "Zero" or
> "Debut" to underline the fact that it is the first release.
I don't care too much.
>
> - Release branches in feed repos?
>
> What do we do if an external feed does not want to maintain a LEDE
> specific release branch - shall we fork it instead and host the fork
> our self?
>
> - Who is willing to support the release branch?
>
> We will need one to two people to keep an closer eye on the release
> branch and to fulfill back port requests, who is volunteering here
> to serving as part of a maintainer group and as contact for release
> specific issues?
I happily volunteer joining the backporting team.
Cheers
Daniel
>
>
> Please provide feedback so that we can agree on a definitive road map
> for branching and for starting the preparations.
>
> Regards,
> Jo
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] per-device rootfs generated on buildbots
Hi! While testing the current snapshot builds I realized that for some reason the additional default packages to be included for each board aren't selected, ie. DEVICE_PACKAGES seems to be ignored in snapshot builds. Ie. eventhough kmod-rtc-ds1307 is set in DEVICE_PACKAGES for the akitio board (oxnas), the package doesn't end up in the generated rootfs and initramfs image for that device. Looking at config.seed, everything looks fine: CONFIG_TARGET_MULTI_PROFILE=y CONFIG_TARGET_ALL_PROFILES=y ... CONFIG_TARGET_PER_DEVICE_ROOTFS=y Any idea? Does that happen on purpose? Is it a bug or a feature? Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Branching LEDE 17.01
Hi! I'd really like to see a rather trivial issue addressed: dnsmasq fails to get notifications on /tmp/resolv.conf.auto changes when running inside ujail. This is because the bind mount obviously won't survive this file being *replaced*, eg. if the DHCP client supplies the DNS server to be used only after dnsmasq has already been started. The easiest solution would be to introduce a directory /tmp/resolv.conf.d/, move all /tmp/resolv.conf* in there and bind mount that into the jail instead. The current /tmp/resolv.conf.auto seems to hardcoded in netifd and appears in dnsmasq's and mwan's default config. Anywhere else? Given the overall code quality of dnsmasq, it would really be nice to at least have it run in a jail by default for the next release... Mentioning the problem to John, he said that the current bind mounting approach will be replaced by a future jailfs he is working on. However, I'm afraid this won't be ready by Friday ;) If there are no objections, I'll suggest a PR introducing /tmp/resolv.conf.d/ and moving the location of /tmp/resolv.conf* into that directory. Cheers Daniel On Tue, Jan 10, 2017 at 04:19:05PM +0100, Jo-Philipp Wich wrote: > Hi guys, > > I'd like to branch off lede-17.01 on Friday, the 13th and would > appreciate if you could merge your outstanding, release critical work > until then. > > If you think we should delay branching, then raise your objections now. > > If no objections are brought up within the next 24 hours, I'll go > forward asking the feed maintainers to create "lede-17.01" branches. > > > Regards, > Jo > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] upstreaming (most) rt2x00 patches
[I had a typo in the lede-dev address in my first attempt to post this] Hi! The amount of patches on top of rt2x00 has grown into a huge pile during the past couple of years. To get things into a shape that allow discussing and merging them upstream, I created a tree on github based on wireless-drivers-next.git: https://github.com/dangowrt/linux/commits/rt2x00-from-openwrt I had to fix up some of Gabor's patches to still apply on the updated code base, but apart from those small fixes, things still apply cleanly on that tree. Imho the patch adding support for MT7620 still needs some more cleaning (I fixed some white-space and indention issues already), and both MT7620 and RT5350 still use mdelay and udelay which should be replaced in the same way done for other codepaths upstream. It'd also be great not to mess up RF and RT, ie. correctly set the RF value for RT5350 and MT7620 according to the actual RF IP used on those chips. Just for clarification, RT6352 was later renamed to MT7620 I for now didn't add any of the EEPROM-related patches, I a suppose that only read_eeprom_from_mtd() should go upstream and all file and firmware-loading mechanics can be considered legacy. I also didn't add any of the device-tree specific stuff, as that will need to be documented (Documentation/devicetree/ofbindings/). However, all the rest should be fine. Maybe the commit messages could be nicer... The goal is to have a nice and clean tree which we can asked to be merged into wireless-drivers-next.git instead of submitting the patches one-by-one via the mailing list. Thus I'm asking for your help: Please review the patches, and also let me know if you had any plans for upstreaming them yourself. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ramips: Add I2C driver to the default kernel config
Just a thought: Isn't there a way to simply have a hotplug handler which calls /sbin/hwclock instead of forcing RTC modules to be built-in? Cheers Daniel On Thu, Jan 12, 2017 at 07:05:00PM -0800, Rosen Penev wrote: > I made a commit that added the RTC driver to the kernel config with > the intent that it would fix hctosys. Unfortunately while the RTC > driver is in there, it's connected through I2C, the driver for which > comes in module form and is thus loaded late. After this commit, it > works fine. > > Signed-off by: Rosen Penev > --- > target/linux/ramips/image/mt7621.mk | 12 +--- > target/linux/ramips/mt7621/config-4.4 | 2 ++ > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index 6d9a727..fd28e19 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -30,7 +30,7 @@ define Device/11acnas >DTS := 11ACNAS >IMAGE_SIZE := $(ralink_default_fw_size_16M) >DEVICE_TITLE := WeVO 11AC NAS Router > - DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-i2c-mt7621 > kmod-mt76 > + DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-mt76 > endef > TARGET_DEVICES += 11acnas > > @@ -83,7 +83,7 @@ define Device/newifi-d1 >DTS := Newifi-D1 >IMAGE_SIZE := $(ralink_default_fw_size_32M) >DEVICE_TITLE := Newifi D1 > - DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-i2c-mt7621 > + DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport > endef > TARGET_DEVICES += newifi-d1 > > @@ -91,8 +91,7 @@ define Device/pbr-m1 >DTS := PBR-M1 >IMAGE_SIZE := $(ralink_default_fw_size_16M) >DEVICE_TITLE := PBR-M1 > - DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core > kmod-ata-ahci \ > - kmod-i2c-mt7621 > + DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core > kmod-ata-ahci > endef > TARGET_DEVICES += pbr-m1 > > @@ -157,7 +156,7 @@ define Device/w2914nsv2 >DTS := W2914NSV2 >IMAGE_SIZE := $(ralink_default_fw_size_16M) >DEVICE_TITLE := WeVO W2914NS v2 > - DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-i2c-mt7621 > kmod-mt76 > + DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-mt76 > endef > TARGET_DEVICES += w2914nsv2 > > @@ -179,8 +178,7 @@ define Device/witi >DTS := WITI >IMAGE_SIZE := $(ralink_default_fw_size_16M) >DEVICE_TITLE := MQmaker WiTi > - DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core > kmod-ata-ahci \ > - kmod-i2c-mt7621 > + DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core > kmod-ata-ahci > endef > TARGET_DEVICES += witi > > diff --git a/target/linux/ramips/mt7621/config-4.4 > b/target/linux/ramips/mt7621/config-4.4 > index 73c3b39..383370b 100644 > --- a/target/linux/ramips/mt7621/config-4.4 > +++ b/target/linux/ramips/mt7621/config-4.4 > @@ -115,6 +115,8 @@ CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y > CONFIG_HIGHMEM=y > CONFIG_HW_HAS_PCI=y > CONFIG_HZ_PERIODIC=y > +CONFIG_I2C=y > +CONFIG_I2C_MT7621=y > # CONFIG_IMG_MDC_DMA is not set > CONFIG_INITRAMFS_SOURCE="" > CONFIG_IRQCHIP=y > -- > 2.9.3 > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 09/14] rt2x00: rt2x00pci: set PCI MWI only if supported
Hi!
On Mon, Jan 16, 2017 at 11:08:57AM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 16, 2017 at 04:06:25AM +0100, Daniel Golle wrote:
> > From: Claudio Mignanti
> >
> > This is needed for devices without support for PCI MWI. See also
> > https://dev.openwrt.org/changeset/21850
> >
> > Signed-off-by: Daniel Golle
> > ---
> > drivers/net/wireless/ralink/rt2x00/rt2x00pci.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
> > b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
> > index eb6dbcd4fddf..4becfeb75ba8 100644
> > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
> > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
> > @@ -94,8 +94,10 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const
> > struct rt2x00_ops *ops)
> >
> > pci_set_master(pci_dev);
> >
> > +#ifdef CONFIG_PCI_SET_MWI
> > if (pci_set_mwi(pci_dev))
> > rt2x00_probe_err("MWI not available\n");
> > +#endif
>
> There is no CONFIG_PCI_SET_MWI in the kernel. This patch is either not
> needed (pci subsystem has own PCI_DISABLE_MWI define) or wrong (we
> should not call this function for some devices).
Is anyone with good long-term memory able to tell why this was needed
in first place? Can we assume it to be obsolete when using modern
kernels?
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 09/14] rt2x00: rt2x00pci: set PCI MWI only if supported
Hi John, On Tue, Jan 17, 2017 at 08:34:44AM +0100, John Crispin wrote: > here is the original thread related to this patch > > http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-November/012227.html nah, that was me apparently trying to submit this upstream once before a couple of years ago. the patch was added by claudio in https://dev.openwrt.org/changeset/21850 supposedly to fix a build error on kernel 2.6.30 https://dev.openwrt.org/ticket/6538 as the config symbol is undefined in current kernels, I reckon we just always had MWI disabled from some point on... Back then RT2X00_LIB_SOC and RT2X00_LIB_MMIO still depended on RT2X00_LIB_PCI which is no longer the case, ie. everything should be fine without that ancient even on non-PCI platforms (on which the build error initially triggered -- rt305x doesn't have PCI at all) So let's remove it and find out :) Cheers Daniel > > John > > > Cheers > > > > > > Daniel > > > >> > >> Stanislaw ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org
Hi! In preparation to be submitted upstream I started to clean up a huge pile of patches for rt2x00 we have been carrying along for quite a while (some for more than half a decade!). Some of them are fixes, most importantly Serge Vasilugin fixed setting the HT20/HT40 filter which got us much closer to the expected performance when using HT40 modes. And also a lot of new added hardware support: Gabor Juhos wrote code for Rt3883 WiSoC. Daniel Golle implemented support for Rt3352 by designs with external PA as well as for boards using a 20MHz crystal instead of the usual 40MHz. Serge Vasilugin contributed support for the Rt5350 WiSoC. Michel Stempin, Felix Fietkau and John Crispin have been helping with cleaning up things and putting away legal doubts. Please review and comment, so we can get those patches merged! Cheers Daniel The following changes since commit cc75c577806a53893122829d91cb122b51643a2d: mwifiex: get rid of global save_adapter and sdio_work (2017-01-12 16:49:18 +0200) are available in the git repository at: https://github.com/dangowrt/linux.git rt2x00-from-openwrt for you to fetch changes up to fb8832d1896475059c964c75ab4baaf94199143c: rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable bit (2017-01-13 04:17:57 +0100) Claudio Mignanti (1): rt2x00: rt2x00pci: set PCI MWI only if supported Daniel Golle (2): rt2x00: support for for RT3352 with external PA rt2x00: add support for RT3352 with 20MHz crystal Felix Fietkau (1): rt2x00: fix rf id for RT3352 Gabor Juhos (34): rt2x00: rt2800lib: move rt2800_drv_data declaration into rt2800lib.h rt2x00: rt2800lib: introduce RT2800_HAS_HIGH_SHARED_MEM flag rt2x00: rt2800: serialize shared memory access rt2x00: rt2800lib: fix beacon generation on RT3593 rt2x00: rt2800lib: add hw_beacon_count field to struct rt2800_drv_data rt2x00: rt2800lib: init additional beacon offset registers rt2x00: rt2800lib: fix max supported beacon count for RT3593 rt2x00: allow to build rt2800soc module for RT3883 rt2x00: rt2800lib: enable support for RT3883 rt2x00: rt2800lib: add rf_vals for RF3853 rt2x00: rt2800lib: enable VCO calibration for RF3853 rt2x00: rt2800lib: add channel configuration function for RF3853 rt2x00: rt2800lib: enable RF3853 support rt2x00: rt2800lib: add MAC register initialization for RT3883 rt2x00: rt2800soc: fix rt2800soc_disable_radio for RT3883 rt2x00: rt2800lib: add BBP register initialization for RT3883 rt2x00: rt2800lib: add RFCSR initialization for RT3883 rt2x00: rt2800lib: use the extended EEPROM map for RT3883 rt2x00: rt2800lib: force rf type to RF3853 on RT3883 rt2x00: rt2800lib: add channel configuration code for RT3883 rt2x00: rt2800lib: fix txpower_to_dev function for RT3883 rt2x00: rt2800lib: use correct txpower calculation function for RT3883 rt2x00: rt2800lib: hardcode txmixer gain values to zero for RT3883 rt2x00: rt2800lib: use correct [RT]XWI size for RT3883 rt2x00: rt2800lib: use correct beacon base for RT3883 rt2x00: rt2800lib: use correct beacon count for RT3883 rt2x00: rt2800lib: fix antenna configuration for RT3883 rt2x00: rt2800lib: fix LNA gain configuration for RT3883 rt2x00: rt2800lib: fix VGC setup for RT3883 rt2x00: rt2800lib: fix EEPROM LNA validation for RT3883 rt2x00: rt2800lib: fix txpower compensation for RT3883 rt2x00: rt2800lib: enable RT2800_HAS_HIGH_SHARED_MEM for RT3883 rt2x00: rt2800lib: use high memory for beacons on RT3883 rt2x00: rt2800mmio: add a workaround for spurious TX_FIFO_STATUS interrupts Michel Stempin (1): rt2x00: add support for RT5350 WiSoC Serge Vasilugin (1): rt2x00 correctly set ht20/ht40 filter evaxige (1): rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable bit drivers/net/wireless/ralink/rt2x00/Kconfig |2 +- drivers/net/wireless/ralink/rt2x00/rt2800.h | 79 +- drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1006 ++- drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 63 ++ drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 98 ++- drivers/net/wireless/ralink/rt2x00/rt2800mmio.h |4 + drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 14 + drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 12 +- drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 31 + drivers/net/wireless/ralink/rt2x00/rt2x00.h | 10 + drivers/net/wireless/ralink/rt2x00/rt2x00dev.c |7 +- drivers/net/wireless/ralink/rt2x00/rt2x00mac.c |8 +- drivers/net/wireless/ralink/rt2x00/rt2x00pci.c |2 + 13 files changed, 1254 insertions(+), 82 deletions(-) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org
Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org
Hi Kalle, On Fri, Jan 13, 2017 at 12:46:56PM +0200, Kalle Valo wrote: > Daniel Golle writes: > > ... > > Please review and comment, so we can get those patches merged! > > No pull requests, please. Instead send these as patches, easier to > review and actually also easier for me to merge. The advantage of pull requests is that author information can be preserved more easily. Running git format-patch results in most patches having wrong SMTP sender information due to the assumption that the patch author is the same person also submitting the patch. So in practise, this would either require changing the From: (and thus Author) to myself or having most mails eaten by anti-spam measures due to non-matching SPF which prohibits my SMTP to send mail on behalf of the original authors of the patches. How do you suggest to handle this situation? Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org
On Fri, Jan 13, 2017 at 04:59:59PM +0100, Johannes Berg wrote: > > > The advantage of pull requests is that author information can be > > preserved more easily. Running git format-patch results in most > > patches > > having wrong SMTP sender information due to the assumption that the > > patch author is the same person also submitting the patch. > > So in practise, this would either require changing the From: (and > > thus > > Author) to myself or having most mails eaten by anti-spam measures > > due > > to non-matching SPF which prohibits my SMTP to send mail on behalf of > > the original authors of the patches. > > > > This is completely untrue. If the first line of the *body* of the email > is "From: ..." then this is preserved as the author information by git > am, and doing so is also the default in git format-patch/send-email > when the author doesn't match the email configuration. Thanks for the clarification, I'll then submit the patches via git format-patch. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org
On Fri, Jan 13, 2017 at 05:17:23PM +0100, Daniel Golle wrote: > On Fri, Jan 13, 2017 at 04:59:59PM +0100, Johannes Berg wrote: > > > > > The advantage of pull requests is that author information can be > > > preserved more easily. Running git format-patch results in most > > > patches > > > having wrong SMTP sender information due to the assumption that the > > > patch author is the same person also submitting the patch. > > > So in practise, this would either require changing the From: (and > > > thus > > > Author) to myself or having most mails eaten by anti-spam measures > > > due > > > to non-matching SPF which prohibits my SMTP to send mail on behalf of > > > the original authors of the patches. > > > > > > > This is completely untrue. If the first line of the *body* of the email > > is "From: ..." then this is preserved as the author information by git > > am, and doing so is also the default in git format-patch/send-email > > when the author doesn't match the email configuration. > > Thanks for the clarification, I'll then submit the patches via > git format-patch. I posted all patches on the mailing list and bundled them up on patchwork. https://patchwork.kernel.org/bundle/dangole/rt2x00-from-openwrt/ Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Patch to iwinfo to add the ability to load backends from external .so modules
Hi! Please resend your patches with git format-patch or git send-email instead of attaching them as files. This will make sure that people actually get to see them and that they will get listed in our patchwork instance [1]. When doing so, please include 'iwinfo' in the mails' subject prefixes, ie. [PATCH iwinfo 1/2] external foo If you are for some reason unable to submit your work in this way, please let us know, so someone else can pick up your patches and resubmit them in this way so they will get reviewed and eventually get merged. Cheers Daniel [1]: http://patchwork.ozlabs.org/project/lede/list/ On Mon, Jan 23, 2017 at 04:00:53PM -0800, Patrick Martin wrote: > I think I attached the wrong patch file, here are the two patches to > apply that are corrected. > > On Mon, Jan 23, 2017 at 3:38 PM, Patrick Martin > wrote: > > Hello, > > > > I'm submitting a patch to iwinfo that loads external .so files from > > /usr/lib/iwinfo to allow for the addition of binary backends via > > packages, I set it up to be as isolated from the other code in iwinfo > > so as to not affect anything you guys might be working on with it. > > this patch (or something similar) is needed in order to add the > > ability to read info about the Quantenna radio in the driver packages > > i'm working on. This was made on jow's (i think it was jow at least) > > suggestion. > > > > Patrick Martin > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ramips: Add patch to reset SPI flash to 3-byte addressing
Hi Alexandru,
On Mon, Jan 30, 2017 at 02:53:43PM -0800, Alexandru Gagniuc wrote:
> This patch is designed to workaround an issue where an mt7620 will
> hang after a reboot. This happens because the bootrom gets confused
> when the SPI flash is left in 4-byte addressing mode. This change
> makes sure that we can reboot the system under normal circumstances,
> but does not protect against system crashes.
NACK. This should not be needed and also doesn't provide a reliable
method to avoid the problem you describe, please rather try
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3274ba26f27becfc4193ec6e229288140651f240
In case you are aware of boards which neither implement a proper
reset of the flash chip nor use a flash chip which supports dedicated
4-byte opcodes, please let us know, in that case the fix might still
be needed and at least provide a best-effort solution (which may still
result in stuck under certain circumstances such as CPU resets
triggered by watchdogs or in any way out of the kernel's control)
Cheers
Daniel
>
> Signed-off-by: Alexandru Gagniuc
> ---
> ...Reset-chip-to-3-byte-addressing-on-system.patch | 65
> ++
> 1 file changed, 65 insertions(+)
> create mode 100644
> target/linux/ramips/patches-4.4/0800-mtd-m25p80-Reset-chip-to-3-byte-addressing-on-system.patch
>
> diff --git
> a/target/linux/ramips/patches-4.4/0800-mtd-m25p80-Reset-chip-to-3-byte-addressing-on-system.patch
>
> b/target/linux/ramips/patches-4.4/0800-mtd-m25p80-Reset-chip-to-3-byte-addressing-on-system.patch
> new file mode 100644
> index 000..de4ee2c
> --- /dev/null
> +++
> b/target/linux/ramips/patches-4.4/0800-mtd-m25p80-Reset-chip-to-3-byte-addressing-on-system.patch
> @@ -0,0 +1,65 @@
> +From 0f7fcc3dfc27a91e7672e9e589f3f558e8c41737 Mon Sep 17 00:00:00 2001
> +From: Alexandru Gagniuc
> +Date: Mon, 30 Jan 2017 13:30:33 -0800
> +Subject: [PATCH] mtd: m25p80: Reset chip to 3-byte addressing on system
> reboot
> +
> +Some SOCs can not handle 4-byte addressing in their mask ROM. On such
> +devices if we leave the SPI flash in 4-byte mode, then reboot the
> +system, the device will not boot.
> +
> +Some SoCs have a special output to reset all the on-board peripherals.
> +This pin should be connected to the !RESET pin of the flash as well.
> +Unfortunately, not all boards implement this. As a workaround for such
> +hardware, reset the SPI flash to 3-byte addressing mode. This does not
> +protect against system crashes, but it does allow the system to reboot
> +in the case of a normal reboot.
> +
> +Cc: Paul Fertser
> +Signed-off-by: Alexandru Gagniuc
> +---
> + drivers/mtd/devices/m25p80.c | 15 +++
> + 1 file changed, 15 insertions(+)
> +
> +diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> +index fe9ceb7..2151975 100644
> +--- a/drivers/mtd/devices/m25p80.c
> b/drivers/mtd/devices/m25p80.c
> +@@ -27,6 +27,9 @@
> + #include
> + #include
> +
> ++#define OPCODE_RESET_ENABLE 0x66
> ++#define OPCODE_RESET0x99
> ++
> + #define MAX_CMD_SIZE6
> + struct m25p {
> + struct spi_device *spi;
> +@@ -168,6 +171,17 @@ static int m25p80_erase(struct spi_nor *nor, loff_t
> offset)
> + return 0;
> + }
> +
> ++void m25p80_reboot(struct mtd_info *mtd)
> ++{
> ++struct spi_nor *nor = container_of(mtd, struct spi_nor, mtd);
> ++struct m25p *flash = nor->priv;
> ++
> ++flash->command[0] = OPCODE_RESET_ENABLE;
> ++spi_write(flash->spi, flash->command, 1);
> ++flash->command[0] = OPCODE_RESET;
> ++spi_write(flash->spi, flash->command, 1);
> ++}
> ++
> + /*
> + * board specific setup should have ensured the SPI clock used here
> + * matches what the READ command supports, at least until this driver
> +@@ -197,6 +211,7 @@ static int m25p_probe(struct spi_device *spi)
> + nor->erase = m25p80_erase;
> + nor->write_reg = m25p80_write_reg;
> + nor->read_reg = m25p80_read_reg;
> ++nor->mtd._reboot = m25p80_reboot;
> +
> + nor->dev = &spi->dev;
> + nor->flash_node = spi->dev.of_node;
> +--
> +2.9.3
> +
> --
> 2.9.3
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release Candidate Test Plan - first draft
Hi! Tested the release candidate on octeon/erlite, most things work nicely so far. Upgrading from 15.05 was tricky though because octeon_board_name is broken in 15.05 and i needed to manually fix it so sysupgrade would work (octeon_board_name() returned 'cavium,octeon-3860' instead of 'erlite' on 15.05) Imho we should make a note on each board which successfully booted the release and make a note whether it was flashed using sysupgrade or factory method and if any hacks or special work-arounds were needed, ie stuff like the octeon_board_name problem mentioned above... Package problems: (I) dnsmasq REFUSED queries no matter from which interface they came. I replaced it with unbound and odhcpd which solved the problem. 16:31:38.423896 IP 192.168.225.237.56085 > 192.168.225.1.domain: 56063+ A? google.com. (28) 16:31:38.427000 IP 192.168.225.1.domain > 192.168.225.237.56085: 56063 Refused 0/0/0 (28) The same configuration worked without any problem for almost a year with more than 100 days uptime on 15.05. (II) openvpn-mbedtls didn't like my vpn server for some reason: The certificate is signed with an unacceptable hash. openvpn-openssl worked without any problems. Should I file bugs for those openvpn-mbedtls and dnsmasq problems? In case of openvpn-mbedtls I'm not sure whether it is a bug or a feature... Cheers Daniel On Mon, Jan 30, 2017 at 03:14:08PM -0500, Rich Brown wrote: > Folks, > > There have been a couple questions on the forum about what needs to be tested > in the LEDE release candidate. > > I put together a draft of a note that lists how to install, what to test, and > how to report problems. It's at: > https://lede-project.org/playground/releasecandidatetestplan > > Comments, updates, etc. welcomed. > > Rich > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH LEDE-17.01] kernel: bump to 4.4.46
This backports kernel bump commits from master branch into lede-17.01
20996edd68 Kernel: bump to 4.4.44
4d1515070b kernel: bump to 4.4.45
3becadd56c kernel: bump to 4.4.46
Refreshed patches for all supported targets, references to the chipidea
USB driver used to support usbgadget mode on ar71xx have been removed
since that feature is not part of the LEDE 17.01 release.
Fixes CVE-2016-8405, CVE-2016-9191, CVE-2017-2583, CVE-2017-2584 as
well as a fix for a fix related to CVE-2016-7097.
Tested-by: Stijn Segers
Signed-off-by: Stijn Segers
Signed-off-by: Koen Vandeputte
Signed-off-by: Daniel Golle
---
include/kernel-version.mk | 4 ++--
.../patches-4.4/910-unaligned_access_hacks.patch | 4 ++--
.../0111-mm-Remove-the-PFN-busy-warning.patch | 2 +-
...R2PEER-to-set-MRSS-128-to-fix-CNS3xxx-BM-DMA..patch | 2 +-
.../cns3xxx/patches-4.4/200-broadcom_phy_reinit.patch | 4 ++--
.../680-NET-skip-GRO-for-foreign-MAC-addresses.patch | 10 +-
...10-serial-imx-repair-and-complete-handshaking.patch | 16 ++--
.../111-serial-imx-fix-polarity-of-RI.patch| 7 +--
...imx-let-irq-handler-return-IRQ_NONE-if-no-eve.patch | 9 ++---
...ial-imx-make-sure-unhandled-irqs-are-disabled.patch | 7 +--
...hci-mediatek-support-MTK-xHCI-host-controller.patch | 8
...hci-mediatek-support-MTK-xHCI-host-controller.patch | 8
...1-sp5100_tco-Add-AMD-Mullins-platform-support.patch | 6 +-
...2-sp5100_tco-Add-AMD-Carrizo-platform-support.patch | 6 +-
...the-device-check-for-SB800-and-later-chipsets.patch | 18 +++---
...g-sp5100_tco-properly-check-for-new-register-.patch | 12
16 files changed, 44 insertions(+), 79 deletions(-)
diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index efd58e1462..e06841dbad 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,10 +3,10 @@
LINUX_RELEASE?=1
LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .42
+LINUX_VERSION-4.4 = .46
LINUX_KERNEL_HASH-3.18.43 =
1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.42 =
324747568e92f203e3ee5ec8b291a868f58b870f1ad214fa64aa3507ed42e878
+LINUX_KERNEL_HASH-4.4.46 =
bb944846c5901aa2cadaa20c3d953ec03ff707dc1178e6ac3851e98747872058
ifdef KERNEL_PATCHVER
LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git a/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
b/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
index 21cad91161..2c014429f2 100644
--- a/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
+++ b/target/linux/ar71xx/patches-4.4/910-unaligned_access_hacks.patch
@@ -491,7 +491,7 @@
memcpy(p, foc->val, foc->len);
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
-@@ -500,7 +500,7 @@ static struct sk_buff *add_grec(struct s
+@@ -505,7 +505,7 @@ static struct sk_buff *add_grec(struct s
if (!skb)
return NULL;
psrc = (__be32 *)skb_put(skb, sizeof(__be32));
@@ -610,7 +610,7 @@
goto next_ht;
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
-@@ -221,7 +221,7 @@ static struct sk_buff **ipv6_gro_receive
+@@ -222,7 +222,7 @@ static struct sk_buff **ipv6_gro_receive
continue;
iph2 = (struct ipv6hdr *)(p->data + off);
diff --git
a/target/linux/brcm2708/patches-4.4/0111-mm-Remove-the-PFN-busy-warning.patch
b/target/linux/brcm2708/patches-4.4/0111-mm-Remove-the-PFN-busy-warning.patch
index f643ec883c..a0602807ba 100644
---
a/target/linux/brcm2708/patches-4.4/0111-mm-Remove-the-PFN-busy-warning.patch
+++
b/target/linux/brcm2708/patches-4.4/0111-mm-Remove-the-PFN-busy-warning.patch
@@ -14,7 +14,7 @@ Signed-off-by: Eric Anholt
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
-@@ -6782,8 +6782,6 @@ int alloc_contig_range(unsigned long sta
+@@ -6785,8 +6785,6 @@ int alloc_contig_range(unsigned long sta
/* Make sure the range is really isolated. */
if (test_pages_isolated(outer_start, end, false)) {
diff --git
a/target/linux/cns3xxx/patches-4.4/130-Extend-PCIE_BUS_PEER2PEER-to-set-MRSS-128-to-fix-CNS3xxx-BM-DMA..patch
b/target/linux/cns3xxx/patches-4.4/130-Extend-PCIE_BUS_PEER2PEER-to-set-MRSS-128-to-fix-CNS3xxx-BM-DMA..patch
index c58830ac6f..db2c29fc92 100644
---
a/target/linux/cns3xxx/patches-4.4/130-Extend-PCIE_BUS_PEER2PEER-to-set-MRSS-128-to-fix-CNS3xxx-BM-DMA..patch
+++
b/target/linux/cns3xxx/patches-4.4/130-Extend-PCIE_BUS_PEER2PEER-to-set-MRSS-128-to-fix-CNS3xxx-BM-DMA..patch
@@ -1,6 +1,6 @@
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
-@@ -1964,7 +1964,8 @@ static void pcie_write_mrrs(struct pci_d
+@@ -1966,7 +1966,8 @@ static void pcie_write_mrrs(struct pci_d
/* In the "safe" case, do not configure the MRRS. There appear to be
* issue
[LEDE-DEV] NETSHe mac80211 GPL sources
Hi! NETSHe offers a modified version of ath9k, mac80211 and cfg80211 which offers support for TDMA, see: http://netshe.ru/files/doc/en/TDMA_brief_en.pdf Where to download the sourcecode of mac80211 and the modified drivers? Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] NETSHe mac80211 GPL sources
Hi Stas, thanks for the quick reply! I'm looking for a good way to replace ubiquiti's proprietary TDMA implementation with something which could be vendor-independent and interoperable -- and ideally Free Open Source Software. As TDMA has been implemented for ath9k in FreeBSD, I was wondering if a similar extension to mac80211 has been made -- and found NETSHe's wireless stack. As ath9k, mac80211 and the Linux kernel are under the GPL license, I was assuming that NETSHe's modifications to support TDMA thus must be available under the GPL licensed as well. So from what I understand you are using your own proprietary driver instead of ath9k? Yet, cfg80211 and mac80211 seem to be involved according to what I found in TDMA_brief_en.pdf, as TDMA interfaces are added obviously added through nl80211. Earlier today I also realised that this has previously been discussed on this mailing list, see https://lists.openwrt.org/pipermail/openwrt-devel/2015-July/034374.html As you are offering a binary version of the firmware for download, according to the GPL you are oblidged to also share the portion of the source code which is under GPL (ie. at least the Linux kernel, GPL'ed wireless drivers like ath9k, libnl, the 'iw' userspace, ...) as well as all modifications you've made to that GPL licensed code. Obviously you could easily avoid that legal requirement by just not offering a free download of the binaries, so don't get me wrong, I do appreciate your openness! Yet, it'd be great if we had a shared codebase for TDMA instead of a growing number of competing implementations (ubnt, mikrotik, Deliberant's iPoll, NETSHe, ...) each being developed behind closed doors. As your implementation is built upon GPL'ed code and you offer binaries for download, please also share the patches for iw, libnl, cfg80211, mac80211 and ath*k. By the end of the day, you are using 99% code which other people have written and published under the assumption that everyone is granted the freedom to run, study, share and modify the software. "The GPL is a copyleft license, which means that derivative work can only be distributed under the same license terms." [1] However, I'm not a lawyer and I have simply no idea if the GPL can actually be enforced in the judicative domain NETSHe is located in or whether we are talking about a purely idealistic/moralic issue here. Anywa, my interest is to use and improve that code! Friends of mine have started a non-profit collaborative ISP project [2] and we are having a heated debate whether to use OpenWrt/LEDE from source or ubnt's proprietary firmware on ubnt and other ath9k-based hardware. Even though Wifi performance on ath9k recently improved a lot, a TDMA implementation under a free license (ie. GPL) would be great thing to have, also for use in Wireless Community Mesh Networks. A good compromise could be to publish the code without the userspace tools allowing AES crypto -- in that way, free community networks can use that implementation and commercial entities would need to license the crypto bits if they want link-level crypto. Cheers Daniel [1]: https://en.wikipedia.org/wiki/GNU_General_Public_License [2]: https://www.reudnetz.org/ On Fri, Feb 03, 2017 at 09:35:30AM +0300, Stanislav V. Korsakov wrote: > Hi Daniel, > > Please check this article http://netshe.ru/wirelessstack to understand > layering of our modifications in Linux wireless stack. You can see that > we add proprietary licensed and dual licensed drivers in wireless stack. > We provide our GPLed and dual licensed source codes to our customer only. > Not our source code is available at http://gw.stasoft.net/dl/ > > Can you tell me what is your real interest? > > Regards, Stas > > > On 03.02.2017 03:43, Daniel Golle wrote: > > Hi! > > > > NETSHe offers a modified version of ath9k, mac80211 and cfg80211 which > > offers support for TDMA, see: > > http://netshe.ru/files/doc/en/TDMA_brief_en.pdf > > > > Where to download the sourcecode of mac80211 and the modified drivers? > > > > > > Cheers > > > > > > Daniel > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] NETSHe mac80211 GPL sources
Hi Alberto, On Fri, Feb 03, 2017 at 10:59:38AM +, Alberto Bursi wrote: > > > On 02/03/2017 07:35 AM, Stanislav V. Korsakov wrote: > > Hi Daniel, > > > > We provide our GPLed and dual licensed source codes to our customer only. > > Not our source code is available at http://gw.stasoft.net/dl/ > > > > What you wrote here sounds like a license violation. > Source code of GPLed software you use *must* be provided to everyone > that asks it, not just to customers. > That's what the GPL license requires. Strictly speaking, it must be provided to anyone who also got access to the binary. So, if you offer a free download of the binary, you must provide the sources under the same terms. Ie. by downloading the binaries from the website, that makes me a customer entitled to ask for the sources. However, if you provide the binaries only to customers or keep them "in-house" (that's what most telcos do), only the parties which were handed the binaries can ask for the sources, that's at least how I understood the GPLv2. Cheers Daniel > > -Alberto > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MT7620A WiFi issue - with a twist!
Hi Weedy, On Fri, Feb 03, 2017 at 07:49:22PM -0500, Weedy wrote: > On 1 February 2017 at 15:29, Jamie Stuart wrote: > > Hello LEDE / OpenWRT devs, > > > > I am requesting your help. First a little background… > ... > > This a known issue with the chipset and seems to have been round for years. > > We are currently building on LEDE trunk and still the issue persists. > > > > We are not driver developers, so my question is whether anyone with > > knowledge can help and provide a proper fix for this issue? > > > You will probably have the most luck posting a bounty on the linux > wifi mailing list. As a response to the many issues and obvious code quality problems in the patch adding support for MT7620 to rt2x00 I started a kickstarter project to fund an afternoon or two (depending on the amount people throw into my hat) of focussing on rt2x00 running on MT7620: https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede > > Your root problem is picking a platform that basically uses a client > mode tested driver in AP mode and then hanging a million clients off > of it. I'm honestly surprised it didn't fall over sooner. Well, rt2x00 is used for both AP and Client mode, and afaik there wasn't a lot of testing for either mode of operation. And AP mode has recently seen quite a bunch of improvements. Having seperate drivers for AP and STA is a common strategy of chip makers to devide-and-conquer QA and also add product differentiation, ie. sell the same hardware for more if it is used for specific tasks. Thus Ralink used to give away the station-mode driver for free and used to charge people for the AP-mode driver (they do share a common codebase). The bigger issue here is that Ralink's WiFi chip design is flawed when using the chips in multi-STA modes (AP, Adhoc, Mesh) because instead of having a way to set parameters for each associated station it only allows it to be set globally, see [1] for an example of how rt2x00 thus needs to limit the hardware to use the parameters of the weakest associated station (the vendor driver does the same). > > May I suggest when it comes time to refresh the hardware you guys pick > something with NGFF or mini-pcie slots for ALL radios. +1 Though I personally don't believe it's ever going to get as chaotic and complex as for the final generation of Ralink's WiFi chips (ie. which later became MT76x0). Ralink/Mediatek's newer chips are much cleaner and don't share the same issues. Cheers Daniel [1] https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/drivers/net/wireless/ralink/rt2x00/rt2800lib.c?id=8f03a7c6e7f959edd22e35158fbb9a4087962fae ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] MT7620A WiFi issue - with a twist!
Hi Juergen, On Sat, Feb 04, 2017 at 08:32:36AM +0100, Juergen Kimmel wrote: > Hello everyone, > I'm in the same boat struggeling with mt7620a WiFi performance, > namely with the device called ZBT APE522ii. > Stock firmware based on Openwrt (has no version number) has no issues > concerning wifi performance. That's because ZBT ships their devices with a firmware containing Mediatek/Ralink's proprietary driver as well as the needed proprietary user-space tools. However, this driver only supports either (multi-SSID) AP-mode or Station-mode, but not both at the same time. > > Because I`m focussing on a mesh solution, I tested Openwrt/Lede based > qMp (qmp.cat) but having the same issues described here. That's not surprising, unfortunately. > IMHO there must be different drivers to be used. My skills are not at > all sufficient to clear where the difference could be. The main problem here is that rt2860_ap driver (which was at least partially also published under GPLv2 terms, you can find it on github) cannot do AdHoc mode which is needed for mesh stuff. > So help is very much appreciated. I'll be working on sorting things out for MT7620 once the kickstarter project I created for that purpose reaches its goal. Cheers Daniel > > 2017-02-04 2:27 GMT+01:00 Juergen Kimmel : > > Hello everyone, > > I'm in the same boat struggeling with mt7620a WiFi performance, namely with > > the device called > > ZBT APE522ii. > > Stock firmware based on Openwrt (no version number) has no issues concerning > > wifi performance. > > > > Because I`m focussing on a mesh solution, I tested Openwrt/Lede based qMp > > (qmp.cat) but having the same issues described here. > > IMHO there must be different drivers used. My skills are not at all > > sufficient to clear where the difference could be. > > So help is very much appreciated. > > > > > > Weedy schrieb am Sa., 4. Feb. 2017 01:51: > >> > >> On 1 February 2017 at 15:29, Jamie Stuart wrote: > >> > Hello LEDE / OpenWRT devs, > >> > > >> > I am requesting your help. First a little background… > >> ... > >> > This a known issue with the chipset and seems to have been round for > >> > years. > >> > We are currently building on LEDE trunk and still the issue persists. > >> > > >> > We are not driver developers, so my question is whether anyone with > >> > knowledge can help and provide a proper fix for this issue? > >> > >> > >> You will probably have the most luck posting a bounty on the linux > >> wifi mailing list. > >> > >> Your root problem is picking a platform that basically uses a client > >> mode tested driver in AP mode and then hanging a million clients off > >> of it. I'm honestly surprised it didn't fall over sooner. > >> > >> May I suggest when it comes time to refresh the hardware you guys pick > >> something with NGFF or mini-pcie slots for ALL radios. > >> > >> ___ > >> Lede-dev mailing list > >> Lede-dev@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/lede-dev > > > > -- > Mit freundlichen Grüssen > > Jürgen Kimmel > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] NETSHe mac80211 GPL sources
Hi Stas, On Fri, Feb 03, 2017 at 03:58:15PM +0300, Stanislav V. Korsakov wrote: > Hi Daniel, > > Why do you think that all our TDMA-related modifications must be under > GPL license? As you are using cfg80211 and mac80211 I just guessed that chances are high that you'd also use ath9k and modified it. > > We use cfg80211, mac80211, ath5k and ath9k with very small modifications > to support new type of interface and to handle some new netlink commands. > We call own dual licensed module from mac80211 to handle new type of > interface. Some code to provide new functionality is placed in our > proprietary licensed driver. This driver does not use any GPL exported > calls/symbols from the kernel and other drivers. Code from this module > is used from our dual licensed module only. This module taints kernel. > > In our mind, we do not breach GPL v2 with this architecture. > Thus, we have two parts of source code: > 1. GPLed and dual-licensed. We provide this source code to our > customers. Any customer can open GPLed part if he wish to do it. Why > should we provide it for everyone (not customers)? Please point me to > GPL v2 license term which has this requirements. Not your interpretation. > 2. Closed source for our proprietary module. Ok, thanks a lot for the clarifications. That's indeed a clean solution as far as I can judge. > > We do not share our binaries for everyone since v3.2. All GPLed code > (including patches) is available in a free access for v3.2. Is that the code on sourceforge.net? > > At least, we try to keep copyrights and software licenses and I do not > see license breaches now. You can find what we build our firmware, what > we used and how. E.g. how we use OpenWRT and what is the difference. We > do not hide it. > If you found breaches - inform me to cancel. That's not the road I'm going for ;) I'm just interested in code, I am not an expert on legal/license things. > > About idealistic... > I did not see long time and effective working just for fun only... > Programmers want to eat... Of course, same here. From a labour perspective FOSS can also be seen as quite a nightmare -- not long ago, companies needed to hire people and then educate them while paying them. Today, you're expected to be self-educated and nobody cares how people are feeding themselves while studying free software code... > Open source is very good and helpful thing. Let discuss how we can help > but keep in mind that we need to earn money too. Imho this conversation can already be seen as a contribution. To avoid confusion in future, it'd be great if you made sure that the GPL'ed part of the sources can be found right next to the binaries as well as on webpages linking to those binaries. Another good concept could be to make sure stuff goes public once you longer have commercial interest in it. That will allow e.g. securiy audits of outdated gear in the field and also help future generations to understand history and evolution of software. CodeWeavers and the wine folks get's that right, imho, but it's a rare thing. Most of the time, stuff just disappears and future researchers are left in the dark when the try to figure out what happened 10 years ago. > > Excuse me my bad English. Hope, I explained our point of view... No worries, your English is good and I didn't have any problems understanding what you were writing. Thank you for your time and for explaining things! > > Now about implementation details if it still interesting... > > Our implementation is completely different from Ubiquiti or FreeBSD's. > In my mind, first uses PCF mode variation. Second is original but i do > not impress how it works in noisy environment. > For our implementation, closest mode is AdHoc with own scheduler. > Scheduler is implemented in software completely. > Our implementation is well for narrow channels and not big mesh networks > (and we do own mesh implementation above TDMA) but lost efficiency with > wide channels. We can not utilize HT/VHT and have bigger delay by design. That's indeed quite different from what I expected. But surely makes sense for long-distance links where QoS and reliability is a most, I imagine that VoIP should work very well using your solution. However, for the purpose I had in mind (wireless community ISP in urban areas) I'd rather have MiMo and more throughput as links are rather short compared to what you are doing. Nevertheless, I'm impressed by your report of 30km+ stable links! Cheers Daniel > > Regards, Stas > > > On 03.02.2017 13:40, Daniel Golle wrote: > > Hi Stas, > > > > thanks for the quick reply! > > > > I'm looking for a good way to replace ubiquiti's proprietary TDMA > > implem
Re: [LEDE-DEV] [OpenWrt-Devel] MT7620A WiFi issue - with a twist!
Hi Alberto, On Sun, Feb 05, 2017 at 02:27:06PM +, Alberto Bursi wrote: > On 02/04/2017 07:11 PM, Daniel Golle wrote: > > As a response to the many issues and obvious code quality problems in > > the patch adding support for MT7620 to rt2x00 I started a kickstarter > > project to fund an afternoon or two (depending on the amount people > > throw into my hat) of focussing on rt2x00 running on MT7620: > > > > https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede > > > Might be a good idea to send a mail to Micheael Larabel, the guy running > Phoronix.com (linux-oriented news and benchmarks site), so he can write > an article to raise awareness for that kickstarter project. > http://www.phoronix-media.com/?k=contact > Or other linux-oriented news sites that might be interested. It's the first time I'm trying to get work compensated by the community and I'm not sure whether kickstarter is the right way to go -- though I've written clearly that the initial goal would cover one night of hacking on rt2x00 and additional funds would pay for additional hours, I'm not sure whether everyone got that. Maybe I'll just need to stop at some point today, because by now, I've been working on MT7620- related stuff for more hours than I'd ever work for that amount of money. Surely, my motivation isn't purely economic in that case, I actually have some idealistic and educational goals as well, which is also why I started upstreaming the rt2x00 patches. However, I also don't want to leave the impression that I'd work for less than minimum wage on stuff which I'm only capable of doing because I've been hacking on kernel code for something like a decade by now. And as it looks like right now, this can work for a weekend, but cannot become a habbit, simply because I can't afford that luxury if it only pays the minimum I've been asking for initially -- probably I just need to create new projects on kickstarter for each phase of work, but that also seems like a lot of overhead given that I'd rather work on code than spending time on a rather annoying JavaScript-application running in my browser and eating half of the RAM of my machine... So if you now any better method or service than kickstarter which allows me to follow the street-musician-protocol while hacking on FOSS code, that'd be highly appreciated. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ramips: replace remaining instances of ralink, port-map
Some boards were apparently forgotten when ralink,portmap was renamed
to mediatek,portmap -- probably because they used the long obsolete
ralink,port-map attribute.
If this commit breaks ethernet wan/lan assignment, this is because
the port-map attribute wasn't actually parsed, you'll have to replace
"w" by "w" in the dts file belonging to that board (and send
a patch doing that!)
Signed-off-by: Daniel Golle
---
Having a closer look now I find it very confusing that a numerical
value is used on rt305x devices which the (supposedly) legacy string
value is used by mt762x based boards. This also prevents unused ports
from being disabled, which could be nice for power/heat management
reasons, at least that helped quite a on previous generation chips.
target/linux/ramips/dts/D240.dts | 2 +-
target/linux/ramips/dts/GL-MT300A.dts | 2 +-
target/linux/ramips/dts/GL-MT300N.dts | 2 +-
target/linux/ramips/dts/GL-MT750.dts | 2 +-
target/linux/ramips/dts/MAC1200RV2.dts | 2 +-
target/linux/ramips/dts/NBG-419N2.dts | 2 +-
target/linux/ramips/dts/WL-WN575A3.dts | 2 +-
target/linux/ramips/dts/WRTNODE2.dtsi | 2 +-
target/linux/ramips/dts/ZBT-WE826.dts | 2 +-
target/linux/ramips/dts/kn_rc.dts | 2 +-
target/linux/ramips/dts/kn_rf.dts | 2 +-
11 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
index 3da96f2a9e..ef45d38e61 100644
--- a/target/linux/ramips/dts/D240.dts
+++ b/target/linux/ramips/dts/D240.dts
@@ -136,7 +136,7 @@
ðernet {
mtd-mac-address = <&factory 0x4>;
- ralink,port-map = "w";
+ mediatek,portmap = "w";
};
&wmac {
diff --git a/target/linux/ramips/dts/GL-MT300A.dts
b/target/linux/ramips/dts/GL-MT300A.dts
index a700558a03..d4c8351f1e 100644
--- a/target/linux/ramips/dts/GL-MT300A.dts
+++ b/target/linux/ramips/dts/GL-MT300A.dts
@@ -133,7 +133,7 @@
pinctrl-names = "default";
pinctrl-0 = <&ephy_pins>;
mtd-mac-address = <&factory 0x4000>;
- ralink,port-map = "w";
+ mediatek,portmap = "w";
};
&wmac {
diff --git a/target/linux/ramips/dts/GL-MT300N.dts
b/target/linux/ramips/dts/GL-MT300N.dts
index be78a72b50..927ea54d0e 100644
--- a/target/linux/ramips/dts/GL-MT300N.dts
+++ b/target/linux/ramips/dts/GL-MT300N.dts
@@ -122,7 +122,7 @@
ðernet {
mtd-mac-address = <&factory 0x4000>;
- ralink,port-map = "w";
+ mediatek,portmap = "w";
};
&wmac {
diff --git a/target/linux/ramips/dts/GL-MT750.dts
b/target/linux/ramips/dts/GL-MT750.dts
index ad1e3f9173..1266dd3230 100644
--- a/target/linux/ramips/dts/GL-MT750.dts
+++ b/target/linux/ramips/dts/GL-MT750.dts
@@ -128,7 +128,7 @@
pinctrl-names = "default";
pinctrl-0 = <&ephy_pins>;
mtd-mac-address = <&factory 0x4000>;
- ralink,port-map = "w";
+ mediatek,portmap = "w";
};
&wmac {
diff --git a/target/linux/ramips/dts/MAC1200RV2.dts
b/target/linux/ramips/dts/MAC1200RV2.dts
index 73ba493c5d..6d58b25b87 100644
--- a/target/linux/ramips/dts/MAC1200RV2.dts
+++ b/target/linux/ramips/dts/MAC1200RV2.dts
@@ -72,7 +72,7 @@
ðernet {
pinctrl-names = "default";
mtd-mac-address = <&factory 0xd>;
- ralink,port-map = "w";
+ mediatek,portmap = "w";
};
&wmac {
diff --git a/target/linux/ramips/dts/NBG-419N2.dts
b/target/linux/ramips/dts/NBG-419N2.dts
index 18e7902397..73143bd642 100644
--- a/target/linux/ramips/dts/NBG-419N2.dts
+++ b/target/linux/ramips/dts/NBG-419N2.dts
@@ -102,7 +102,7 @@
};
&esw {
- ralink,portmap = <0x2f>;
+ mediatek,portmap = <0x2f>;
};
&wmac {
diff --git a/target/linux/ramips/dts/WL-WN575A3.dts
b/target/linux/ramips/dts/WL-WN575A3.dts
index 98716beb49..213cf9c70b 100644
--- a/target/linux/ramips/dts/WL-WN575A3.dts
+++ b/target/linux/ramips/dts/WL-WN575A3.dts
@@ -125,5 +125,5 @@
ðernet {
mtd-mac-address = <&factory 0x2e>;
- ralink,port-map = "w";
+ mediatek,portmap = "w";
};
diff --git a/target/linux/ramips/dts/WRTNODE2.dtsi
b/target/linux/ramips/dts/WRTNODE2.dtsi
index 294616c0f7..ca7aa3befc 100644
--- a/target/linux/ramips/dts/WRTNODE2.dtsi
+++ b/target/linux/ramips/dts/WRTNODE2.dtsi
@@ -75,7 +75,7 @@
ðernet {
mtd-mac-address = <&factory 0x4>;
- ralink,port-map = "w";
+ mediatek,portmap = "w";
};
&sdhci {
diff --git a/target/linux/ramips/dts/ZBT-WE826.dts
b/target/linux/ramips/dts/ZBT-WE826.dts
index de7fa42d91..8a453bca32 100644
--- a/target/linux/ramips/dts/ZBT-WE826.dts
+++ b/target/linux/ramips/dts/ZBT-WE826.dts
@@ -102,7 +102,
Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?
Hi Dennis, On Sat, Feb 18, 2017 at 06:32:53PM +0100, Dennis Schneck wrote: > Hello, > is there a Image for TP-Link TL-WA854RE ? Due to the lack of an Ethernet port the device is currently very hard to support properly. It's also known to have a very hard to access UART, so it's easy to brick and hard to revive... I just wouldn't recommend anyone to buy such a thing, chances are high that you'll end up with an unusable device sooner or later. Anyway, for proper support we'd need either: * adding wireless interface being enabled as AP * mimic WPS button functionality of stock firmware Both are not trivial in the current framework and would require changing the way wireless configuration is initially being generated. While this is generally an area which is being worked on, I'm not aware of any other devices having wireless enabled after being flashed initially. As a hack or temporary work-around, this is easy to achieve though. Ufo (CC'ed) put some work into adding board support for this device, maybe he can point you to his current work-in-progress patch. Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?
Hi Dennis, Hi Alberto, On Sat, Feb 18, 2017 at 07:02:54PM +, Alberto Bursi wrote: > > Anyway, for proper support we'd need either: > > * adding wireless interface being enabled as AP > > * mimic WPS button functionality of stock firmware > > > There are some such wifi-only devices supported like the "D-Link > DCH-M225 Wi-Fi Audio Extender", and it seems they have wifi enabled by > default with this commit: > https://github.com/lede-project/source/commit/0d5277f73fe4071df4273784e3252d520cef8a6e Nice, I missed that one. It was replaced by https://github.com/lede-project/source/commit/bcfbeae79f799cf1087d692e4869589eb20d2080 (because via uci-defaults it couldn't work reliably, as wifi config wouldn't always even exist at this point) Now the KEY_RFKILL needs to be pressed in order to enabled wifi, then button-hotplug (or gpio-button-hotplug) will enabled the wifi. This still leaves us without failsafe mode and hard-to-access UART, so it'd make more sense to revive https://github.com/openwrt/packages-abandoned/tree/master/utils/restorefactory for those devices (or is there an easy way to have wifi enabled in failsafe mode?) Cheers Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
