[OpenWrt-Devel] [PATCH][RFT] omap: switch kernel to 3.14
Signed-off-by: Rafał Miłecki --- target/linux/omap/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/omap/Makefile b/target/linux/omap/Makefile index 5795c00..e581436 100644 --- a/target/linux/omap/Makefile +++ b/target/linux/omap/Makefile @@ -13,7 +13,7 @@ FEATURES:=usb usbgadget ext4 targz fpu audio display nand ubifs CPU_TYPE:=cortex-a9 CPU_SUBTYPE:=vfpv3 -LINUX_VERSION:=3.13.7 +LINUX_VERSION:=3.14.6 MAINTAINER:=Imre Kaloz -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Babel-users] [PATCH] babeld: use procd to start, stop, and respawn
On 09/08/2014 08:22 PM, Gabriel Kerneis wrote: On Mon, Sep 08, 2014 at 10:54:29AM -0700, Dave Taht wrote: On Mon, Sep 8, 2014 at 6:10 AM, Baptiste Jonglez wrote: Additionally adds a patch to the babeld source is to prevent the attempted recreation of a pidfile when babeld restarts uncleanly. This is also possible to do by passing -I '' on the command line, however procd interprets an empty argument terminating the list, and thus cannot supply empty arguments to programs it manages. Patching babeld itself is a workaround. Why not tackle the root issue? It seems that you encountered crashes in babeld, so that should be fixed, instead of working around the crashes. I did experience a few babeld crashes myself, but never managed to find where they came from. There lies the rub. If you have a deployed machine on a rooftop somewhere, it is better to restart the daemon automagically and log the action rather than attempt to debug it. Using procd to manage this stuff reduces the probability of a babel failure taking out a node by several orders of magnitude, and I strongly favor managing it this way. Certainly finding and fixing bugs so that it doesn't ever crash is a good option, but in the real world, nothing is perfect, and defense in depth is needed. However, there is an elephant in the room here: "procd interprets an empty argument terminating the list, and thus cannot supply empty arguments to programs it manages". More of a mouse in room. I agree that maybe there should be a way of doing it, but really, you're working with a program that thinks is "good" and that is wrong? sure, it's _legitimate_, but why make your app rely on what is (clearly) causing problems? Cheers, Karl P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Missing target sunxi in BB RC[x] series?
On Mon, 8 Sep 2014, Derek Werthmuller wrote: Looking to build BB RC3 for a few of the AllWinnerA20 processor boards, but I don't see them as a target on make menuconfig page? Am I missing something? Also don't see any pre-built images for BB for any of these platforms. I can understand if they were removed from the RC series since they may not be ready for production quite yet and need to stay in trunk. I havn't looked in trunk since BB RC branched. Hi, sunxi depends at least on 3.13 or 3.14 to have decent support for its peripherals. BB focuses on 3.10, backporting the sunxi patches to that kernel wouldn't have made sense. It will make its way into the next release, until that time, please use trunk. Note: an sdcard image generator for the target is on the way. Thx, -w-___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] bcm53xx: select nvram package by default
Signed-off-by: Rafał Miłecki --- target/linux/bcm53xx/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/bcm53xx/Makefile b/target/linux/bcm53xx/Makefile index f9d7e32..c0b3cd5 100644 --- a/target/linux/bcm53xx/Makefile +++ b/target/linux/bcm53xx/Makefile @@ -23,6 +23,6 @@ endef KERNELNAME:="zImage dtbs" -DEFAULT_PACKAGES += swconfig wpad-mini +DEFAULT_PACKAGES += swconfig wpad-mini nvram $(eval $(call BuildTarget)) -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] package: nvram: enable on bcm53xx target
It uses mtd, so doesn't require any special adjustments for new target. It has been succesfully tested (reading, writing and commiting). Signed-off-by: Rafał Miłecki --- package/utils/nvram/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/utils/nvram/Makefile b/package/utils/nvram/Makefile index 81cff03..fe70e34 100644 --- a/package/utils/nvram/Makefile +++ b/package/utils/nvram/Makefile @@ -19,7 +19,7 @@ define Package/nvram CATEGORY:=Base system TITLE:=Userspace port of the Broadcom NVRAM manipulation tool MAINTAINER:=Jo-Philipp Wich - DEPENDS:=@TARGET_brcm47xx||@TARGET_ar71xx + DEPENDS:=@TARGET_brcm47xx||@TARGET_bcm53xx||@TARGET_ar71xx endef define Package/nvram/description -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Babel-users] [PATCH] babeld: use procd to start, stop, and respawn
On Mon, Sep 08, 2014 at 10:54:29AM -0700, Dave Taht wrote: > On Mon, Sep 8, 2014 at 6:10 AM, Baptiste Jonglez wrote: > >> Additionally adds a patch to the babeld source is to prevent the > >> attempted recreation of a pidfile when babeld restarts uncleanly. This is > >> also possible to do by passing -I '' on the command line, however procd > >> interprets an empty argument terminating the list, and thus cannot supply > >> empty arguments to programs it manages. > > > Patching babeld itself is a workaround. Why not tackle the root issue? > > It seems that you encountered crashes in babeld, so that should be fixed, > > instead of working around the crashes. I did experience a few babeld > > crashes myself, but never managed to find where they came from. > > There lies the rub. If you have a deployed machine on a rooftop > somewhere, it is better to restart the daemon automagically and log > the action rather than attempt to debug it. Using procd to manage this > stuff reduces the probability of a babel failure taking out a node by > several orders of magnitude, and I strongly favor managing it this > way. Certainly finding and fixing bugs so that it doesn't ever crash > is a good option, but in the real world, nothing is perfect, and > defense in depth is needed. However, there is an elephant in the room here: "procd interprets an empty argument terminating the list, and thus cannot supply empty arguments to programs it manages". Isn't there a way to fix *that* bug (or rather limitation) at least? Best, -- Gabriel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SStrip strange issue ?!? [Re: There is a error when I buildemailrelay-nossl package in openwrt]
Well there was already an open PR for davfs2 and library and unluckily the commit of this bugfix was added to this PR. Let me know if I have to split them in two different PR https://github.com/openwrt/packages/pull/286 On Mon, Sep 8, 2014 at 8:55 PM, Etienne Champetier < champetier.etie...@gmail.com> wrote: > Hi Federico > > Le 8 sept. 2014 20:34, "Federico Di Marco" a écrit : > > > > Hi again, > > > > I fixed the bug, but due to fact I am not an official maintainer some > days will be required to update openwrt sources. You can however update > manually the only modified file which is the Makefile of emailrelay in > feeds/packages/net/EmailRelay/Makefile folder with the one from my github > repository > https://raw.githubusercontent.com/fededim/packages/e04ad35b6b09681b1e0daa61fa0958a700f9ea5e/net/emailrelay/Makefile > > > > Just overwrite the file and reissue make world, everything should be > fine. > > > > Federico > > > > Please send a PR > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SStrip strange issue ?!? [Re: There is a error when I buildemailrelay-nossl package in openwrt]
Hi Federico Le 8 sept. 2014 20:34, "Federico Di Marco" a écrit : > > Hi again, > > I fixed the bug, but due to fact I am not an official maintainer some days will be required to update openwrt sources. You can however update manually the only modified file which is the Makefile of emailrelay in feeds/packages/net/EmailRelay/Makefile folder with the one from my github repository https://raw.githubusercontent.com/fededim/packages/e04ad35b6b09681b1e0daa61fa0958a700f9ea5e/net/emailrelay/Makefile > > Just overwrite the file and reissue make world, everything should be fine. > > Federico > Please send a PR ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SStrip strange issue ?!? [Re: There is a error when I buildemailrelay-nossl package in openwrt]
Hi again, I fixed the bug, but due to fact I am not an official maintainer some days will be required to update openwrt sources. You can however update manually the only modified file which is the Makefile of emailrelay in feeds/packages/net/EmailRelay/Makefile folder with the one from my github repository https://raw.githubusercontent.com/fededim/packages/e04ad35b6b09681b1e0daa61fa0958a700f9ea5e/net/emailrelay/Makefile Just overwrite the file and reissue make world, everything should be fine. Federico On Mon, Sep 8, 2014 at 4:32 PM, Federico Di Marco wrote: > Well I have never tried compiling both packages, I'll check it out when I > have some spare time, meanwhile please just select one of the two packages, > it should work fine. > > Federico > > On Mon, Sep 8, 2014 at 3:47 PM, 见敌必杀 wrote: > >> Thank you for your explain about this issue, I am a newer of openwrt, I >> don't know what function is I need, so I choice to select "select all >> packages by default" in "make menuconfig", and then to run the command >> "make". My architecture is x86, I do not real need emailrely without ssl. >> For result of select all packages by default, this will select emailrely >> with ssl and emailrely without ssl too. Here is full message when I run >> command "make V=s", build emailrely with ssl is success, but build >> emailrely without ssl fail. >> I am sorry about I couldn't open that audio.avi, it may be GWF prevent me >> access that web. If you think this is a no issue, I will not select >> emailrely without ssl and continue my job. If you need more information, I >> will offer those information. >> >> my build steps are: >> ./script/feed update -a >> ./script/feed install -a >> make menuconfig >> >> Target System -> x86 >> Global build settings -> Select all packages by default >> save and exit >> >> make V=s >> After a few hours, it show: >> >> make[3]: Entering directory >> `/home/yangjun/openwrt/openwrt/feeds/packages/net/emailrelay' >> rm -rf >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay >> mkdir -p >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/stamp >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay >> install -d -m0755 >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/usr/bin >> install -m0755 >> /home/yangjun/openwrt/openwrt/build_dir/target-i386_i486_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/usr/bin/ >> install -m0755 >> /home/yangjun/openwrt/openwrt/build_dir/target-i386_i486_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-filter-copy >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/usr/bin/ >> install -m0755 >> /home/yangjun/openwrt/openwrt/build_dir/target-i386_i486_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-passwd >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/usr/bin/ >> install -m0755 >> /home/yangjun/openwrt/openwrt/build_dir/target-i386_i486_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-poke >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/usr/bin/ >> install -m0755 >> /home/yangjun/openwrt/openwrt/build_dir/target-i386_i486_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-submit >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/usr/bin/ >> install -d -m0755 >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/etc >> install -m0644 files/emailrelay.auth >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/etc/ >> install -d -m0755 >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/etc/init.d >> install -m0755 files/emailrelay.init >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/etc/init.d/emailrelay >> SHELL= /home/yangjun/openwrt/openwrt/staging_dir/host/bin/flock >> /home/yangjun/openwrt/openwrt/tmp/.root-copy.flock -c 'cp -fpR >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay/. >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/' >> rm -rf >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/tmp-emailrelay >> touch >> /home/yangjun/openwrt/openwrt/staging_dir/target-i386_i486_uClibc-0.9.33.2/root-x86/stamp/.emailrelay_installed >> make[3]: Leaving directory >> `/home/yangjun/openwrt/openwrt/feeds/packages/net/emailrelay' >> make[3]: Entering directory >> `/home/yangjun/openwrt/openwrt/feeds/packages/net/emailrelay' >> mkdir -p /home/y
Re: [OpenWrt-Devel] [PATCH] babeld: use procd to start, stop, and respawn
FYI - Forwarded message from Juliusz Chroboczek - Date: Mon, 08 Sep 2014 16:03:56 +0200 From: Juliusz Chroboczek To: Baptiste Jonglez Cc: openwrt-devel@lists.openwrt.org, babel-us...@lists.alioth.debian.org Subject: Re: [Babel-users] [OpenWrt-Devel] [PATCH] babeld: use procd to start, stop, and respawn User-Agent: Wanderlust/2.15.9 >> adds a hotplug.d file to restart babeld when interfaces go up or down. > https://github.com/openwrt-routing/packages/pull/52 > However [...] this should not be needed, as babeld detects > when an interface is brought up and then starts using it. Yes, note however that babeld only watches the interfaces that were given to it on the command line or in the config file. Does OpenWRT need wildcard support? >> Additionally adds a patch to the babeld source is to prevent the >> attempted recreation of a pidfile when babeld restarts uncleanly. Please don't do that. We're trying to avoid having the OpenWRT version of babeld diverge from upstream, as a patched babeld is confusing to both the users and the maintainers. >> This is also possible to do by passing -I '' on the command line, >> however procd interprets an empty argument terminating the list, and >> thus cannot supply empty arguments to programs it manages. If this cannot be fixed without hacking babeld, I can add a special case so that "-I none" is a synonim for "-I ''". -- Juliusz - End forwarded message - pgpoR4xiD3th_.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Missing target sunxi in BB RC[x] series?
On 8 September 2014 19:27, Derek Werthmuller wrote: > Looking to build BB RC3 for a few of the AllWinnerA20 processor boards, but > I don't see them as a target on make menuconfig page? Am I missing > something? > > Also don't see any pre-built images for BB for any of these platforms. I > can understand if they were removed from the RC series since they may not be > ready for production quite yet and need to stay in trunk. I havn't looked > in trunk since BB RC branched. http://git.openwrt.org/?p=14.07/openwrt.git;a=commit;h=52bcebc3b22d3fe36ccec1d7d2754756d2d47ec9 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Missing target sunxi in BB RC[x] series?
Looking to build BB RC3 for a few of the AllWinnerA20 processor boards, but I don't see them as a target on make menuconfig page? Am I missing something? Also don't see any pre-built images for BB for any of these platforms. I can understand if they were removed from the RC series since they may not be ready for production quite yet and need to stay in trunk. I havn't looked in trunk since BB RC branched. Cheers Derek ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k regression (was: Barrier Breaker timeline?)
On 08/09/14 11:23, John Crispin wrote: > > On 08/09/2014 16:16, Aaron Z wrote: >> I am curious if there is a timeline for either RC4 or the final >> release for Barrier Breaker? >> The RC3 release announcement said ( >> https://forum.openwrt.org/viewtopic.php?pid=242292 ) on 31 Jul said >> "Depending on how testing goes we will push the final or RC4 within >> the next 2 weeks." >> That is obviously past, any idea on a new timeframe? >> I need to setup a couple of WNR1043ND access points I need to setup >> and would prefer to go straight to the final if that is coming in the >> next week or so. > > Hi, > > the test build is done and we fixed the 2 problems that came up. SDK now > works properly. all the packages from all feeds build (apart from > old.packages which has a fallout of ~15 packages) currently we are > waiting on a ath9k regression fix that is being tested just now. once Hi there, could you give some more details about the regression? I spotted today an issue with 1 ap + 1 adhoc VIFs over a single phy, on tl-wdr3500/3600, with mcast_rate=24000 on the adhoc wifi-iface, where the adhoc would not transmit unicast at 802.11n rates, instead staying at G rates or something like that. didn't put much time into it, and it resolved spontaneously at some point, or I issued a "wifi" reset, can't say for sure, but it was definitely reproduceable after reboot, so I'll dig into it later today or during the week, i'm asking, just in case it's the same issue / regression you're already dealing with? cheers! gui > that is in the release branch i will restart the builders and generate > BB-final. > > John > > > > > >> >> Thanks >> >> Aaron Z >> >> A human being should be able to change a diaper, plan an invasion, >> butcher a hog, conn a ship, design a building, write a sonnet, balance >> accounts, build a wall, set a bone, comfort the dying, take orders, >> give orders, cooperate, act alone, solve equations, analyze a new >> problem, pitch manure, program a computer, cook a tasty meal, fight >> efficiently, die gallantly. Specialization is for insects. >> — Robert Heinlein, Time Enough for Loveove >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Barrier Breaker timeline?
On 08/09/2014 18:15, Karl Palsson wrote: > On Mon, Sep 08, 2014 at 04:23:10PM +0200, John Crispin wrote: >> >> On 08/09/2014 16:16, Aaron Z wrote: >>> I am curious if there is a timeline for either RC4 or the >>> final release for Barrier Breaker? >> >> the test build is done and we fixed the 2 problems that came up. >> SDK now works properly. all the packages from all feeds build >> (apart from old.packages which has a fallout of ~15 packages) >> currently we are waiting on a ath9k regression fix that is being >> tested just now. once that is in the release branch i will >> restart the builders and generate BB-final. >> >> John > > Currently, there's a regression in new packages vs AA, > https://github.com/openwrt/packages/issues/292 The package has > gone back a major revision, from someone other than the package > maintainer... > > Sincerely, Karl P let me look into it ... John > ___ openwrt-devel > mailing list openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Barrier Breaker timeline?
On Mon, Sep 08, 2014 at 04:23:10PM +0200, John Crispin wrote: > > On 08/09/2014 16:16, Aaron Z wrote: > > I am curious if there is a timeline for either RC4 or the final > > release for Barrier Breaker? > > the test build is done and we fixed the 2 problems that came up. SDK now > works properly. all the packages from all feeds build (apart from > old.packages which has a fallout of ~15 packages) currently we are > waiting on a ath9k regression fix that is being tested just now. once > that is in the release branch i will restart the builders and generate > BB-final. > > John Currently, there's a regression in new packages vs AA, https://github.com/openwrt/packages/issues/292 The package has gone back a major revision, from someone other than the package maintainer... Sincerely, Karl P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Barrier Breaker timeline?
Hi, It is here on the wiki already posted by someone http://wiki.openwrt.org/toh/pcengines/apu Regards, Nishant On 8 September 2014 20:13:34 GMT+05:30, John Crispin wrote: >is this reported or documented anywhere ? > > > >On 08/09/2014 16:40, Nishant Sharma wrote: >> >> On 8 September 2014 20:07:26 GMT+05:30, John Crispin > wrote: >>> On 08/09/2014 16:29, Nishant Sharma wrote: Hi John, > the test build is done and we fixed the 2 problems that came up. >SDK > now > works properly. all the packages from all feeds build (apart from > old.packages which has a fallout of ~15 packages) currently we are > waiting on a ath9k regression fix that is being tested just now. >>> once > that is in the release branch i will restart the builders and >>> generate > BB-final. Great news. Shall we expect the x86 images created to retain >changes >>> on reboot on BB-final? >>> >>> they don't do so now ? >> The last I tried on rc3 and trunk, they didn't. Hence a separate post >too on the list. >> >> Wiki said the same. Will try again tomorrow and post the findings. >> >> Regards, >> Nishant >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] disappearing on-link route with RA
Yeah, the issue was in the tons of work-arounds needed to deal with Linux' onlink-route handling before 3.14. I added another one because they are so nice and likeable. This should hopefully do the trick again, until next time. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Barrier Breaker timeline?
is this reported or documented anywhere ? On 08/09/2014 16:40, Nishant Sharma wrote: > > On 8 September 2014 20:07:26 GMT+05:30, John Crispin > wrote: >> On 08/09/2014 16:29, Nishant Sharma wrote: >>> Hi John, the test build is done and we fixed the 2 problems that came up. SDK now works properly. all the packages from all feeds build (apart from old.packages which has a fallout of ~15 packages) currently we are waiting on a ath9k regression fix that is being tested just now. >> once that is in the release branch i will restart the builders and >> generate BB-final. >>> Great news. Shall we expect the x86 images created to retain changes >> on reboot on BB-final? >> >> they don't do so now ? > The last I tried on rc3 and trunk, they didn't. Hence a separate post too on > the list. > > Wiki said the same. Will try again tomorrow and post the findings. > > Regards, > Nishant > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Barrier Breaker timeline?
On 8 September 2014 20:07:26 GMT+05:30, John Crispin wrote: > >On 08/09/2014 16:29, Nishant Sharma wrote: >> >> Hi John, >>> the test build is done and we fixed the 2 problems that came up. SDK >>> now >>> works properly. all the packages from all feeds build (apart from >>> old.packages which has a fallout of ~15 packages) currently we are >>> waiting on a ath9k regression fix that is being tested just now. >once >>> that is in the release branch i will restart the builders and >generate >>> BB-final. >> >> Great news. Shall we expect the x86 images created to retain changes >on reboot on BB-final? > >they don't do so now ? The last I tried on rc3 and trunk, they didn't. Hence a separate post too on the list. Wiki said the same. Will try again tomorrow and post the findings. Regards, Nishant -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2] kernel: add bcma patches sent upstream but not pushed yet
Signed-off-by: Rafał Miłecki
---
V2: Add bcma_init_bus in bcm53xx patch to fix Oops
---
...-bcma-register-bcma-as-device-tree-driver.patch | 11 +-
.../patches-3.14/121-bcma-get-irqs-from-dt.patch | 38 ++--
...42-bcma-add-support-for-chipcommon-B-core.patch | 8 +-
.../160-bcma-add-PCI-IDs-for-more-devices.patch| 32 ---
.../linux/generic/patches-3.10/026-bcma-sent.patch | 247 +
.../linux/generic/patches-3.14/026-bcma-sent.patch | 247 +
6 files changed, 524 insertions(+), 59 deletions(-)
delete mode 100644
target/linux/bcm53xx/patches-3.14/160-bcma-add-PCI-IDs-for-more-devices.patch
create mode 100644 target/linux/generic/patches-3.10/026-bcma-sent.patch
create mode 100644 target/linux/generic/patches-3.14/026-bcma-sent.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/120-bcma-register-bcma-as-device-tree-driver.patch
b/target/linux/bcm53xx/patches-3.14/120-bcma-register-bcma-as-device-tree-driver.patch
index 317fbdc..9027f48 100644
---
a/target/linux/bcm53xx/patches-3.14/120-bcma-register-bcma-as-device-tree-driver.patch
+++
b/target/linux/bcm53xx/patches-3.14/120-bcma-register-bcma-as-device-tree-driver.patch
@@ -76,15 +76,15 @@ Signed-off-by: Hauke Mehrtens
#include
#include
-@@ -173,6 +176,7 @@ int __init bcma_host_soc_register(struct
+@@ -176,6 +179,7 @@ int __init bcma_host_soc_register(struct
/* Host specific */
bus->hosttype = BCMA_HOSTTYPE_SOC;
bus->ops = &bcma_host_soc_ops;
+ bus->host_pdev = NULL;
- /* Register */
- err = bcma_bus_early_register(bus, &soc->core_cc, &soc->core_mips);
-@@ -181,3 +185,69 @@ int __init bcma_host_soc_register(struct
+ /* Initialize struct, detect chip */
+ bcma_init_bus(bus);
+@@ -195,3 +199,72 @@ int __init bcma_host_soc_init(struct bcm
return err;
}
@@ -112,6 +112,9 @@ Signed-off-by: Hauke Mehrtens
+ bus->ops = &bcma_host_soc_ops;
+ bus->host_pdev = pdev;
+
++ /* Initialize struct, detect chip */
++ bcma_init_bus(bus);
++
+ /* Register */
+ err = bcma_bus_register(bus);
+ if (err)
diff --git a/target/linux/bcm53xx/patches-3.14/121-bcma-get-irqs-from-dt.patch
b/target/linux/bcm53xx/patches-3.14/121-bcma-get-irqs-from-dt.patch
index d9a831c..02cf1ea 100644
--- a/target/linux/bcm53xx/patches-3.14/121-bcma-get-irqs-from-dt.patch
+++ b/target/linux/bcm53xx/patches-3.14/121-bcma-get-irqs-from-dt.patch
@@ -24,8 +24,8 @@ Signed-off-by: Hauke Mehrtens
MODULE_DESCRIPTION("Broadcom's specific AMBA driver");
MODULE_LICENSE("GPL");
-@@ -120,6 +122,38 @@ static void bcma_release_core_dev(struct
- kfree(core);
+@@ -131,6 +133,38 @@ static bool bcma_is_core_needed_early(u1
+ return false;
}
+static struct device_node *bcma_of_find_child_device(struct platform_device
*parent,
@@ -60,21 +60,21 @@ Signed-off-by: Hauke Mehrtens
+ core->irq = irq_of_parse_and_map(node, 0);
+}
+
- static int bcma_register_cores(struct bcma_bus *bus)
+ static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
{
- struct bcma_device *core;
-@@ -155,7 +189,13 @@ static int bcma_register_cores(struct bc
- break;
- case BCMA_HOSTTYPE_SOC:
- core->dev.dma_mask = &core->dev.coherent_dma_mask;
-- core->dma_dev = &core->dev;
-+ if (bus->host_pdev) {
-+ core->dma_dev = &bus->host_pdev->dev;
-+ core->dev.parent = &bus->host_pdev->dev;
-+ bcma_of_fill_device(bus->host_pdev, core);
-+ } else {
-+ core->dma_dev = &core->dev;
-+ }
- break;
- case BCMA_HOSTTYPE_SDIO:
- break;
+ int err;
+@@ -147,7 +181,13 @@ static void bcma_register_core(struct bc
+ break;
+ case BCMA_HOSTTYPE_SOC:
+ core->dev.dma_mask = &core->dev.coherent_dma_mask;
+- core->dma_dev = &core->dev;
++ if (bus->host_pdev) {
++ core->dma_dev = &bus->host_pdev->dev;
++ core->dev.parent = &bus->host_pdev->dev;
++ bcma_of_fill_device(bus->host_pdev, core);
++ } else {
++ core->dma_dev = &core->dev;
++ }
+ break;
+ case BCMA_HOSTTYPE_SDIO:
+ break;
diff --git
a/target/linux/bcm53xx/patches-3.14/142-bcma-add-support-for-chipcommon-B-core.patch
b/target/linux/bcm53xx/patches-3.14/142-bcma-add-support-for-chipcommon-B-core.patch
index c744e38..59b94c1 100644
---
a/target/linux/bcm53xx/patches-3.14/142-bcma-add-support-for-chipcommon-B-core.patch
+++
b/target/linux/bcm53xx/patches-3.14/142-bcma-add-support-for-chipcommon-B-core.patch
@@ -105,7 +105,7 @@ Signed-off-by: Hauke Mehrtens
+}
Re: [OpenWrt-Devel] Barrier Breaker timeline?
On Mon, Sep 8, 2014 at 10:23 AM, John Crispin wrote: > the test build is done and we fixed the 2 problems that came up. SDK now > works properly. all the packages from all feeds build (apart from > old.packages which has a fallout of ~15 packages) currently we are > waiting on a ath9k regression fix that is being tested just now. once > that is in the release branch i will restart the builders and generate > BB-final. Perfect. Thanks! Aaron Z A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. — Robert Heinlein, Time Enough for Love ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Barrier Breaker timeline?
On 08/09/2014 16:16, Aaron Z wrote: > I am curious if there is a timeline for either RC4 or the final > release for Barrier Breaker? > The RC3 release announcement said ( > https://forum.openwrt.org/viewtopic.php?pid=242292 ) on 31 Jul said > "Depending on how testing goes we will push the final or RC4 within > the next 2 weeks." > That is obviously past, any idea on a new timeframe? > I need to setup a couple of WNR1043ND access points I need to setup > and would prefer to go straight to the final if that is coming in the > next week or so. Hi, the test build is done and we fixed the 2 problems that came up. SDK now works properly. all the packages from all feeds build (apart from old.packages which has a fallout of ~15 packages) currently we are waiting on a ath9k regression fix that is being tested just now. once that is in the release branch i will restart the builders and generate BB-final. John > > Thanks > > Aaron Z > > A human being should be able to change a diaper, plan an invasion, > butcher a hog, conn a ship, design a building, write a sonnet, balance > accounts, build a wall, set a bone, comfort the dying, take orders, > give orders, cooperate, act alone, solve equations, analyze a new > problem, pitch manure, program a computer, cook a tasty meal, fight > efficiently, die gallantly. Specialization is for insects. > — Robert Heinlein, Time Enough for Loveove > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Barrier Breaker timeline?
I am curious if there is a timeline for either RC4 or the final release for Barrier Breaker? The RC3 release announcement said ( https://forum.openwrt.org/viewtopic.php?pid=242292 ) on 31 Jul said "Depending on how testing goes we will push the final or RC4 within the next 2 weeks." That is obviously past, any idea on a new timeframe? I need to setup a couple of WNR1043ND access points I need to setup and would prefer to go straight to the final if that is coming in the next week or so. Thanks Aaron Z A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. — Robert Heinlein, Time Enough for Loveove ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, Sep 8, 2014 at 3:50 PM, Robert P. J. Day wrote: > > ok, new issue at github: > > https://github.com/openwrt/packages/issues/291 > > is this the proper format? is there any information i failed to > include? This looks fine. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
ok, new issue at github: https://github.com/openwrt/packages/issues/291 is this the proper format? is there any information i failed to include? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, 8 Sep 2014, Jonas Gorski wrote: > I do acknowledge that the trac intro page doesn't have instructions > for bugs in feeds, but you didn't follow the directions completely. > You were told to report to github, and then actively decided to > disregard that. i (incorrectly) assumed you made a slip of the tongue since the wiki page pointed me at trac -- my apologies. i just noticed that, further down that same page is the link to github error reporting specifically for packages: https://github.com/openwrt/packages/issues so i'll reproduce the issue there. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, Sep 8, 2014 at 3:05 PM, Robert P. J. Day wrote: > On Mon, 8 Sep 2014, Jonas Gorski wrote: > >> On Mon, Sep 8, 2014 at 2:14 PM, Robert P. J. Day >> wrote: >> > On Mon, 8 Sep 2014, Etienne Champetier wrote: >> > >> >> >> >> Hi >> >> Le 7 sept. 2014 23:40, "Robert P. J. Day" a écrit >> >> : >> >> > >> >> > >> >> > still reviewing so i don't think i have the background to debug this >> >> > one: >> >> > >> >> > $ make V=s >> >> > ... big snip ... >> >> > Package emailrelay-nossl is missing dependencies for the following >> >> > libraries: >> >> > libcrypto.so.1.0.0 >> >> > libssl.so.1.0.0 >> >> > Makefile:118: recipe for target >> >> > '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' >> >> failed >> >> > make[3]: *** >> >> > [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] >> >> > Error 1 >> >> > >> >> > i'm using the default config.ramips_mt7620a config file. thoughts? >> >> > >> >> > rday >> >> >> >> Please open an issue on github >> > >> > submitted through trac: >> > >> > https://dev.openwrt.org/ticket/17794 >> >> Trac is not github. The (new) packages feed is at >> https://www.github.com/openwrt/packages and any issues for the >> packages therein should be raised there. > > i realize that, except that if one goes to the development page > here: > > https://dev.openwrt.org/ > > one of the first links is entitled "Add a new ticket", and it takes > you to trac. pretty sure it's not my fault if i followed precisely the > directions at the openwrt development page. I do acknowledge that the trac intro page doesn't have instructions for bugs in feeds, but you didn't follow the directions completely. You were told to report to github, and then actively decided to disregard that. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Fwd: GRUB / GRUB2 on current trunk?
Hi all, Posting on Devel list as it seems more like a devel query now. Regards, Nishant Original Message From: Nishant Sharma Sent: 3 September 2014 20:18:49 GMT+05:30 To: openwrt-us...@lists.openwrt.org Subject: GRUB / GRUB2 on current trunk? Hi, This is my first message to the list. Is there a way that I could compile old GRUB on SVN r42320 or install GRUB2 somehow on the target disk after copying the rootfs? The hardware is PCEngines APU with SSD. I am compiling it for x86_64 and there is no way that I can use grub-install command by chrooting into the new rootfs flashed on the target drive, as the GRUB2 utils are not available in the rootfs. The ext4 filesystem image generated by 'make' doesn't survive changes on a reboot. Which forces me to first copy rootfs to the target disk and then install the boot loader on it. The good old GRUB used to be so easy for x86. Any pointers would be of a great help. Thanks in advance. Regards, Nishant -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] babeld: use procd to start, stop, and respawn
Hi,
Note that babeld is maintained in https://github.com/openwrt-routing/packages.
Nevertheless, comments inline.
On Sun, Sep 07, 2014 at 05:56:32PM -0400, Tristan Plumb wrote:
> Changes the babeld init script to utilize procd and
Nice, it was a requested feature:
https://github.com/openwrt-routing/packages/issues/17
Could you separate your patch into three patches? (procd support, hotplug
script, pidfile hack)
> adds a hotplug.d file to restart babeld when interfaces go up or down.
Somebody provided a patch for this just a few days ago, see:
https://github.com/openwrt-routing/packages/pull/52
However, see the comments: this should not be needed, as babeld detects
when an interface is brought up and then starts using it. What is your
use-case?
> Additionally adds a patch to the babeld source is to prevent the
> attempted recreation of a pidfile when babeld restarts uncleanly. This is
> also possible to do by passing -I '' on the command line, however procd
> interprets an empty argument terminating the list, and thus cannot supply
> empty arguments to programs it manages.
Patching babeld itself is a workaround. Why not tackle the root issue?
It seems that you encountered crashes in babeld, so that should be fixed,
instead of working around the crashes. I did experience a few babeld
crashes myself, but never managed to find where they came from.
> Signed-off-by: Tristan Plumb
> ---
> diff --git a/babeld/Makefile b/babeld/Makefile
> index e939310..70fcd64 100644
> --- a/babeld/Makefile
> +++ b/babeld/Makefile
> @@ -54,6 +54,8 @@ define Package/babeld/install
> $(INSTALL_CONF) ./files/babeld.config $(1)/etc/config/babeld
> $(INSTALL_DIR) $(1)/etc/init.d
> $(INSTALL_BIN) ./files/babeld.init $(1)/etc/init.d/babeld
> + $(INSTALL_DIR) $(1)/etc/hotplug.d/iface
> + $(INSTALL_DATA) ./files/babeld.hotplug
> $(1)/etc/hotplug.d/iface/25-babeld
> endef
>
> $(eval $(call BuildPackage,babeld))
> diff --git a/babeld/files/babeld.hotplug b/babeld/files/babeld.hotplug
> new file mode 100644
> index 000..3fe674a
> --- /dev/null
> +++ b/babeld/files/babeld.hotplug
> @@ -0,0 +1,6 @@
> +#!/bin/sh
> +
> +[ "$ACTION" = ifup ] || exit 0
> +
> +/etc/init.d/babeld enabled && /etc/init.d/babeld restart
> +
> diff --git a/babeld/files/babeld.init b/babeld/files/babeld.init
> index 180fc7e..de8d73b 100755
> --- a/babeld/files/babeld.init
> +++ b/babeld/files/babeld.init
> @@ -2,9 +2,9 @@
>
> . /lib/functions/network.sh
>
> +USE_PROCD=1
> START=70
>
> -pidfile='/var/run/babeld.pid'
> CONFIGFILE='/var/etc/babeld.conf'
> OTHERCONFIGFILE="/etc/babeld.conf"
> EXTRA_COMMANDS="status"
> @@ -197,7 +197,7 @@ babel_config_cb() {
> esac
> }
>
> -start() {
> +start_service() {
> mkdir -p /var/lib
> # Start by emptying the generated config file
> >"$CONFIGFILE"
> @@ -213,26 +213,17 @@ start() {
> config_foreach parse_old_global_options general
> # Parse filters separately, since we know which options we expect
> config_foreach babel_filter filter
> + procd_open_instance
> # Using multiple config files is supported since babeld 1.5.1
> - /usr/sbin/babeld -D -I "$pidfile" -c "$OTHERCONFIGFILE" -c "$CONFIGFILE"
> - # Wait for the pidfile to appear
> - for i in 1 2
> - do
> - [ -f "$pidfile" ] || sleep 1
> - done
> - [ -f "$pidfile" ] || (echo "Failed to start babeld"; exit 42)
> + procd_set_param command /usr/sbin/babeld -c "$OTHERCONFIGFILE" -c
> "$CONFIGFILE"
> + procd_set_param respawn
> + procd_close_instance
> }
>
> -stop() {
> - [ -f "$pidfile" ] && kill $(cat $pidfile)
> - # avoid race-condition on restart: wait for
> - # babeld to die for real.
> - [ -f "$pidfile" ] && sleep 1
> - [ -f "$pidfile" ] && sleep 1
> - [ -f "$pidfile" ] && sleep 1
> - [ -f "$pidfile" ] && exit 42
> +service_triggers() {
> + procd_add_reload_trigger babeld
> }
>
> status() {
> - [ -f "$pidfile" ] && kill -USR1 $(cat $pidfile)
> + kill -USR1 $(pidof babeld)
> }
> diff --git a/babeld/patches/001-no-default-pidfile.patch
> b/babeld/patches/001-no-default-pidfile.patch
> new file mode 100644
> index 000..74ac6b4
> --- /dev/null
> +++ b/babeld/patches/001-no-default-pidfile.patch
> @@ -0,0 +1,21 @@
> +diff --git a/babeld.c b/babeld.c
> +index 656c9da..88e4aec 100644
> +--- a/babeld.c
> b/babeld.c
> +@@ -66,7 +66,7 @@ int resend_delay = -1;
> + int random_id = 0;
> + int do_daemonise = 0;
> + const char *logfile = NULL,
> +-*pidfile = "/var/run/babeld.pid",
> ++*pidfile = NULL,
> + *state_file = "/var/lib/babel-state";
> +
> + unsigned char *receive_buffer = NULL;
> +@@ -251,6 +251,7 @@ main(int argc, char **argv)
> + break;
> + case 'D':
> + do_daemonise = 1;
> ++pidfile = "/var/run/babeld.pid";
> + break;
> + case 'L':
> + logfile = optarg;
pgptPm84CyRww.pgp
Description: PGP s
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, 8 Sep 2014, Jonas Gorski wrote: > On Mon, Sep 8, 2014 at 2:14 PM, Robert P. J. Day > wrote: > > On Mon, 8 Sep 2014, Etienne Champetier wrote: > > > >> > >> Hi > >> Le 7 sept. 2014 23:40, "Robert P. J. Day" a écrit : > >> > > >> > > >> > still reviewing so i don't think i have the background to debug this > >> > one: > >> > > >> > $ make V=s > >> > ... big snip ... > >> > Package emailrelay-nossl is missing dependencies for the following > >> > libraries: > >> > libcrypto.so.1.0.0 > >> > libssl.so.1.0.0 > >> > Makefile:118: recipe for target > >> > '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' > >> failed > >> > make[3]: *** > >> > [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] > >> > Error 1 > >> > > >> > i'm using the default config.ramips_mt7620a config file. thoughts? > >> > > >> > rday > >> > >> Please open an issue on github > > > > submitted through trac: > > > > https://dev.openwrt.org/ticket/17794 > > Trac is not github. The (new) packages feed is at > https://www.github.com/openwrt/packages and any issues for the > packages therein should be raised there. i realize that, except that if one goes to the development page here: https://dev.openwrt.org/ one of the first links is entitled "Add a new ticket", and it takes you to trac. pretty sure it's not my fault if i followed precisely the directions at the openwrt development page. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] disappearing on-link route with RA
Hello fine folks, i'm testing bb-rc, compiled by myself from: git://git.openwrt.org/14.07/openwrt.git at exactly this commit: git-svn-id: svn://svn.openwrt.org/openwrt/branches/barrier_breaker@42398 so, a little bit more recent than the published bb-rc3 from http://downloads.openwrt.org/barrier_breaker/14.07-rc3/ and i encounter a behaviour i'm already getting used to :P [0] with network.iface.proto=dhcpv6, the first RA that arrives creates the on-link route correctly (2001:db8::/64 on dev blah) and the second RA, makes it disappear :( leaving only the "default" route, and producing "triangular" routing between nodes on the same link-local you might not notice this immediately on a wired LAN, but on a geographically widespread batman-adv mesh network like DeltaLibre, it's the first thing i notice after sysupgrading, and ssh'ing into a node :) root@palmeras:~# ip -6 r default from :: via fe80::a2f3:c1ff:fe86:425 dev br-lan proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::a2f3:c1ff:fe86:425 dev br-lan proto static metric 1024 2a00:1508:1:f004::/64 dev br-lan proto static metric 256 fddf:ca97:c78b::/64 dev br-lan proto kernel metric 256 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev eth0-167 proto kernel metric 256 fe80::/64 dev wlan0_ap proto kernel metric 256 fe80::/64 dev wlan0_adhoc proto kernel metric 256 fe80::/64 dev wlan0_adhoc-167 proto kernel metric 256 root@palmeras:~# rdisc6 br-lan Soliciting ff02::2 (ff02::2) on br-lan... Hop limit : 64 ( 0x40) Stateful address conf.: No Stateful other conf. : No Mobile home agent : No Router preference : medium Neighbor discovery proxy : No Router lifetime : 1800 (0x0708) seconds Reachable time: unspecified (0x) Retransmit time : unspecified (0x) Prefix : 2a00:1508:1:f004::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 3600 (0x0e10) seconds Pref. time : 3600 (0x0e10) seconds MTU : 1500 bytes (valid) Source link-layer address: A0:F3:C1:86:04:25 Recursive DNS server : 2a00:1508:1:f004::1 DNS server lifetime : 1200 (0x04b0) seconds from fe80::a2f3:c1ff:fe86:425 root@palmeras:~# ip -6 r default from :: via fe80::a2f3:c1ff:fe86:425 dev br-lan proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::a2f3:c1ff:fe86:425 dev br-lan proto static metric 1024 fddf:ca97:c78b::/64 dev br-lan proto kernel metric 256 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev eth0-167 proto kernel metric 256 fe80::/64 dev wlan0_ap proto kernel metric 256 fe80::/64 dev wlan0_adhoc proto kernel metric 256 fe80::/64 dev wlan0_adhoc-167 proto kernel metric 256 root@palmeras:~# opkg list odhcp6c netifd odhcp6c - 2014-08-25-0300fe7589a1701361735ac068e4b57bb1a1896f root@palmeras:~# opkg list netifd netifd - 2014-08-31-b2dcb02570939d98b92c7c55db1c328693a5d52a [0]: i recall encountering a similar regression twice already, in the last couple of years or so, and in both cases it was promptly fixed by cyrus: much respect for your impressive work on ipv6! /me always thankful :) [0a] in fact, i was just looking for the last report https://lists.openwrt.org/pipermail/openwrt-devel/2014-February/023640.html and I don't recall specifically, but i guess it worked after that fix, (or i would have noticed). Anyway i'm not sure anymore :$ sorry for not following up that original thread, now it's gone from my memory happy to debug this further, provide pcaps, or anything else needed cheers! gui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, Sep 8, 2014 at 2:14 PM, Robert P. J. Day wrote: > On Mon, 8 Sep 2014, Etienne Champetier wrote: > >> >> Hi >> Le 7 sept. 2014 23:40, "Robert P. J. Day" a écrit : >> > >> > >> > still reviewing so i don't think i have the background to debug this >> > one: >> > >> > $ make V=s >> > ... big snip ... >> > Package emailrelay-nossl is missing dependencies for the following >> > libraries: >> > libcrypto.so.1.0.0 >> > libssl.so.1.0.0 >> > Makefile:118: recipe for target >> > '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' >> failed >> > make[3]: *** >> > [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] >> > Error 1 >> > >> > i'm using the default config.ramips_mt7620a config file. thoughts? >> > >> > rday >> >> Please open an issue on github > > submitted through trac: > > https://dev.openwrt.org/ticket/17794 Trac is not github. The (new) packages feed is at https://www.github.com/openwrt/packages and any issues for the packages therein should be raised there. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Missing packages from packages feed on GitHub repository
Ok, got it. Thank you for all your answers. On Wed, Sep 3, 2014 at 12:57 PM, Jiří Šlachta wrote: > Hi Federico, > > I would say you can take over maintainership without asking anyone. There > is no formal maintainer for this package and git history shows that this > package was maintained by almost all devs through the time. Just create > pull request against the packages repository in github and it will be merged > by devs or maintainers if it complies the "Contributing Guidelines". > > Please see following: > https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md > > Jiri > > Dne 03/09/2014 v 11:56 Federico Di Marco napsal(a): >> :) Ok got it, just to be sure before "stealing" others' work is there >> anybody willing to maintain neon library ? From SVN jow (I do not know >> his/her email) is the last one who modified neon package, could >> someone please ask him/her if he/she is willing sooner or later to >> upload neon library to Git ? >> >> Federico >> >> On Wed, Sep 3, 2014 at 11:17 AM, Weedy wrote: >>> >>> On 3 Sep 2014 04:21, "Federico Di Marco" wrote: Well shouldn't there already be assigned a maintaner ? >>> >>> They were never set in stone. >>> This is why we started over. >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, 8 Sep 2014, Etienne Champetier wrote: > > Hi > Le 7 sept. 2014 23:40, "Robert P. J. Day" a écrit : > > > > > > still reviewing so i don't think i have the background to debug this > > one: > > > > $ make V=s > > ... big snip ... > > Package emailrelay-nossl is missing dependencies for the following > > libraries: > > libcrypto.so.1.0.0 > > libssl.so.1.0.0 > > Makefile:118: recipe for target > > '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' > failed > > make[3]: *** > > [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] > > Error 1 > > > > i'm using the default config.ramips_mt7620a config file. thoughts? > > > > rday > > Please open an issue on github submitted through trac: https://dev.openwrt.org/ticket/17794 rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SStrip strange issue ?!? [Re: There is a error when I build emailrelay-nossl package in openwrt]
Hi Yangjun, after a full check, it seems that everything is working and there is no issue (I was wrong with sstrip). Please have a look at the video of the the checks I have done on my router after having unistalled the libopenssl ( https://www.fededim.pw ). You can also a find a build of both emailrelay packages (ar7xxx architecture, hoping it's the same as yours) I have used in my test on the same website. Finally sorry to all Openwrt folks for the fake issue on sstrip, it won't happen again (incredibly almost half file size can be stripped). Federico On Mon, Sep 8, 2014 at 1:02 PM, Federico Di Marco wrote: > Ok please discard this thread, sstrip is fine. > > On Mon, Sep 8, 2014 at 12:00 PM, Federico Di Marco > wrote: > >> I know that this is seems a very strange behaviour, so I made a screen >> video to check it by yourself, you can download the video here >> >> >> https://www.fededim.pw/OpenWrt%20EmailRelay%20compilation%20issue_no%20audio.avi >> >> On Mon, Sep 8, 2014 at 11:23 AM, Federico Di Marco >> wrote: >> >>> Hi yangjun, >>> >>> I just gave a quick view to your problem it seems you are right there is >>> an issue in the generated ipkg file, eventhough the compilation is fine >>> (emailrelay does compile without ssl). In my build machine (architecture >>> ar7xxx) at the end build_dir/target-your >>> architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main contains the >>> correct executables >>> >>> -rwxr-xr-x 1 compile compile 702462 set 8 10:38 src/main/emailrelay >>> -rwxr-xr-x 1 compile compile 99271 set 8 10:38 >>> src/main/emailrelay-filter-copy >>> -rwxr-xr-x 1 compile compile 68688 set 8 10:38 >>> src/main/emailrelay-passwd >>> -rwxr-xr-x 1 compile compile 8135 set 8 10:38 src/main/emailrelay-poke >>> -rw-r--r-- 1 compile compile 2676 dic 7 2013 src/main/emailrelay.rc >>> -rwxr-xr-x 1 compile compile 212614 set 8 10:38 >>> src/main/emailrelay-submit >>> >>> *Instead the folder build_dir/target-your >>> architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >>> (the folder from which the final .ipkg file) contains different length >>> files and this is very strange!* >>> >>> drwxr-xr-x 2 compile compile 4096 set 8 10:55 . >>> drwxr-xr-x 3 compile compile 4096 set 8 10:55 .. >>> -rwxr-xr-x 1 compile compile 410528 set 8 10:56 emailrelay >>> -rwxr-xr-x 1 compile compile 58280 set 8 10:56 emailrelay-filter-copy >>> -rwxr-xr-x 1 compile compile 41704 set 8 10:56 emailrelay-passwd >>> -rwxr-xr-x 1 compile compile 3815 set 8 10:56 emailrelay-poke >>> -rwxr-xr-x 1 compile compile 124624 set 8 10:56 emailrelay-submit >>> >>> >>> Looking at compilation output the following commands are executed after >>> compilation to create the ipkg-ar7xxx folder structure >>> >>> touch >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/.built >>> mkdir -p /home/compile/openwrt/bin/ar71xx/packages >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/CONTROL >>> /home/compile/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2/pkginfo >>> install -d -m0755 >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin >>> install -m0755 >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >>> install -m0755 >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-filter-copy >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >>> install -m0755 >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-passwd >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >>> install -m0755 >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-poke >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >>> install -m0755 >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-submit >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >>> install -d -m0755 >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc >>> install -m0644 files/emailrelay.auth >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/ >>> install -d -m0755 >>> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/init.d >>> install
Re: [OpenWrt-Devel] SStrip strange issue ?!? [Re: There is a error when I build emailrelay-nossl package in openwrt]
Ok please discard this thread, sstrip is fine. On Mon, Sep 8, 2014 at 12:00 PM, Federico Di Marco wrote: > I know that this is seems a very strange behaviour, so I made a screen > video to check it by yourself, you can download the video here > > > https://www.fededim.pw/OpenWrt%20EmailRelay%20compilation%20issue_no%20audio.avi > > On Mon, Sep 8, 2014 at 11:23 AM, Federico Di Marco > wrote: > >> Hi yangjun, >> >> I just gave a quick view to your problem it seems you are right there is >> an issue in the generated ipkg file, eventhough the compilation is fine >> (emailrelay does compile without ssl). In my build machine (architecture >> ar7xxx) at the end build_dir/target-your >> architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main contains the >> correct executables >> >> -rwxr-xr-x 1 compile compile 702462 set 8 10:38 src/main/emailrelay >> -rwxr-xr-x 1 compile compile 99271 set 8 10:38 >> src/main/emailrelay-filter-copy >> -rwxr-xr-x 1 compile compile 68688 set 8 10:38 >> src/main/emailrelay-passwd >> -rwxr-xr-x 1 compile compile 8135 set 8 10:38 src/main/emailrelay-poke >> -rw-r--r-- 1 compile compile 2676 dic 7 2013 src/main/emailrelay.rc >> -rwxr-xr-x 1 compile compile 212614 set 8 10:38 >> src/main/emailrelay-submit >> >> *Instead the folder build_dir/target-your >> architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >> (the folder from which the final .ipkg file) contains different length >> files and this is very strange!* >> >> drwxr-xr-x 2 compile compile 4096 set 8 10:55 . >> drwxr-xr-x 3 compile compile 4096 set 8 10:55 .. >> -rwxr-xr-x 1 compile compile 410528 set 8 10:56 emailrelay >> -rwxr-xr-x 1 compile compile 58280 set 8 10:56 emailrelay-filter-copy >> -rwxr-xr-x 1 compile compile 41704 set 8 10:56 emailrelay-passwd >> -rwxr-xr-x 1 compile compile 3815 set 8 10:56 emailrelay-poke >> -rwxr-xr-x 1 compile compile 124624 set 8 10:56 emailrelay-submit >> >> >> Looking at compilation output the following commands are executed after >> compilation to create the ipkg-ar7xxx folder structure >> >> touch >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/.built >> mkdir -p /home/compile/openwrt/bin/ar71xx/packages >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/CONTROL >> /home/compile/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2/pkginfo >> install -d -m0755 >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin >> install -m0755 >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >> install -m0755 >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-filter-copy >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >> install -m0755 >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-passwd >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >> install -m0755 >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-poke >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >> install -m0755 >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-submit >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ >> install -d -m0755 >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc >> install -m0644 files/emailrelay.auth >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/ >> install -d -m0755 >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/init.d >> install -m0755 files/emailrelay.init >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/init.d/emailrelay >> find >> /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl >> -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs -r rm -rf >> >> *Till this commands the **build_dir/target-your >> architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx directory >> contains the correct files* (i.e the same as those in src/main)*, yet >> when the next command is executed the ipkg-folder changes its contents and >> this is very strange!* (you can try it by yourself by removing
Re: [OpenWrt-Devel] SStrip strange issue ?!? [Re: There is a error when I build emailrelay-nossl package in openwrt]
I know that this is seems a very strange behaviour, so I made a screen video to check it by yourself, you can download the video here https://www.fededim.pw/OpenWrt%20EmailRelay%20compilation%20issue_no%20audio.avi On Mon, Sep 8, 2014 at 11:23 AM, Federico Di Marco wrote: > Hi yangjun, > > I just gave a quick view to your problem it seems you are right there is > an issue in the generated ipkg file, eventhough the compilation is fine > (emailrelay does compile without ssl). In my build machine (architecture > ar7xxx) at the end build_dir/target-your > architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main contains the > correct executables > > -rwxr-xr-x 1 compile compile 702462 set 8 10:38 src/main/emailrelay > -rwxr-xr-x 1 compile compile 99271 set 8 10:38 > src/main/emailrelay-filter-copy > -rwxr-xr-x 1 compile compile 68688 set 8 10:38 src/main/emailrelay-passwd > -rwxr-xr-x 1 compile compile 8135 set 8 10:38 src/main/emailrelay-poke > -rw-r--r-- 1 compile compile 2676 dic 7 2013 src/main/emailrelay.rc > -rwxr-xr-x 1 compile compile 212614 set 8 10:38 src/main/emailrelay-submit > > *Instead the folder build_dir/target-your > architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ > (the folder from which the final .ipkg file) contains different length > files and this is very strange!* > > drwxr-xr-x 2 compile compile 4096 set 8 10:55 . > drwxr-xr-x 3 compile compile 4096 set 8 10:55 .. > -rwxr-xr-x 1 compile compile 410528 set 8 10:56 emailrelay > -rwxr-xr-x 1 compile compile 58280 set 8 10:56 emailrelay-filter-copy > -rwxr-xr-x 1 compile compile 41704 set 8 10:56 emailrelay-passwd > -rwxr-xr-x 1 compile compile 3815 set 8 10:56 emailrelay-poke > -rwxr-xr-x 1 compile compile 124624 set 8 10:56 emailrelay-submit > > > Looking at compilation output the following commands are executed after > compilation to create the ipkg-ar7xxx folder structure > > touch > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/.built > mkdir -p /home/compile/openwrt/bin/ar71xx/packages > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/CONTROL > /home/compile/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2/pkginfo > install -d -m0755 > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin > install -m0755 > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ > install -m0755 > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-filter-copy > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ > install -m0755 > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-passwd > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ > install -m0755 > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-poke > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ > install -m0755 > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-submit > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ > install -d -m0755 > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc > install -m0644 files/emailrelay.auth > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/ > install -d -m0755 > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/init.d > install -m0755 files/emailrelay.init > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/init.d/emailrelay > find > /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl > -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs -r rm -rf > > *Till this commands the **build_dir/target-your > architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx directory > contains the correct files* (i.e the same as those in src/main)*, yet > when the next command is executed the ipkg-folder changes its contents and > this is very strange!* (you can try it by yourself by removing manually > ipkg-ar71xx folder and executing all these commands, according to your > architecture). *Since I don't know what this command does (it's after > compilation) can anybody explain me what is do
Re: [OpenWrt-Devel] mac80211/DFS-support default since r42431
* Jonas Gorski [08.09.2014 11:54]: > detection support in ath9k/ath10k. So if CSAs are an issue, it was > already an issue before. thanks for pointing that, it was not clear to me. > > "somebody" can just mark all channels as "unavailable". > > How would they do that? Especially with non-DFS enabled channels. > Spamming CSAs? I'm pretty sure authorities get interested very fast if > you produce patterns triggering radar detection over a very wide band. as far as i understand, sending a CSA can be done from anybody in IBSS. if a station "hears" a CSA it must mark the channel as "unavailable", because you must "thrust" the CSA. Or is this only when a radar-pattern is detected? > But all of these should only affect you if you try to use a channel > requiring DFS support, and should have no influence when operating on > non-DFS channels. ok. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mac80211/DFS-support default since r42431
On Mon, Sep 8, 2014 at 11:03 AM, Bastian Bittorf wrote: > * Felix Fietkau [08.09.2014 10:36]: >> > is from a security point of view a difficult thing - because everybody >> > can take down a complete city-network. >> I've never heard this claim before. How does enabling this option allow >> people to take down a network? > > the theory is here: > http://battlemesh.org/BattleMeshV7/Agenda?action=AttachFile&do=get&target=2014-05-17_wbmv7_DFS.pdf > > on short - it is a problem for IBSS/adhoc: > if somebody sends a CSA / channel switch announcement which is > not "signed/thrusted", you must switch. So the issue is in CSA, not DFS. I have bad news for you: CSA support is independent of DFS support and (being) implemented in the generic mac80211 layer. All my changeset did was to enable the hardware specific radar detection support in ath9k/ath10k. So if CSAs are an issue, it was already an issue before. > also: > "somebody" can just mark all channels as "unavailable". How would they do that? Especially with non-DFS enabled channels. Spamming CSAs? I'm pretty sure authorities get interested very fast if you produce patterns triggering radar detection over a very wide band. > the question is: is it really implemented in IBSS mode and > what about vif's? (adhoc + ap) There's both multi-vif CSA support as well as IBSS DFS support in mac80211. CSA support was disabled until recently as it had locking issues, but these are supposedly resolved. The current compat-wireless used by OpenWrt still has it disabled. But all of these should only affect you if you try to use a channel requiring DFS support, and should have no influence when operating on non-DFS channels. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] SStrip strange issue ?!? [Re: There is a error when I build emailrelay-nossl package in openwrt]
Hi yangjun, I just gave a quick view to your problem it seems you are right there is an issue in the generated ipkg file, eventhough the compilation is fine (emailrelay does compile without ssl). In my build machine (architecture ar7xxx) at the end build_dir/target-your architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main contains the correct executables -rwxr-xr-x 1 compile compile 702462 set 8 10:38 src/main/emailrelay -rwxr-xr-x 1 compile compile 99271 set 8 10:38 src/main/emailrelay-filter-copy -rwxr-xr-x 1 compile compile 68688 set 8 10:38 src/main/emailrelay-passwd -rwxr-xr-x 1 compile compile 8135 set 8 10:38 src/main/emailrelay-poke -rw-r--r-- 1 compile compile 2676 dic 7 2013 src/main/emailrelay.rc -rwxr-xr-x 1 compile compile 212614 set 8 10:38 src/main/emailrelay-submit *Instead the folder build_dir/target-your architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ (the folder from which the final .ipkg file) contains different length files and this is very strange!* drwxr-xr-x 2 compile compile 4096 set 8 10:55 . drwxr-xr-x 3 compile compile 4096 set 8 10:55 .. -rwxr-xr-x 1 compile compile 410528 set 8 10:56 emailrelay -rwxr-xr-x 1 compile compile 58280 set 8 10:56 emailrelay-filter-copy -rwxr-xr-x 1 compile compile 41704 set 8 10:56 emailrelay-passwd -rwxr-xr-x 1 compile compile 3815 set 8 10:56 emailrelay-poke -rwxr-xr-x 1 compile compile 124624 set 8 10:56 emailrelay-submit Looking at compilation output the following commands are executed after compilation to create the ipkg-ar7xxx folder structure touch /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/.built mkdir -p /home/compile/openwrt/bin/ar71xx/packages /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/CONTROL /home/compile/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2/pkginfo install -d -m0755 /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin install -m0755 /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ install -m0755 /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-filter-copy /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ install -m0755 /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-passwd /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ install -m0755 /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-poke /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ install -m0755 /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/src/main/emailrelay-submit /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/usr/bin/ install -d -m0755 /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc install -m0644 files/emailrelay.auth /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/ install -d -m0755 /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/init.d install -m0755 files/emailrelay.init /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl/etc/init.d/emailrelay find /home/compile/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx/emailrelay-nossl -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs -r rm -rf *Till this commands the **build_dir/target-your architecture_34kc_uClibc-0.9.33.2/emailrelay-1.9/ipkg-ar71xx directory contains the correct files* (i.e the same as those in src/main)*, yet when the next command is executed the ipkg-folder changes its contents and this is very strange!* (you can try it by yourself by removing manually ipkg-ar71xx folder and executing all these commands, according to your architecture). *Since I don't know what this command does (it's after compilation) can anybody explain me what is doing SStrip to the executables in ipkg-ar7xxx folder ?!?! For sure this command affects the executable files in some way as it clearly show the output.* *export CROSS="mips-openwrt-linux-uclibc-" NO_RENAME=1 ; NM="mips-openwrt-linux-uclibc-nm" STRIP="/home/compile/openwrt/staging_dir/host/bin/sstrip" STRIP_KMOD="/home/compile/openwrt/scripts/strip-kmod.sh" /home/compile/openwrt/scripts/rstrip.sh /home/compile/openwrt/
Re: [OpenWrt-Devel] mac80211/DFS-support default since r42431
* Felix Fietkau [08.09.2014 10:36]: > > is from a security point of view a difficult thing - because everybody > > can take down a complete city-network. > I've never heard this claim before. How does enabling this option allow > people to take down a network? the theory is here: http://battlemesh.org/BattleMeshV7/Agenda?action=AttachFile&do=get&target=2014-05-17_wbmv7_DFS.pdf on short - it is a problem for IBSS/adhoc: if somebody sends a CSA / channel switch announcement which is not "signed/thrusted", you must switch. also: "somebody" can just mark all channels as "unavailable". the question is: is it really implemented in IBSS mode and what about vif's? (adhoc + ap) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] for ramips/mt7620a, emailrelay-nossl fails to build
On Mon, 8 Sep 2014, Etienne Champetier wrote: > > Hi > Le 7 sept. 2014 23:40, "Robert P. J. Day" a écrit : > > > > > > still reviewing so i don't think i have the background to debug this > > one: > > > > $ make V=s > > ... big snip ... > > Package emailrelay-nossl is missing dependencies for the following > > libraries: > > libcrypto.so.1.0.0 > > libssl.so.1.0.0 > > Makefile:118: recipe for target > '/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk' > failed > > make[3]: *** > > [/home/rpjday/openwrt/git/bin/ramips/packages/emailrelay-nossl_1.9-1_ramips_24kec.ipk] > > Error 1 > > > > i'm using the default config.ramips_mt7620a config file. thoughts? > > > > rday > > > > Please open an issue on github github? the FAQ instructs one to report bugs here: http://dev.openwrt.org/report can you clarify? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] imx6: fix image build for Generic profile.
Signed-off-by: Yousong Zhou --- I do not own a board that can run imx6 target firmware, but this patch has been compile tested by myself and aandrew in #openwrt. target/linux/imx6/image/Makefile | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/target/linux/imx6/image/Makefile b/target/linux/imx6/image/Makefile index 2e2e11b..391db78 100644 --- a/target/linux/imx6/image/Makefile +++ b/target/linux/imx6/image/Makefile @@ -13,14 +13,16 @@ endef define Image/BuildKernel/Template + ifneq ($(1),) $(CP) $(DTS_DIR)/$(1).dtb $(BIN_DIR)/$(IMG_PREFIX)-$(1).dtb $(call Image/BuildKernel/MkFIT,$(1),$(KDIR)/zImage,$(BIN_DIR)/$(IMG_PREFIX)-$(1).dtb,none,0x10008000,0x10008000) $(CP) $(KDIR)/fit-$(1).itb $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fit-uImage.itb - ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) + ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) $(call Image/BuildKernel/MkFIT,$(1),$(KDIR)/zImage-initramfs,$(BIN_DIR)/$(IMG_PREFIX)-$(1).dtb,none,0x10008000,0x10008000,-initramfs) $(CP) $(KDIR)/fit-$(1)-initramfs.itb $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fit-uImage-initramfs.itb + endif endif $(CP) $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage @@ -71,10 +73,10 @@ endef define Image/Build/squashfs $(call prepare_generic_squashfs,$(KDIR)/root.$(1)) dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-$(1).bin bs=128k conv=sync - ( \ + [ -f "$(BIN_DIR)/$(IMG_PREFIX)-$(call sanitize_profile_name)-fit-uImage.itb" ] && ( \ dd if=$(BIN_DIR)/$(IMG_PREFIX)-$(call sanitize_profile_name)-fit-uImage.itb bs=2048k conv=sync; \ dd if=$(KDIR)/root.$(1) bs=128k conv=sync; \ - ) > $(BIN_DIR)/$(IMG_PREFIX)-$(call sanitize_profile_name)-fit-$(1).bin + ) > $(BIN_DIR)/$(IMG_PREFIX)-$(call sanitize_profile_name)-fit-$(1).bin || true endef define Image/mkfs/targz @@ -107,8 +109,8 @@ define Image/Build/ubi endef -Image/BuildKernel/Template/generic=$(call Image/BuildKernel/Template) -Image/InstallKernel/Template/generic=$(call Image/InstallKernel/Template) +Image/BuildKernel/Template/Generic=$(call Image/BuildKernel/Template) +Image/InstallKernel/Template/Generic=$(call Image/InstallKernel/Template) Image/BuildKernel/Template/IMX6DL_WANDBOARD=$(call Image/BuildKernel/Template,imx6dl-wandboard) Image/InstallKernel/Template/IMX6DL_WANDBOARD=$(call Image/InstallKernel/Template,imx6dl-wandboard) -- 1.7.10.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] USB crash when USB WiFi dongle is used (RTL8192CU) - WDR4300
Problem is already fixed. Please look: https://dev.openwrt.org/ticket/17706 Commit id is b00ac8067148e43f43b690c754bd92802a1514c1 Thanks, Lukasz On Tue, Aug 12, 2014 at 11:42 AM, Bastian Bittorf wrote: > * Łukasz Baj [11.08.2014 16:56]: > > 3.14.12. When I connect this dongle to USB and then disconnect it I see > > following crash and USB stops working. Any ideas how to fix this problem? > > does it also happen, when you force a 'wifi down' before unplugging? > (please check with 'iw dev wlan0 info' if it is really off) > > bye, bastian > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mac80211/DFS-support default since r42431
On 2014-09-08 08:52, Bastian Bittorf wrote: > with r42431 DFS is enabled by default[1]: > > "mac80211: enable DFS support for ath9k/10k by default The DFS pattern > detector now supports all three regions; ETSI, FCC and JP, so there is > no reason to not have it enabled anymore." > > there was a long discussion on battlemesh/Leipzig[2] that this > is from a security point of view a difficult thing - because everybody > can take down a complete city-network. I've never heard this claim before. How does enabling this option allow people to take down a network? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mac80211/DFS-support default since r42431
with r42431 DFS is enabled by default[1]: "mac80211: enable DFS support for ath9k/10k by default The DFS pattern detector now supports all three regions; ETSI, FCC and JP, so there is no reason to not have it enabled anymore." there was a long discussion on battlemesh/Leipzig[2] that this is from a security point of view a difficult thing - because everybody can take down a complete city-network. I'am unsure about the decision: a) selfbuilders can disable it b) it changes the default behaviour what do you think about it? bye, bastian [1] https://dev.openwrt.org/changeset/42431/trunk [2] http://www.battlemesh.org/BattleMeshV7 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
