Re: [OpenWrt-Devel] uClibc-ng
On Sun, Jul 20, 2014 at 9:13 PM, Waldemar Brodkorb w...@uclibc-ng.org wrote: Hello Embedded Linux Hackers, it seems there is no plan to release a new uClibc version. The current maintainer does not response on any public or private mails about a plan to do a needed release. Therefore most of you carrying a lot of patches against uClibc 0.9.33.2 to make it work in your project. A really ugly situation. I have seen some patches got in uClibc upstream some weeks ago (- inactivity). But anyway, a 1st try... Look at OpenSSL and LibreSSL... Might be we see some competition or rebirth starting here, too? My POV (from my experiences) is most embedded projects are not really interested in upstream work or keep their own patches (this seems to be easier). An example: Recently, I pointed to [0], but the maintainer of the project did not give any feedback to Bernd (requested a simple S-o-b). What I want to say it is not only a problem of the uClibc maintainer :-). From my experiences successful projects do regular releases (6 months or a year). What are your plans? To get out of this situation I started a spin-off called uClibc-ng. The website for the project is here: http://www.uclibc-ng.org Beta 3 is tagged and downloadable via http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz Do you plan a browsable Git website, where someone can look at the source via webbrowser? OK, you have now an infrastructure... Do you have people (developers, users) behind you :-)? If you want a 1.0 in the near future please test and report back any issues. You can use the bug tracker, the mailing list or dicussion forum to report back. To prevent spam you need to be subscribed or registered. I have added most of the patches from your projects on top of uClibc master. Did you look also at the patches [1] from the Freetz project? Thanks for your initial work! - Sedat - [0] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/0.9.32.1/100-fix_hosttools.patch [1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Duplicate netifd protocol for l2tp
On 19.07.2014 08:48, Baptiste Jonglez wrote: Hi, Two packages provide the proto l2tp netifd protocol: xl2tpd [1] in the new packages feed, and l2tpv3tun [2] in oldpackages. The config are totally different, the problem is really a name clash. It seems they are doing things differently xl2tpd is RFC2661 (https://github.com/xelerance/xl2tpd/blob/master/README.xl2tpd) l2tpv3 is RFC5641 (http://tools.ietf.org/html/rfc5641) changes are in: http://tools.ietf.org/html/rfc3931#section-1.1 What is the recommended way to deal with name clashes in netifd protocols, without breaking existing user configuration? In this case, using proto l2tpv2 for xl2tpd and proto l2tpv3 for l2tpv3tun would probably be the cleanest, but it would break configuration for anyone using one or the other :) clean versions leads to less confusion Note that only the l2tpv3tun configuration is documented right now [3]. Thanks, Baptiste [1] https://github.com/openwrt/packages/tree/master/net/xl2tpd [2] http://git.openwrt.org/?p=packages.git;a=tree;f=net/l2tpv3tun [3] http://wiki.openwrt.org/doc/uci/network#protocol.l2tp.l2tp.pseudowire.tunnel I wrote something about l2tpv3tun earlier,see : http://patchwork.openwrt.org/patch/4891/ Arguments for using iproute2 instead of l2tpv3tun might still apply ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi, On Sun, Jul 20, 2014 at 03:50:24PM -0700, David Lang wrote: I'm well aware of all the bullshit that is knocking on my doors all day. Point is, firewalls on the *routers* are not goint to help the laptop that moves around, attaches to a Wifi Hotspot, is hacked there, gets moved back behind your firewall, and starts hacking others from there. And it doesn't help the desktop PC that neglected to do any updates, gets infected by flash/pdf/word exploit, and starts scanning your network, behind the firewall. The problem here isn't with laptops, it's with TVs, light Bulbs, Thermostats, digital picture frames, etc. These are the types of devices that I'm worried about protecting. Yes, so how do you protect them from the malware on your PC and Laptop, which both are behind the firewall? A hacker from the wild is likely to not even *find* the device if it's using EUI64 IPv6 addressing and not registered in DNS, while an attacker on the same LAN just needs to ping ff02::1 to see them all, wide open... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgppN212beHLO.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] Duplicate netifd protocol for l2tp
Steven Barth wrote: I renamed the xl2tpd netifd protocol to l2tpv2 and kept the l2tpv3 as l2tp as documented in the wiki. Thanks :) On Mon, Jul 21, 2014 at 08:47:58AM +0200, Dirk Neukirchen wrote: The config are totally different, the problem is really a name clash. It seems they are doing things differently xl2tpd is RFC2661 (https://github.com/xelerance/xl2tpd/blob/master/README.xl2tpd) l2tpv3 is RFC5641 (http://tools.ietf.org/html/rfc5641) changes are in: http://tools.ietf.org/html/rfc3931#section-1.1 Yes, L2TPv2 and L2TPv3 are quite different. L2TPv2 is tightly coupled with PPP, while L2TPv3 allows static tunnels. I wrote something about l2tpv3tun earlier,see : http://patchwork.openwrt.org/patch/4891/ Arguments for using iproute2 instead of l2tpv3tun might still apply Interesting, I didn't know iproute could handle static L2TP tunnels. In the case of L2TPv2, a daemon is needed to handle the PPP part. On a related note, there is a large amount of code duplication in network scripts when dealing with PPP (ppp, pppoe, pppoa, pptp and l2tpv2 protocols). pgplchUzv74W8.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] OpenWRT IPv6 firewall
On Mon, 21 Jul 2014, Gert Doering wrote: Hi, On Sun, Jul 20, 2014 at 03:50:24PM -0700, David Lang wrote: I'm well aware of all the bullshit that is knocking on my doors all day. Point is, firewalls on the *routers* are not goint to help the laptop that moves around, attaches to a Wifi Hotspot, is hacked there, gets moved back behind your firewall, and starts hacking others from there. And it doesn't help the desktop PC that neglected to do any updates, gets infected by flash/pdf/word exploit, and starts scanning your network, behind the firewall. The problem here isn't with laptops, it's with TVs, light Bulbs, Thermostats, digital picture frames, etc. These are the types of devices that I'm worried about protecting. Yes, so how do you protect them from the malware on your PC and Laptop, which both are behind the firewall? A hacker from the wild is likely to not even *find* the device if it's using EUI64 IPv6 addressing and not registered in DNS, while an attacker on the same LAN just needs to ping ff02::1 to see them all, wide open... The argument was that laptops are better protected nowdays because they routinely get exposed outside the home network. I agree that they are far better than they used to be, but I am saying that there is this other class of devices that is not benefiting from the attention that the desktop OSs are getting, and these devices are absolutly quality. no, having a default-deny permiter doesn't protect you from a laptop on the inside, but it does protect you from everyone else's laptops outside. While it is nice to say that IPv6 has a large address space and so nobody will ever scan it, I don't believe it. When IPv4 started out, people didn't believe that scanning it was going to be practical either. And since common methods of assigning IPv6 addresses are either sequential (DHCP) or based on MAC addresses (fairly predictable per vendor), I expect that scanning is going to continue. As for the doing a scan against someone else's IPv6 address space is a DoS against your service, remember that these people aren't doing the scan from _their_ internet connection, they are doing it from botnets, so they are using free bandwidth David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
Hi, On Mon, Jul 21, 2014 at 12:18:46AM -0700, David Lang wrote: While it is nice to say that IPv6 has a large address space and so nobody will ever scan it, I don't believe it. Don't believe. Try math. 2^64 is big enough that if you manage to send a few 1000 packets a second, you'll need up to the heat death of the universe to scan a single /64 subnet... (Of course this can be optimized if you're targeting very specific devices and only need to scan 2^24 potential EUI64 addresses in a given vendor's MAC range - but that's not your Joe Random attacker. If someone is that determined, he'll just target your PC first, and jump from there to the devices on your LAN. Way easier in general) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp9RQ4rBklXV.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] [PATCH] lantiq xway: generate ramdisk image by default
If you would that would be great. It is not essential, but that way all the necessary downloads would be in one place on the official openwrt site. Thank you, Ben On Sun, 2014-07-20 at 11:12 +0200, John Crispin wrote: i can build a ramdisk for the board for the reelase if it is needed to install. we do the same for the mikrotik boards. John On 20/07/2014 10:03, Ben Mulvihill wrote: No problem. I'll try to make sure there is a link to a non-official ramdisk image on the wiki. (Along with some installation instructions, which at the moment are lacking!) Ben On Sun, 2014-07-20 at 08:54 +0200, John Crispin wrote: technically correct. however there is a dependency bug left over from some cargo cult cleanups. this causes the image builder to not build when ramdisk is enabled. i plan to clean this up post BB. i will ignore this patch until said time. John On 19/07/2014 15:13, Ben Mulvihill wrote: The installation process on nand-based boards using ubi like the BTHOMEHUBV2B makes use of a ramdisk image, so it makes sense to generate this by default. Signed-off-by: Ben Mulvihill ben.mulvih...@gmail.com --- --- a/target/linux/lantiq/xway/target.mk 2014-07-19 14:59:39.691201637 +0200 +++ b/target/linux/lantiq/xway/target.mk 2014-07-19 12:40:06.101871732 +0200 @@ -1,7 +1,7 @@ ARCH:=mips SUBTARGET:=xway BOARDNAME:=XWAY -FEATURES:=squashfs atm mips16 nand ubifs +FEATURES:=squashfs atm mips16 nand ubifs ramdisk CPU_TYPE:=34kc CPU_SUBTYPE:=dsp ___ 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 ___ 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] OpenWRT IPv6 firewall
On Mon, 21 Jul 2014, Gert Doering wrote: On Mon, Jul 21, 2014 at 12:18:46AM -0700, David Lang wrote: While it is nice to say that IPv6 has a large address space and so nobody will ever scan it, I don't believe it. Don't believe. Try math. 2^64 is big enough that if you manage to send a few 1000 packets a second, you'll need up to the heat death of the universe to scan a single /64 subnet... (Of course this can be optimized if you're targeting very specific devices and only need to scan 2^24 potential EUI64 addresses in a given vendor's MAC range - but that's not your Joe Random attacker. If someone is that determined, he'll just target your PC first, and jump from there to the devices on your LAN. Way easier in general) If someone is targeting you specifically, there are all sorts of other scenarios that come into play. I consider those out of scope for this sort of discussion. We are talking about what is appropriate as the default to defend against the normal Internet Badness, not against targeted threats or the NSA. You are effectivly saying that security by obscurity is good enough. You are assuming that IP address assignments are going to be random enough to make scanning worthless, so no other protection is needed. I just don't buy that. I don't believe that the addresses are really going to end up beng that random. Plus there will need to be some way for devices to be discovered, which will probably be via broadcasts. I don't believe that the devices are going to be secured to the point where these broadcasts will only work from the local network. It doesn't matter how big the per-network address space is if devices respond to the one broadcast address for the network. Also, if the devices intend to be accessible, are they really going to ask people to enter IPv6 IP addresses into configs? or are they going to be publishing themselves to DNS or some other nameserver that will make them easier to find? If you have a SIP phone that you want to just work, how are the legitimate remote users going to find it? So I'm saying that we still need to block inbound access from random external IP addresses by default. I could see having the firewall look for outbond packets from the devices and opening up inbound rules from those IPs Even if it allowed access on all ports from the entire source network it would still be better than anyone on the Internet. this would make getting something work between networks not be on by default, but once each side tries to connect to the other, things would be open. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] luci-app-minidlna disables minidlna?
Hi Garbor,
In luci-app-mindlna we find the following in
/etc/uci-defaults/luci-minidlna:
3 /etc/init.d/minidlna enabled {
4 /etc/init.d/minidlna stop
5 /etc/init.d/minidlna disable
6 }
Which disables MiniDLNA startup and is a quite unexpected side-effect of
installing a web-interface plugin, don't you think? Any reason for
this? Can this be removed?
bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] luci-app-minidlna disables minidlna?
Am 21.07.2014 11:18, schrieb Bruno Randolf:
Hi Garbor,
In luci-app-mindlna we find the following in
/etc/uci-defaults/luci-minidlna:
3 /etc/init.d/minidlna enabled {
4 /etc/init.d/minidlna stop
5 /etc/init.d/minidlna disable
6 }
Which disables MiniDLNA startup and is a quite unexpected side-effect of
installing a web-interface plugin, don't you think? Any reason for
this? Can this be removed?
bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi,
found some other luci-apps enabling the service during package installation.
I think luci-apps should leave the current status of installed services
untouched.
If a service is configured and luci installation disable the service thats not
good.
In the other case (i.e. luci-app-samba) enabling a service during installation
or
during build via make or imagebuilder is also not good because the service is
not yet configured.
In general it's easy to enable/disable services via LuCi interface.
Christian
---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz
ist aktiv.
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] Sysupgrade to Barrier Breaker on au1000 (MTX-1)
On 07/18/2014 06:25 PM, John Crispin wrote: 4) we make a script that we call after the build on the server that repackages the images how about that ? Hmmm, I think it should not be done on the server, but as part of the OpenWRT build - also if I compile locally I would like to get a sysupgrade image to upgrade from AA to BB... Relying on server scripts would exclude this possibility, and also make more awkward to maintain your build server scripts (special cases for rare platforms). It would be possible to create a special image for upgrade from AA, something like openwrt-au1000-au1500-jffs2-128k-sysupgrade-from-12.09.bin, but I think it's simpler to just add a symlink to the tar.gz in all cases, like this: diff --git a/target/linux/au1000/image/Makefile b/target/linux/au1000/image/Makefile index 63c0b03..060f87a 100644 --- a/target/linux/au1000/image/Makefile +++ b/target/linux/au1000/image/Makefile @@ -63,8 +63,11 @@ define Image/Build $(CP) $(KDIR)/kernel.flash.srec $(BIN_DIR)/$(IMG_PREFIX)-vmlinux-flash.srec $(CP) $(KDIR)/kernel.ram.srec $(BIN_DIR)/$(IMG_PREFIX)-vmlinux-ram.srec $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(1).fs $(TMP_DIR)/$(IMG_PREFIX)-root.fs + # link for backwards compatibility with Attitude Adjustment + ln -sfn $(TMP_DIR)/$(IMG_PREFIX)-root.fs $(TMP_DIR)/$(IMG_PREFIX)-jffs2-128k.fs tar -C $(BIN_DIR) -cvzf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-sysupgrade.bin \ - $(IMG_PREFIX)-vmlinux.bin -C $(TMP_DIR) $(IMG_PREFIX)-root.fs + $(IMG_PREFIX)-vmlinux.bin -C $(TMP_DIR) $(IMG_PREFIX)-root.fs \ + $(IMG_PREFIX)-jffs2-128k.fs ifeq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y) $(call Image/Build/Initramfs) endif What do you think? If you agree I will post this as a properly formatted patch. bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] trac/rss-feed has changed?
* Mathias Kresin open...@kresin.me [18.07.2014 19:36]: i'm using the rss feed from gitweb http://git.openwrt.org/?p=openwrt.git;a=atom;opt=--no-merges which works quite nice. works, thank you! - bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq xway: generate ramdisk image by default
sure, i also just figured out why the rc1 lantiq images dont have dsl enabled by default. i will pusah a fix to trunk tonight once i tested it properly John On 21/07/2014 10:29, Ben Mulvihill wrote: If you would that would be great. It is not essential, but that way all the necessary downloads would be in one place on the official openwrt site. Thank you, Ben On Sun, 2014-07-20 at 11:12 +0200, John Crispin wrote: i can build a ramdisk for the board for the reelase if it is needed to install. we do the same for the mikrotik boards. John On 20/07/2014 10:03, Ben Mulvihill wrote: No problem. I'll try to make sure there is a link to a non-official ramdisk image on the wiki. (Along with some installation instructions, which at the moment are lacking!) Ben On Sun, 2014-07-20 at 08:54 +0200, John Crispin wrote: technically correct. however there is a dependency bug left over from some cargo cult cleanups. this causes the image builder to not build when ramdisk is enabled. i plan to clean this up post BB. i will ignore this patch until said time. John On 19/07/2014 15:13, Ben Mulvihill wrote: The installation process on nand-based boards using ubi like the BTHOMEHUBV2B makes use of a ramdisk image, so it makes sense to generate this by default. Signed-off-by: Ben Mulvihill ben.mulvih...@gmail.com --- --- a/target/linux/lantiq/xway/target.mk 2014-07-19 14:59:39.691201637 +0200 +++ b/target/linux/lantiq/xway/target.mk 2014-07-19 12:40:06.101871732 +0200 @@ -1,7 +1,7 @@ ARCH:=mips SUBTARGET:=xway BOARDNAME:=XWAY -FEATURES:=squashfs atm mips16 nand ubifs +FEATURES:=squashfs atm mips16 nand ubifs ramdisk CPU_TYPE:=34kc CPU_SUBTYPE:=dsp ___ 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 ___ 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] Sysupgrade to Barrier Breaker on au1000 (MTX-1)
On 07/21/2014 12:28 PM, Bruno Randolf wrote: It would be possible to create a special image for upgrade from AA, something like openwrt-au1000-au1500-jffs2-128k-sysupgrade-from-12.09.bin, but I think it's simpler to just add a symlink to the tar.gz in all cases, The symlink approach does not work, as dd does not recognize the symlink and the rootfs is broken afterwards. So IMHO the best solution is to create a special sysupgrade image for upgrade from 12.09, like openwrt-au1000-au1500-jffs2-128k-sysupgrade-from-12.09.bin... diff --git a/target/linux/au1000/image/Makefile b/target/linux/au1000/image/Makefile index 63c0b03..56f613b 100644 --- a/target/linux/au1000/image/Makefile +++ b/target/linux/au1000/image/Makefile @@ -65,6 +65,10 @@ define Image/Build $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(1).fs $(TMP_DIR)/$(IMG_PREFIX)-root.fs tar -C $(BIN_DIR) -cvzf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-sysupgrade.bin \ $(IMG_PREFIX)-vmlinux.bin -C $(TMP_DIR) $(IMG_PREFIX)-root.fs + # backwards compatible image for upgrade from Attitude Adjustment (12.09) + $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(1).fs $(TMP_DIR)/$(IMG_PREFIX)-jffs2-128k.fs + tar -C $(BIN_DIR) -cvzf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-sysupgrade-from-12.09.bin \ + $(IMG_PREFIX)-vmlinux.bin -C $(TMP_DIR) $(IMG_PREFIX)-jffs2-128k.fs ifeq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y) $(call Image/Build/Initramfs) endif bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade to Barrier Breaker on au1000 (MTX-1)
Hi Bruno i will merge a patch post the rc2 fork that will generate old and new images int he release branch while not doing so in the dev trunk. i really dont want any workarounds in trunk how about that ? John On 21/07/2014 15:20, Bruno Randolf wrote: On 07/21/2014 12:28 PM, Bruno Randolf wrote: It would be possible to create a special image for upgrade from AA, something like openwrt-au1000-au1500-jffs2-128k-sysupgrade-from-12.09.bin, but I think it's simpler to just add a symlink to the tar.gz in all cases, The symlink approach does not work, as dd does not recognize the symlink and the rootfs is broken afterwards. So IMHO the best solution is to create a special sysupgrade image for upgrade from 12.09, like openwrt-au1000-au1500-jffs2-128k-sysupgrade-from-12.09.bin... diff --git a/target/linux/au1000/image/Makefile b/target/linux/au1000/image/Makefile index 63c0b03..56f613b 100644 --- a/target/linux/au1000/image/Makefile +++ b/target/linux/au1000/image/Makefile @@ -65,6 +65,10 @@ define Image/Build $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(1).fs $(TMP_DIR)/$(IMG_PREFIX)-root.fs tar -C $(BIN_DIR) -cvzf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-sysupgrade.bin \ $(IMG_PREFIX)-vmlinux.bin -C $(TMP_DIR) $(IMG_PREFIX)-root.fs + # backwards compatible image for upgrade from Attitude Adjustment (12.09) + $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(1).fs $(TMP_DIR)/$(IMG_PREFIX)-jffs2-128k.fs + tar -C $(BIN_DIR) -cvzf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-sysupgrade-from-12.09.bin \ + $(IMG_PREFIX)-vmlinux.bin -C $(TMP_DIR) $(IMG_PREFIX)-jffs2-128k.fs ifeq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y) $(call Image/Build/Initramfs) endif bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [mpc83xx] add menuconfig-option for rb333 and rb600
Add new target-profile for both boards in menuconfig. Replaced unconditional Makefile directives with such that depends on menuconfig settings. The default behaviour remains to be as it was: to compile for both. Signed-off-by: Claudio Thomas c...@xmodus-systems.de --- target/linux/mpc83xx/Makefile | 12 +++- target/linux/mpc83xx/image/Makefile | 10 -- target/linux/mpc83xx/profiles/00-default.mk | 16 target/linux/mpc83xx/profiles/mikrotik.mk | 24 4 files changed, 59 insertions(+), 3 deletions(-) create mode 100644 target/linux/mpc83xx/profiles/00-default.mk create mode 100644 target/linux/mpc83xx/profiles/mikrotik.mk diff --git a/target/linux/mpc83xx/Makefile b/target/linux/mpc83xx/Makefile index 915faec..6a49c53 100644 --- a/target/linux/mpc83xx/Makefile +++ b/target/linux/mpc83xx/Makefile @@ -23,6 +23,16 @@ define Target/Description Build firmware images for Freescale MPC83xx based boards (eg. RouterBoard 600). endef -KERNELNAME:=uImage dtbImage.rb600 dtbImage.rb333 +KERNELNAME:=uImage +ifeq ($(CONFIG_TARGET_mpc83xx_Default),y) + KERNELNAME+=dtbImage.rb600 dtbImage.rb333 +else + ifeq ($(CONFIG_TARGET_mpc83xx_rb333),y) + KERNELNAME+=dtbImage.rb333 + endif + ifeq ($(CONFIG_TARGET_mpc83xx_rb600),y) + KERNELNAME+=dtbImage.rb600 + endif +endif $(eval $(call BuildTarget)) diff --git a/target/linux/mpc83xx/image/Makefile b/target/linux/mpc83xx/image/Makefile index c7458f1..3921426 100644 --- a/target/linux/mpc83xx/image/Makefile +++ b/target/linux/mpc83xx/image/Makefile @@ -13,8 +13,14 @@ define Image/Prepare endef define Image/BuildKernel - cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb600.elf $(BIN_DIR)/openwrt-$(BOARD)-rb600.elf - cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb333.elf $(BIN_DIR)/openwrt-$(BOARD)-rb333.elf + $(if $(filter $(CONFIG_TARGET_mpc83xx_Default),y), \ + cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb333.elf $(BIN_DIR)/openwrt-$(BOARD)-rb333.elf; \ + cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb600.elf $(BIN_DIR)/openwrt-$(BOARD)-rb600.elf; \ + ) + $(if $(filter $(CONFIG_TARGET_mpc83xx_rb333),y), \ + cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb333.elf $(BIN_DIR)/openwrt-$(BOARD)-rb333.elf ) + $(if $(filter $(CONFIG_TARGET_mpc83xx_rb600),y), \ + cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb600.elf $(BIN_DIR)/openwrt-$(BOARD)-rb600.elf ) cp $(KDIR)/uImage $(BIN_DIR)/openwrt-$(BOARD)-uImage endef diff --git a/target/linux/mpc83xx/profiles/00-default.mk b/target/linux/mpc83xx/profiles/00-default.mk new file mode 100644 index 000..b30c4b6 --- /dev/null +++ b/target/linux/mpc83xx/profiles/00-default.mk @@ -0,0 +1,16 @@ +# +# Copyright (C) 2014 Xmodus Systems GmbH, Claudio Thomas c...@xmodus-systems.de +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Default + NAME:=Default (all) +endef + +define Profile/Default/Description + Default package set compatible with most boards (compile all). +endef +$(eval $(call Profile,Default)) + diff --git a/target/linux/mpc83xx/profiles/mikrotik.mk b/target/linux/mpc83xx/profiles/mikrotik.mk new file mode 100644 index 000..389ff12 --- /dev/null +++ b/target/linux/mpc83xx/profiles/mikrotik.mk @@ -0,0 +1,24 @@ +# +# Copyright (C) 2014 Xmodus Systems GmbH, Claudio Thomas c...@xmodus-systems.de +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/rb333 + NAME:=Mikrotik RouterBOARD 333 +endef + +define Profile/rb333/Description + Mikrotik RouterBOARD 333. +endef +$(eval $(call Profile,rb333)) + +define Profile/rb600 + NAME:=Mikrotik RouterBOARD 600 +endef + +define Profile/rb600/Description + Mikrotik RouterBOARD 600. +endef +$(eval $(call Profile,rb600)) -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [mpc83xx] add menuconfig-option for rb333 and rb600
Add new target-profile for both boards in menuconfig. Replaced unconditional Makefile directives with such that depends on menuconfig settings. The default behaviour remains to be as it was: to compile for both. Signed-off-by: Claudio Thomas c...@xmodus-systems.de --- target/linux/mpc83xx/Makefile | 12 +++- target/linux/mpc83xx/image/Makefile | 10 -- target/linux/mpc83xx/profiles/00-default.mk | 16 target/linux/mpc83xx/profiles/mikrotik.mk | 24 4 files changed, 59 insertions(+), 3 deletions(-) create mode 100644 target/linux/mpc83xx/profiles/00-default.mk create mode 100644 target/linux/mpc83xx/profiles/mikrotik.mk diff --git a/target/linux/mpc83xx/Makefile b/target/linux/mpc83xx/Makefile index 915faec..6a49c53 100644 --- a/target/linux/mpc83xx/Makefile +++ b/target/linux/mpc83xx/Makefile @@ -23,6 +23,16 @@ define Target/Description Build firmware images for Freescale MPC83xx based boards (eg. RouterBoard 600). endef -KERNELNAME:=uImage dtbImage.rb600 dtbImage.rb333 +KERNELNAME:=uImage +ifeq ($(CONFIG_TARGET_mpc83xx_Default),y) + KERNELNAME+=dtbImage.rb600 dtbImage.rb333 +else + ifeq ($(CONFIG_TARGET_mpc83xx_rb333),y) + KERNELNAME+=dtbImage.rb333 + endif + ifeq ($(CONFIG_TARGET_mpc83xx_rb600),y) + KERNELNAME+=dtbImage.rb600 + endif +endif $(eval $(call BuildTarget)) diff --git a/target/linux/mpc83xx/image/Makefile b/target/linux/mpc83xx/image/Makefile index c7458f1..3921426 100644 --- a/target/linux/mpc83xx/image/Makefile +++ b/target/linux/mpc83xx/image/Makefile @@ -13,8 +13,14 @@ define Image/Prepare endef define Image/BuildKernel - cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb600.elf $(BIN_DIR)/openwrt-$(BOARD)-rb600.elf - cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb333.elf $(BIN_DIR)/openwrt-$(BOARD)-rb333.elf + $(if $(filter $(CONFIG_TARGET_mpc83xx_Default),y), \ + cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb333.elf $(BIN_DIR)/openwrt-$(BOARD)-rb333.elf; \ + cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb600.elf $(BIN_DIR)/openwrt-$(BOARD)-rb600.elf; \ + ) + $(if $(filter $(CONFIG_TARGET_mpc83xx_rb333),y), \ + cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb333.elf $(BIN_DIR)/openwrt-$(BOARD)-rb333.elf ) + $(if $(filter $(CONFIG_TARGET_mpc83xx_rb600),y), \ + cp $(LINUX_DIR)/arch/powerpc/boot/dtbImage.rb600.elf $(BIN_DIR)/openwrt-$(BOARD)-rb600.elf ) cp $(KDIR)/uImage $(BIN_DIR)/openwrt-$(BOARD)-uImage endef diff --git a/target/linux/mpc83xx/profiles/00-default.mk b/target/linux/mpc83xx/profiles/00-default.mk new file mode 100644 index 000..b30c4b6 --- /dev/null +++ b/target/linux/mpc83xx/profiles/00-default.mk @@ -0,0 +1,16 @@ +# +# Copyright (C) 2014 Xmodus Systems GmbH, Claudio Thomas c...@xmodus-systems.de +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Default + NAME:=Default (all) +endef + +define Profile/Default/Description + Default package set compatible with most boards (compile all). +endef +$(eval $(call Profile,Default)) + diff --git a/target/linux/mpc83xx/profiles/mikrotik.mk b/target/linux/mpc83xx/profiles/mikrotik.mk new file mode 100644 index 000..389ff12 --- /dev/null +++ b/target/linux/mpc83xx/profiles/mikrotik.mk @@ -0,0 +1,24 @@ +# +# Copyright (C) 2014 Xmodus Systems GmbH, Claudio Thomas c...@xmodus-systems.de +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/rb333 + NAME:=Mikrotik RouterBOARD 333 +endef + +define Profile/rb333/Description + Mikrotik RouterBOARD 333. +endef +$(eval $(call Profile,rb333)) + +define Profile/rb600 + NAME:=Mikrotik RouterBOARD 600 +endef + +define Profile/rb600/Description + Mikrotik RouterBOARD 600. +endef +$(eval $(call Profile,rb600)) -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [project/ucwmp.git][PATCH V2] session: check for uclient_connect return value
uclient_connect may return an error and calling uclient_write will cause
a crash
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: Use exit, otherwise cwmp-session will hang... no idea why :(
---
session/main.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/session/main.c b/session/main.c
index 147c949..e35cd5b 100644
--- a/session/main.c
+++ b/session/main.c
@@ -139,9 +139,16 @@ static void cwmp_dump_message(const char *msg, const char
*data)
static void __cwmp_send_request(struct uloop_timeout *t)
{
int len = 0;
+ int err;
+
cwmp_dump_message(Send CPE data, cur_request);
- uclient_connect(uc);
+ err = uclient_connect(uc);
+ if (err) {
+ fprintf(stderr, Failed to connect to the server: %d\n, err);
+ exit(255);
+ }
+
uclient_http_set_request_type(uc, POST);
cwmp_add_cookies(uc);
--
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] [Buildroot] uClibc-ng
Hi Thomas, Thomas De Schampheleire wrote, Hi Waldemar, Waldemar Brodkorb w...@uclibc-ng.org schreef: Hello Embedded Linux Hackers, Interesting development! One question: how do you see musl vs uclibc-ng in the future? At this moment uclibc supports more architectures, but this may change. Do you think both should/can coexist? What are the distinctive features of uclibc over musl, according to you? I think both can coexist for a while. uClibc is more compatible to glibc, so most of the software packages used on embedded systems are working fine without patching. Musl is relatively new and there are patches required to make some stuff work. Alpine Linux, Sabotage and OpenADK have a lot of patches, fixing musl issues. uClibc has support for non-MMU systems. uClibc can be configured at build time and can be made smaller than musl. Musl can be used to have a complete static linked system, uClibc still requires libgcc_so.so for some threading functions. uClibc is widely used in the embedded Linux world, musl is a newcomer. For musl you need to patch gcc. 4.9.x does not include support for it. It is just good to have a choice. At the time all software packages working fine with musl and support for it is added to gcc and all architectures and MMU-less systems are supported, uClibc might be obsolete. best regards Waldemar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade to Barrier Breaker on au1000 (MTX-1)
On 07/21/2014 02:22 PM, John Crispin wrote: i will merge a patch post the rc2 fork that will generate old and new images int he release branch while not doing so in the dev trunk. i really dont want any workarounds in trunk how about that ? Sounds OK to me. Anyhow there are not so many au1000 users out there and I guess we can expect them to follow the major OpenWRT releases... bruno John On 21/07/2014 15:20, Bruno Randolf wrote: On 07/21/2014 12:28 PM, Bruno Randolf wrote: It would be possible to create a special image for upgrade from AA, something like openwrt-au1000-au1500-jffs2-128k-sysupgrade-from-12.09.bin, but I think it's simpler to just add a symlink to the tar.gz in all cases, The symlink approach does not work, as dd does not recognize the symlink and the rootfs is broken afterwards. So IMHO the best solution is to create a special sysupgrade image for upgrade from 12.09, like openwrt-au1000-au1500-jffs2-128k-sysupgrade-from-12.09.bin... diff --git a/target/linux/au1000/image/Makefile b/target/linux/au1000/image/Makefile index 63c0b03..56f613b 100644 --- a/target/linux/au1000/image/Makefile +++ b/target/linux/au1000/image/Makefile @@ -65,6 +65,10 @@ define Image/Build $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(1).fs $(TMP_DIR)/$(IMG_PREFIX)-root.fs tar -C $(BIN_DIR) -cvzf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-sysupgrade.bin \ $(IMG_PREFIX)-vmlinux.bin -C $(TMP_DIR) $(IMG_PREFIX)-root.fs + # backwards compatible image for upgrade from Attitude Adjustment (12.09) + $(CP) $(BIN_DIR)/$(IMG_PREFIX)-$(1).fs $(TMP_DIR)/$(IMG_PREFIX)-jffs2-128k.fs + tar -C $(BIN_DIR) -cvzf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-sysupgrade-from-12.09.bin \ + $(IMG_PREFIX)-vmlinux.bin -C $(TMP_DIR) $(IMG_PREFIX)-jffs2-128k.fs ifeq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y) $(call Image/Build/Initramfs) endif bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uClibc-ng
Hi Sedat, Sedat Dilek wrote, On Sun, Jul 20, 2014 at 9:13 PM, Waldemar Brodkorb w...@uclibc-ng.org wrote: Hello Embedded Linux Hackers, it seems there is no plan to release a new uClibc version. The current maintainer does not response on any public or private mails about a plan to do a needed release. Therefore most of you carrying a lot of patches against uClibc 0.9.33.2 to make it work in your project. A really ugly situation. I have seen some patches got in uClibc upstream some weeks ago (- inactivity). I didn't go so far to say uClibc is dead, it is just totally unclear when the next release is planned. But anyway, a 1st try... Look at OpenSSL and LibreSSL... Might be we see some competition or rebirth starting here, too? Dunno, time will show. My POV (from my experiences) is most embedded projects are not really interested in upstream work or keep their own patches (this seems to be easier). An example: Recently, I pointed to [0], but the maintainer of the project did not give any feedback to Bernd (requested a simple S-o-b). What I want to say it is not only a problem of the uClibc maintainer :-). I think most embedded projects try to push their local patches to upstream. At least buildroot does it a lot and I try to do it if time permits. In your example the uClibc maintainer could also just add the patch and mention where he has got it from. Or should the known bug should just be ignored, because of a missing S-o-b? From my experiences successful projects do regular releases (6 months or a year). What are your plans? A good mantra: Release early, release often. I have no plans doing regular releases every static time period. Just if it make sense. To get out of this situation I started a spin-off called uClibc-ng. The website for the project is here: http://www.uclibc-ng.org Beta 3 is tagged and downloadable via http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz Do you plan a browsable Git website, where someone can look at the source via webbrowser? Trac has it included: http://www.uclibc-ng.org/browser/uClibc-ng Or: http://www.openadk.org/cgi-bin/gitweb.cgi?p=uClibc-ng.git;a=summary OK, you have now an infrastructure... Do you have people (developers, users) behind you :-)? No. Just me. I am using it for my OpenADK project. I published the stuff so others might benefit from it. Some buildroot and OpenWrt devs were interested. If you want a 1.0 in the near future please test and report back any issues. You can use the bug tracker, the mailing list or dicussion forum to report back. To prevent spam you need to be subscribed or registered. I have added most of the patches from your projects on top of uClibc master. Did you look also at the patches [1] from the Freetz project? Yes. I wanted to inform the freetz project, but I didn't find a mailinglist or the mail adresses of the main contributors. Most of the patches are either backports from git master or from OpenWrt. I hope the rest might get contributed by the freetz people with some meta-information, what kind of problem is fixed by a patch. best regards Waldemar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade to Barrier Breaker on au1000 (MTX-1)
On 21/07/2014 19:27, Bruno Randolf wrote: On 07/21/2014 02:22 PM, John Crispin wrote: i will merge a patch post the rc2 fork that will generate old and new images int he release branch while not doing so in the dev trunk. i really dont want any workarounds in trunk how about that ? Sounds OK to me. Anyhow there are not so many au1000 users out there and I guess we can expect them to follow the major OpenWRT releases... bruno ok, so be it ... i will cook up a patch ... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uClibc-ng
Hello, (adding uclibc and Bernhard) 2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb w...@uclibc-ng.org: Hello Embedded Linux Hackers, it seems there is no plan to release a new uClibc version. The current maintainer does not response on any public or private mails about a plan to do a needed release. Therefore most of you carrying a lot of patches against uClibc 0.9.33.2 to make it work in your project. A really ugly situation. Although I do welcome your action, and stepping in to offer a solution to this, I feel like forking might have the potential of making this situation worse, including, but not limited to: - creating confusion between uclibc and uclibc-ng - pissing off Bernhard - duplicating existing infrastructure instead of gaining access to it - what if you end up in the same situation as uClibc, we all have busy lives? Thomas and I talked to Khem Raj about this uClibc situation during ELC back in June, and Khem offered some help to see if we could: - make Bernhard aware of the lack of release situation - use his uclibc.org access to facilitate a 0.9.34? release To get out of this situation I started a spin-off called uClibc-ng. The website for the project is here: http://www.uclibc-ng.org Beta 3 is tagged and downloadable via http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz If you want a 1.0 in the near future please test and report back any issues. You can use the bug tracker, the mailing list or dicussion forum to report back. To prevent spam you need to be subscribed or registered. I have added most of the patches from your projects on top of uClibc master. Thanks Waldemar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
hi, i pushed a patch in the hope that it will work. please test current trunk and tell if the problem is solved. John On 20/07/2014 17:56, Paul Blazejowski wrote: Hi, sorry your email got lost somehow on my end... And the machine hosting mailing list is down at the moment it seems. here is the info: root@router:~# cat /tmp/sysinfo/* wndr4300 NETGEAR WNDR3700v4/WNDR4300 thanks, -paul On Sat, 2014-07-19 at 14:52 -0400, Paul Blazejowski wrote: John, any update on this issue? i strongly believe that the hard-coded wndr4300 string somewhere in the source is the culprit of the problem since the wndr3700v4 board_detection is identified as wndr4300 thus the sysupgrade works for 4300 but not for 3700v4. Regards, -paul On Tue, 2014-06-24 at 23:15 +0200, John Crispin wrote: On 24/06/2014 22:43, Paul Blazejowski wrote: i get The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. from web interface. this is what i have: -rw-r--r-- 1 diffie diffie 8919040 2014-06-24 15:58 bin/ar71xx/openwrt-ar71xx-nand-wndr3700v4-squashfs-sysupgrade.tar should i push it from shell using sysupgrade script? it will work from shell, i will look into why it fails via webui. thanks! On Tue, 2014-06-24 at 22:32 +0200, John Crispin wrote: On 24/06/2014 22:25, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... i tested 4300 and it works. you need to use the *-ubi-sysupgrade.tar file. Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there 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 ___ 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] [PATCH] ar71xx: Fix GL.iNet WLAN LED
LED script expects WLAN LED to be gl-connect:red:wlan.
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
---
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
index ef1b54f..0713f14 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-inet.c
@@ -41,7 +41,7 @@ static struct flash_platform_data gl_inet_flash_data = {
static struct gpio_led gl_inet_leds_gpio[] __initdata = {
{
- .name = gl-connect:red:wireless,
+ .name = gl-connect:red:wlan,
.gpio = GL_INET_GPIO_LED_WLAN,
.active_low = 0,
},
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uClibc-ng
2014-07-21 11:42 GMT-07:00 Thomas Petazzoni thomas.petazz...@free-electrons.com: Dear Florian Fainelli, On Mon, 21 Jul 2014 11:23:46 -0700, Florian Fainelli wrote: 2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb w...@uclibc-ng.org: Hello Embedded Linux Hackers, it seems there is no plan to release a new uClibc version. The current maintainer does not response on any public or private mails about a plan to do a needed release. Therefore most of you carrying a lot of patches against uClibc 0.9.33.2 to make it work in your project. A really ugly situation. Although I do welcome your action, and stepping in to offer a solution to this, I feel like forking might have the potential of making this situation worse, including, but not limited to: - creating confusion between uclibc and uclibc-ng - pissing off Bernhard - duplicating existing infrastructure instead of gaining access to it - what if you end up in the same situation as uClibc, we all have busy lives? Thomas and I talked to Khem Raj about this uClibc situation during ELC back in June, and Khem offered some help to see if we could: - make Bernhard aware of the lack of release situation - use his uclibc.org access to facilitate a 0.9.34? release ELC was end of April, early May, and Khem told me he would act with one month. I've pinged him several times, and nothing happened. He might have been too afraid to piss off Bernhard. On my side, I fully support Waldemar's fork. The last uClibc release is more than 2 years old, and Bernhard has never been answering to *any* of the e-mails asking to do a release, sent since September 2013 or so. At this point, I think there is absolutely no hope to see any action being done by the existing uClibc community in terms of doing stable releases, and this case, the lever that open-source licenses provide is simple: fork. That's what Waldemar has done, and it's good. To speak my mind, I think uClibc has no future in the next 2 or 3 years, musl is a much more active project, with multiple embedded projects starting to use it, on the other end, (e)glibc has remedied its own problems and its useful again. No MMU architectures are becoming less and less popular, and the cost for larger flash storage mediums keeps decreasing, so all these key selling features (noMMU support and reduced memory footprint) that uClibc has will soon no longer be any useful to it. Bottom line is, I believe uClibc is a (relatively speaking) dead project already, forking it might be useful to keep the existing user base alive, but I expect all of them to transition to something active and maintained, whether that's glibc or musl. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uClibc-ng
Hi Florian, Florian Fainelli wrote, Hello, (adding uclibc and Bernhard) 2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb w...@uclibc-ng.org: Hello Embedded Linux Hackers, it seems there is no plan to release a new uClibc version. The current maintainer does not response on any public or private mails about a plan to do a needed release. Therefore most of you carrying a lot of patches against uClibc 0.9.33.2 to make it work in your project. A really ugly situation. Although I do welcome your action, and stepping in to offer a solution to this, I feel like forking might have the potential of making this situation worse, including, but not limited to: - creating confusion between uclibc and uclibc-ng What kind of confusion. uClibc-ng frontpage clearly states it is a spin-off of uClibc. - pissing off Bernhard May be I am already pissed off by him? In the past I send a patch for mips64 n64 with no answer. After a ping a month later it got applied. A bug report about broken sparc support never got a response. Public mails of the buildroot project missing a release got ignored. A private mail from me to Eric and Bernhard, response from Eric that he is no longer involved, no answer from Bernhard. So the selective answers of Bernhard are a problem, at least for me. - duplicating existing infrastructure instead of gaining access to it I asked Bernhard if he wants to give up maintainership. - what if you end up in the same situation as uClibc, we all have busy lives? So what is the situation of uClibc? The problem is lack of communication. I would be fine if Bernhard would answer any mails regarding non-technical issues with uClibc. A short mail I am busy, no release this year. would be at least a fair statement. Or I am very busy, having a new job, can someone make a release? Thomas and I talked to Khem Raj about this uClibc situation during ELC back in June, and Khem offered some help to see if we could: - make Bernhard aware of the lack of release situation - use his uclibc.org access to facilitate a 0.9.34? release Nothing happened. Should I whine another year on the mailinglist about a new release? As an old OpenBSD user I am following: Shutup and hack! best regards Waldemar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uClibc-ng
Hi Florian, Florian Fainelli wrote, To speak my mind, I think uClibc has no future in the next 2 or 3 years, musl is a much more active project, with multiple embedded projects starting to use it, on the other end, (e)glibc has remedied its own problems and its useful again. I am on your site here. But the 2-3 years must be become such a bad time for embedded users? We already have separate repositories for ARC and NPTL support and for Xtensa and NPTL. We have different projects all using different patch sets on top of 0.9.33.x. Buildroot, OpenWrt, OpenEmbedded, Freetz, Bering-Uclibc, OpenADK, Aboriginal (musl switch is in work). I do not see such a bad split-off in musl. Why? Because musl have a responsive and active maintainer. Bottom line is, I believe uClibc is a (relatively speaking) dead project already, forking it might be useful to keep the existing user base alive, but I expect all of them to transition to something active and maintained, whether that's glibc or musl. Sure, and that is totally okay for me. I just wanna make the existing userbase happy for the time, they can not switch to musl or glibc. Why not make the transition smooth? best regards Waldemar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3 1/2] firmware-utils: add new tool for fixing headers on ZyXEL devices (brcm63xx)
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
---
v3: code cleanup.
v2: Fix zyxbcm.c indentation.
diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index 64eccdd..d5cfdaa 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -49,6 +49,7 @@ define Host/Compile
$(call cc,mkchkimg)
$(call cc,mkzcfw cyg_crc32)
$(call cc,spw303v)
+ $(call cc,zyxbcm)
$(call cc,trx2edips)
$(call cc,xorimage)
$(call cc,buffalo-enc buffalo-lib, -Wall)
diff --git a/tools/firmware-utils/src/zyxbcm.c
b/tools/firmware-utils/src/zyxbcm.c
new file mode 100644
index 000..cfd00d3
--- /dev/null
+++ b/tools/firmware-utils/src/zyxbcm.c
@@ -0,0 +1,259 @@
+/*
+ * zyxbcm.c - based on Jonas Gorski's spw303v.c
+ *
+ * Copyright (C) 2014 Álvaro Fernández Rojas nolt...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include stdint.h
+#include time.h
+#include unistd.h
+#include sys/stat.h
+
+#define TAGVER_LEN 4 /* Length of Tag Version */
+#define SIG1_LEN 20/* Company Signature 1 Length */
+#define SIG2_LEN 14/* Company Signature 2 Lenght */
+#define BOARDID_LEN 16 /* Length of BoardId */
+#define ENDIANFLAG_LEN 2 /* Endian Flag Length */
+#define CHIPID_LEN 6 /* Chip Id Length */
+#define IMAGE_LEN 10 /* Length of Length Field */
+#define ADDRESS_LEN 12 /* Length of Address field */
+#define DUALFLAG_LEN 2 /* Dual Image flag Length */
+#define INACTIVEFLAG_LEN 2 /* Inactie Flag Length */
+#define RSASIG_LEN 20 /* Length of RSA Signature in tag */
+#define TAGINFO1_LEN 30/* Length of vendor information
field1 in tag */
+#define ZYX_TAGINFO1_LEN 20/* Length of vendor information field1
in tag */
+#define FLASHLAYOUTVER_LEN 4 /* Length of Flash Layout Version
String tag */
+#define TAGINFO2_LEN 16/* Length of vendor information
field2 in tag */
+#define CRC_LEN 4 /* Length of CRC in bytes */
+
+#define IMAGETAG_CRC_START 0x
+
+struct bcm_tag {
+ char tagVersion[TAGVER_LEN];// 0-3: Version of the
image tag
+ char sig_1[SIG1_LEN]; // 4-23: Company Line 1
+ char sig_2[SIG2_LEN]; // 24-37: Company Line 2
+ char chipid[CHIPID_LEN];// 38-43: Chip this
image is for
+ char boardid[BOARDID_LEN]; // 44-59: Board name
+ char big_endian[ENDIANFLAG_LEN];// 60-61: Map
endianness -- 1 BE 0 LE
+ char totalLength[IMAGE_LEN];// 62-71: Total length
of image
+ char cfeAddress[ADDRESS_LEN]; // 72-83: Address in
memory of CFE
+ char cfeLength[IMAGE_LEN]; // 84-93: Size of CFE
+ char flashImageStart[ADDRESS_LEN]; // 94-105: Address in
memory of image start (kernel for OpenWRT, rootfs for stock firmware)
+ char flashRootLength[IMAGE_LEN];// 106-115: Size of
rootfs for flashing
+ char kernelAddress[ADDRESS_LEN];// 116-127: Address in
memory of kernel
+ char kernelLength[IMAGE_LEN]; // 128-137: Size of
kernel
+ char dualImage[DUALFLAG_LEN]; // 138-139: Unused at
present
+ char inactiveFlag[INACTIVEFLAG_LEN];// 140-141: Unused at
present
+ char rsa_signature[RSASIG_LEN]; // 142-161: RSA
Signature (unused at present; some vendors may use this)
+ char information1[TAGINFO1_LEN];// 162-191: Compilation
and related information (not generated/used by OpenWRT)
+ char flashLayoutVer[FLASHLAYOUTVER_LEN];// 192-195: Version
flash layout
+ char fskernelCRC[CRC_LEN]; // 196-199:
kernel+rootfs CRC32
+ char information2[TAGINFO2_LEN];// 200-215: Unused at
present except Alice Gate where is is information
+ char imageCRC[CRC_LEN];
[OpenWrt-Devel] [project/ucwmp.git][PATCH V3] session: check for uclient_connect return value
uclient_connect may return an error and calling uclient_write will cause
a crash
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V3: Correctly use uloop_end
---
session/main.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/session/main.c b/session/main.c
index 147c949..bf20904 100644
--- a/session/main.c
+++ b/session/main.c
@@ -139,9 +139,17 @@ static void cwmp_dump_message(const char *msg, const char
*data)
static void __cwmp_send_request(struct uloop_timeout *t)
{
int len = 0;
+ int err;
+
cwmp_dump_message(Send CPE data, cur_request);
- uclient_connect(uc);
+ err = uclient_connect(uc);
+ if (err) {
+ fprintf(stderr, Failed to connect to the server: %d\n, err);
+ uloop_end();
+ return;
+ }
+
uclient_http_set_request_type(uc, POST);
cwmp_add_cookies(uc);
--
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:grub2: fix build error on linux missing libzfs
configure enables libzfs support on default. This will break the build, on systems without libzfs. Signed-off-by: Hans Ulli Kroll ulli.kr...@googlemail.com --- package/boot/grub2/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/package/boot/grub2/Makefile b/package/boot/grub2/Makefile index 83edfc6..64a3058 100644 --- a/package/boot/grub2/Makefile +++ b/package/boot/grub2/Makefile @@ -48,12 +48,14 @@ CONFIGURE_ARGS += \ --disable-werror \ --disable-nls \ --disable-device-mapper \ + --disable-libzfs \ --disable-grub-mkfont HOST_CONFIGURE_ARGS += \ --target=$(REAL_GNU_TARGET_NAME) \ --sbindir=$(STAGING_DIR_HOST)/bin \ --disable-werror \ + --disable-libzfs \ --disable-nls HOST_MAKE_FLAGS += \ -- 1.9.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Hi John, strange i did not receive your email, yet others from ml show up in my inbox just fine...(case of forgotten cc: or reply to all?) anyways ... just flashed the factory image i've built from r41792 and the changes you've made in r41788 by spitting the 2 routers work just fine for me. The router now correctly identifies as wndr3700v4 as reported in LuCI and kernel dmesg as well as in sysinfo: root@router:/tmp# cat sysinfo/* wndr3700v4 NETGEAR WNDR3700v4 As for sysupgrade, it shows the checksum now and flashes OK. It is nice to just upload the image into web interface and flash away instead of cables,pins and other gadgets to get the firmware loaded ... I thank you for your help in fixing this issue. case closed ;-) Best Regards, -paul hi, i pushed a patch in the hope that it will work. please test current trunk and tell if the problem is solved. On Sun, 2014-07-20 at 11:56 -0400, Paul Blazejowski wrote: Hi, sorry your email got lost somehow on my end... And the machine hosting mailing list is down at the moment it seems. here is the info: root@router:~# cat /tmp/sysinfo/* wndr4300 NETGEAR WNDR3700v4/WNDR4300 thanks, -paul On Sat, 2014-07-19 at 14:52 -0400, Paul Blazejowski wrote: John, any update on this issue? i strongly believe that the hard-coded wndr4300 string somewhere in the source is the culprit of the problem since the wndr3700v4 board_detection is identified as wndr4300 thus the sysupgrade works for 4300 but not for 3700v4. Regards, -paul On Tue, 2014-06-24 at 23:15 +0200, John Crispin wrote: On 24/06/2014 22:43, Paul Blazejowski wrote: i get The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. from web interface. this is what i have: -rw-r--r-- 1 diffie diffie 8919040 2014-06-24 15:58 bin/ar71xx/openwrt-ar71xx-nand-wndr3700v4-squashfs-sysupgrade.tar should i push it from shell using sysupgrade script? it will work from shell, i will look into why it fails via webui. thanks! On Tue, 2014-06-24 at 22:32 +0200, John Crispin wrote: On 24/06/2014 22:25, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... i tested 4300 and it works. you need to use the *-ubi-sysupgrade.tar file. Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
