[OpenWrt-Devel] syn_flood v/s synflood_protect in firewall default config

2016-03-30 Thread Naresh Kumar Mehta
All,

 

>From https://wiki.openwrt.org/doc/uci/firewall, syn_flood is obsoleted by
synflood_protect  but I still see syn_flood in
https://dev.openwrt.org/browser/trunk/package/network/config/firewall/files/
firewall.config. Does it mean we missed to update default value in
firewall.config or documentation is going faster than code.

 

Thanks,

Naresh

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] OpenWRT ppc44x target & the APM821XX SoC

2016-03-30 Thread Chris Blake
Hello everyone,

Quick Question about the ppc44x target. I am currently working on
porting over a PowerPC Device that uses the APM821XX SoC (464-based)
but the closest current target would be ppc44x, which seems to be a
bit outdated and lacks support for some system level integration
(LED's, sysupgrade scripts, etc.). I was able to get OpenWRT up and
running by creating a new device target for this SoC, but I was
curious on the best way to get this merged upstream.

The device in Question is a Cisco Meraki MR24, which has a APM82181
800Mhz SoC, 128MB DDR2 RAM, and 2x Atheros PCIe wireless cards. The
current working code can be found at
https://github.com/riptidewave93/Openwrt-MR24 but I was curious on
which of the following is the best way to move forward:

1. RFC the current code (new device target for this SoC) for review.
2. Create a new apm821xx subtarget for the ppc44x target, and RFC for review.
3. Other ideas?

I am also aware of another developer working on porting over another
device that uses this SoC, so it would be nice to know which path of
action is recommended as other PPC targets (ex, mpc85xx) have been
branched out in the past.

Thank you for your time.

Regards,
Chris Blake
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] [ramips] Adjust image size limit for the D-Link DIR-860L B1

2016-03-30 Thread Daniel Engberg
Currently the maximum image size defaults to 8Mbyte even though this model has 
16Mbyte of flash memory.

Tested and works on my device.

Signed-off-by: Daniel Engberg 

---

diff --git a/target/linux/ramips/image/Makefile 
b/target/linux/ramips/image/Makefile
index 0cfb8fb..2590e2b 100644
--- a/target/linux/ramips/image/Makefile
+++ b/target/linux/ramips/image/Makefile
@@ -1085,6 +1085,7 @@ define Device/dir-860l-b1
   DTS := DIR-860L-B1
   IMAGES += factory.bin
   KERNEL := kernel-bin | patch-dtb | relocate-kernel | lzma | uImage lzma
+  IMAGE_SIZE := $(ralink_default_fw_size_16M)
   IMAGE/sysupgrade.bin := \
append-kernel | pad-offset 65536 64 | append-rootfs | \
seama -m "dev=/dev/mtdblock/2" -m "type=firmware" | \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] /proc//stat

2016-03-30 Thread W. Michael Petullo
> According to the PROC(5) manpage, field five of /proc//stat should
> be the GID of the process with PID . Yet I find the following for
> (e.g.) Postfix's pickup process:
> 
> 5657 (pickup) S 1771 1771 1771 0 -1 4219136 170 0 0 0 0 0 0 0 20 0 1 0 
> 3513070 24834048 524 18446744073709551615 4194304 4446388 140727413994400 
> 140727413992112 139626969169172 0 0 16781312 8192 0 0 0 17 0 0 0 0 0 0 
> 6543544 6546778 24240128 140727414001539 140727414001560 140727414001560 
> 140727414001628 0
> 
> Here the fifth field is 1771. 1771 is the parent process ID, and is
> definitely not a valid GID on the computer (not in /etc/group). Am I
> going crazy, or is there something wrong in the kernel?
> 
> It does not seem possible to get a GID out of Busybox's ps. Is there
> another way to identify the GID of a running process?

Bah.

The man page means "The process-group ID of the process", not "The
process group-ID of the process". What I need is in /proc//status.

Sorry for the noise.

-- 
Mike

:wq
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] /proc//stat

2016-03-30 Thread W. Michael Petullo
According to the PROC(5) manpage, field five of /proc//stat should
be the GID of the process with PID . Yet I find the following for
(e.g.) Postfix's pickup process:

5657 (pickup) S 1771 1771 1771 0 -1 4219136 170 0 0 0 0 0 0 0 20 0 1 0 3513070 
24834048 524 18446744073709551615 4194304 4446388 140727413994400 
140727413992112 139626969169172 0 0 16781312 8192 0 0 0 17 0 0 0 0 0 0 6543544 
6546778 24240128 140727414001539 140727414001560 140727414001560 
140727414001628 0

Here the fifth field is 1771. 1771 is the parent process ID, and is
definitely not a valid GID on the computer (not in /etc/group). Am I
going crazy, or is there something wrong in the kernel?

It does not seem possible to get a GID out of Busybox's ps. Is there
another way to identify the GID of a running process?

-- 
Mike

:wq
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] stdout and putchar() behavior in musl

2016-03-30 Thread Alexander Dahl
Hei hei,

Am 2016-03-30 13:07, schrieb Ram Chandra Jangir:
> When I use uClibc/gcc, I can see writing c+1 from putchar() happening
> immediately. But when I use musl, character(c+1) gets printed on console
> only if I exit from the program by entering 'e'. 

Maybe it's (line) buffered. What happens if you enter newlines?

Greets
Alex

-- 
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6 ***
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] stdout and putchar() behavior in musl

2016-03-30 Thread Arjen de Korte

Citeren Ram Chandra Jangir :


Hi,

Did anyone observed stdout and putchar() behavior differences between musl &
uClibc?

I have below code snippet :

int main(void){
int c;
while((c=getchar())!= 'e') {
putchar(c+1);
}
return 0;
}

When I use uClibc/gcc, I can see writing c+1 from putchar() happening
immediately. But when I use musl, character(c+1) gets printed on console
only if I exit from the program by entering 'e'.
I guess printing character using putchar family on stdio is having bug(or
different implementation) in musl. Has anybody faced this issue? Any
workaround?


Apparently in uClibc stdout is unbuffered and in musl it is buffered.  
Either is allowed in the C-standard (it is  not specified) so this is  
not a bug. If you want each character to be output immediately, you  
probably need to add flush(stdout).

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] stdout and putchar() behavior in musl

2016-03-30 Thread Ram Chandra Jangir
Hi,

Did anyone observed stdout and putchar() behavior differences between musl &
uClibc?

I have below code snippet :

int main(void){
int c;
while((c=getchar())!= 'e') {
putchar(c+1);
}
return 0;
}

When I use uClibc/gcc, I can see writing c+1 from putchar() happening
immediately. But when I use musl, character(c+1) gets printed on console
only if I exit from the program by entering 'e'. 
I guess printing character using putchar family on stdio is having bug(or
different implementation) in musl. Has anybody faced this issue? Any
workaround?


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Chaos Calmer 15.05.1 brcm63xx/generic missing packages

2016-03-30 Thread Álvaro Fernández Rojas
Hello John,

I’ve just realized that luci, management, routing and telephony packages are 
missing for brcm63xx/generic when I was trying to build a firmware with image 
builder.
https://downloads.openwrt.org/chaos_calmer/15.05.1/brcm63xx/generic/packages/luci/
 

https://downloads.openwrt.org/chaos_calmer/15.05.1/brcm63xx/generic/packages/management/
 

https://downloads.openwrt.org/chaos_calmer/15.05.1/brcm63xx/generic/packages/routing/
 

https://downloads.openwrt.org/chaos_calmer/15.05.1/brcm63xx/generic/packages/telephony/
 


Any chance of fixing this for 15.05.1? :_(

Regards,
Álvaro.___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] opkg upgrade all

2016-03-30 Thread Michal Hrusecky
Daniel Dickinson -  3:18 30.03.16 wrote:
> On 16-03-30 02:48 AM, Michal Hrusecky wrote:
> >
> >Yep, I understand all those. My question was whether upgrade all is disabled
> >just because of this ideological stuff and in hope that users wouldn't find 
> >and
> >try one of the posts I linked or whether there is anything really broken.
> 
> It's *not* ideological, it's about preventing broken routers.  On most
> routers OpenWrt support, if you do upgrade all you *will* break your router
> because you will end up with a fatal out of space issue that results the
> requirement to reset to factory defaults.
> 
> This is because squashfs is *far* more compressed than jffs2 AND because
> with the limited flash on the vast majority of devices it is not at all
> possible upgrade all packages into the overlay jffs2 without causing the
> jffs2 to end up with 0 erase blocks free, which results in a situation where
> you can't even erase files to get back to a working state (try it if you
> don't believe me - dd if=/dev/zero of=/fill.bin and then try to get back to
> a working state).

And as I said I know that you *can* run out of disk space and effectively break
your OpenWRT installation. As you can do with your mentioned
'dd if=/dev/zero of=/fill.bin' or with
'opkg upgrade `opkg list-upgradable | sed 's|\ .*||'`'
You can also break your router in plenty of other ways. But dd is still in.  I
also know people are dumb and will do it, but they are also creative and can
use google so they will do it anyway (and when I google for opkg upgrade,
workarounds to get opkg upgrade all back is the 3rd to 8th link showed on the
results page).

So from the replies so far I guess the only reason for disabling it is the try
to prevent people from doing stupid stuff, nothing really broken, right?

> Regards,
> 
> Daniel
> 
> >
> >>Em qua, 30 de mar de 2016 02:30, Michal Hrusecky 
> >>escreveu:
> >>
> >>>Luiz Angelo Daros de Luca -  1:41 30.03.16 wrote:
> Michal,
> 
> Google is your friend ;-)
> >>>
> >>>He pretends he is, but didn't provided the answer I was looking for, just
> >>>plenty of workarounds I mentioned ;-)
> >>>
> But I'll easy your search
> https://wiki.openwrt.org/doc/techref/opkg
> 
> Check the upgrade description.
> >>>
> >>>Reread and the only thing that is mentioned there is general discourage to
> >>>do
> >>>upgrades and be careful what you are doing and that there are generally no
> >>>updates available apart from trunk and that opkg will not upgrade kernel.
> >>>No
> >>>technical problem and no specific issue with upgrade all.
> >>>
> Regards
> 
> Em ter, 29 de mar de 2016 às 04:45, Michal Hrusecky <
> >>>michal.hruse...@nic.cz>
> escreveu:
> 
> >Hi,
> >
> >there is a patch in OpenWRT that disables option to upgrade all
> >>>packages
> >and
> >allows upgrading only specified packages which leads to plenty of
> >>>answers
> >online how to do that[1][2][3][...] Does anybody remembers the reason
> >>>for
> >disabling it? The only thing I can think of is discouraging people from
> >doing
> >upgrades and encourage them to reflash new squashfs image as they
> >>>might not
> >have enough free space. But as you can see, people will try and do it
> >anyway so
> >it might be a good idea to let the command there as it will be probably
> >safer
> >with integrated command than with random scripts on internet. Or is
> >>>there
> >some
> >other reason and some real problem?
> >
> >[1] https://sandalov.org/blog/1777/
> >[2]
> >
> >>>https://www.codeden.net/2015/05/upgrade-all-openwrt-packages-with-a-single-line-command/
> >[3] http://blog.vanutsteen.nl/2014/01/12/openwrt-upgrade-all-packages/
> >___
> >openwrt-devel mailing list
> >openwrt-devel@lists.openwrt.org
> >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> --
> 
> Luiz Angelo Daros de Luca
> luizl...@gmail.com
> >>>
> >>--
> >>
> >>Luiz Angelo Daros de Luca
> >>luizl...@gmail.com
> >___
> >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] The old days are gone; OpenWrt is a product now

2016-03-30 Thread Chris Green
On Wed, Mar 30, 2016 at 12:12:45AM -0400, Daniel Dickinson wrote:
[snip]
> 
> The project itself is in a transition state, and, at least from what see,
> has lost a lot of mindshare for a variety of reasons (I think part of just
> that geeks (except strange ones like us) just aren't as excited by working
> on routers as in days past, and hence is left to people who are willing to
> treat it like a job, or have the time and energy, and inclination to put in
> a job-like effort.
> 
I'm mostly a lurker on this list.  I bought a Mikrotik router a while
ago because I wanted a reasonably powerful (computer-wise) router that
I could run Linux on.

My experience wasn't entirely positive.  I did get openwrit installed
and running on the Mikrotik but it took a long time and involved quite
a lot of learning plus a patch (search back for RB2011).

I think you are right in saying that openwrt is caught between two
stools.  It's not 'solid' enough to be in the same world as most Linux
distributions.  You can't install it like you can Ubuntu or SuSe or
anything like that, there's almost bound to be more hassle than
'insert this CD/DVD and power up'.

On the other hand it's got too big and complex to really appeal to the
hardware bashing fraternity and anyway they've all gone off to
Rasperry Pi, Beaglobone Black, Arduino, etc.

Unless openwrt becomes the OS of choice for some mainstream routers
and can be updated and maintained regularly like 'ordinary' Linux I
think it will remain a niche interest.

-- 
Chris Green
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Git mirror with branches, tags and full history?

2016-03-30 Thread John Crispin


On 30/03/2016 09:43, Bruno Randolf wrote:
> On 03/30/2016 08:32 AM, John Crispin wrote:
>> i have just updated https://github.com/openwrt/openwrt
> 
> Thanks!
> 
> Now, if you could add a tag "v15.05.1" things would be perfect...
> 
> bruno

done
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Git mirror with branches, tags and full history?

2016-03-30 Thread Sedat Dilek
On Wed, Mar 30, 2016 at 9:43 AM, Bruno Randolf  wrote:
> On 03/30/2016 08:32 AM, John Crispin wrote:
>> i have just updated https://github.com/openwrt/openwrt
>
> Thanks!
>
> Now, if you could add a tag "v15.05.1" things would be perfect...
>

Geil (German)!

Just curious, is the GitHub-OpenWrt-Mirror faster in things of checking-out?

- Sedat -
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Git mirror with branches, tags and full history?

2016-03-30 Thread Bruno Randolf
On 03/30/2016 08:32 AM, John Crispin wrote:
> i have just updated https://github.com/openwrt/openwrt

Thanks!

Now, if you could add a tag "v15.05.1" things would be perfect...

bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 2/2] brcm2708: add brcmfmac43430-firmware-sdio for Rasberry Pi 3

2016-03-30 Thread Álvaro Fernández Rojas
Signed-off-by: Álvaro Fernández Rojas 
---
 target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk 
b/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
index a20e225..c39cf52 100644
--- a/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
+++ b/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
@@ -7,7 +7,7 @@
 
 define Profile/RaspberryPi_3
   NAME:=Raspberry Pi 3 Model B
-  PACKAGES:=kmod-brcmfmac wpad-mini
+  PACKAGES:=brcmfmac43430-firmware-sdio kmod-brcmfmac wpad-mini
 endef
 define Profile/RaspberryPi_3/Description
   Raspberry Pi 3 Model B
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 1/2] brcmfmac43430-firmware: add new package

2016-03-30 Thread Álvaro Fernández Rojas
This adds the firmware needed for the BCM43438 included in Raspberry Pi 3.

Signed-off-by: Álvaro Fernández Rojas 
---
 package/firmware/brcmfmac43430-firmware/Makefile | 61 
 1 file changed, 61 insertions(+)
 create mode 100644 package/firmware/brcmfmac43430-firmware/Makefile

diff --git a/package/firmware/brcmfmac43430-firmware/Makefile 
b/package/firmware/brcmfmac43430-firmware/Makefile
new file mode 100644
index 000..6e78e9d
--- /dev/null
+++ b/package/firmware/brcmfmac43430-firmware/Makefile
@@ -0,0 +1,61 @@
+# Copyright (C) 2016 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=brcmfmac43430-firmware-sdio
+PKG_RELEASE:=1
+
+include $(INCLUDE_DIR)/package.mk
+
+BRCMFMAC43430_SDIO_REV:=54bab3d6a6d43239c71d26464e6e10e5067ffea7
+BRCMFMAC43430_SDIO_URL:=https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/$(BRCMFMAC43430_SDIO_REV)/brcm80211/brcm/
+BRCMFMAC43430_SDIO_FILE:=brcmfmac43430-sdio-$(BRCMFMAC43430_SDIO_REV)
+
+define Download/brcmfmac43430_sdio_bin
+  FILE:=$(BRCMFMAC43430_SDIO_FILE).bin
+  URL:=$(BRCMFMAC43430_SDIO_URL)
+  URL_FILE:=brcmfmac43430-sdio.bin
+  MD5SUM:=4a410ab9a1eefe82e158d36df02b3589
+endef
+$(eval $(call Download,brcmfmac43430_sdio_bin))
+
+define Download/brcmfmac43430_sdio_txt
+  FILE:=$(BRCMFMAC43430_SDIO_FILE).txt
+  URL:=$(BRCMFMAC43430_SDIO_URL)
+  URL_FILE:=brcmfmac43430-sdio.txt
+  MD5SUM:=8c3cb6d8f0609b43f09d083b4006ec5a
+endef
+$(eval $(call Download,brcmfmac43430_sdio_txt))
+
+define Package/brcmfmac43430-firmware-sdio
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  TITLE:=Broadcom BCM43430 fullmac SDIO firmware
+  URL:=http://www.broadcom.com/
+endef
+
+define Package/brcmfmac43430-firmware-sdio/description
+   Broadcom BCM43430 fullmac SDIO firmware
+endef
+
+define Build/Prepare
+   rm -rf $(PKG_BUILD_DIR)
+   mkdir -p $(PKG_BUILD_DIR)
+   cp $(DL_DIR)/$(BRCMFMAC43430_SDIO_FILE).bin 
$(PKG_BUILD_DIR)/brcmfmac43430-sdio.bin
+   cp $(DL_DIR)/$(BRCMFMAC43430_SDIO_FILE).txt 
$(PKG_BUILD_DIR)/brcmfmac43430-sdio.txt
+endef
+
+define Build/Compile
+   true
+endef
+
+define Package/brcmfmac43430-firmware-sdio/install
+   $(INSTALL_DIR) $(1)/lib/firmware/brcm/
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/brcmfmac43430-sdio.bin 
$(1)/lib/firmware/brcm/
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/brcmfmac43430-sdio.txt 
$(1)/lib/firmware/brcm/
+endef
+
+$(eval $(call BuildPackage,brcmfmac43430-firmware-sdio))
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Git mirror with branches, tags and full history?

2016-03-30 Thread John Crispin


On 29/03/2016 11:06, John Crispin wrote:
> 
> 
> On 29/03/2016 10:07, Bruno Randolf wrote:
>> Hello!
>>
>> What happened to https://github.com/openwrt/openwrt/?
>>
>> Last commit on 'master' is from Feb 23, on 'chaos_calmer' from Feb 19...
>>
>> It's a problem for me because I am using this as my main git upstream
>> and I'd have to rebase (again) to use
>> git://git.openwrt.org/15.05/openwrt.git or
>> git://git.openwrt.org/openwrt.git.
>>
>> As noted before the benefit of having one git repo with all branches is
>> easier rebasing and merging new releases. I would appreciate if it came
>> back.
>>
>> Thanks,
>> bruno
> 
> i was just passed me the files required to sync github. will need a
> couple of days to set it up. stay tuned 


i have just updated https://github.com/openwrt/openwrt
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] opkg upgrade all

2016-03-30 Thread Daniel Dickinson

On 16-03-30 02:48 AM, Michal Hrusecky wrote:


Yep, I understand all those. My question was whether upgrade all is disabled
just because of this ideological stuff and in hope that users wouldn't find and
try one of the posts I linked or whether there is anything really broken.


It's *not* ideological, it's about preventing broken routers.  On most 
routers OpenWrt support, if you do upgrade all you *will* break your 
router because you will end up with a fatal out of space issue that 
results the requirement to reset to factory defaults.


This is because squashfs is *far* more compressed than jffs2 AND because 
with the limited flash on the vast majority of devices it is not at all 
possible upgrade all packages into the overlay jffs2 without causing the 
jffs2 to end up with 0 erase blocks free, which results in a situation 
where you can't even erase files to get back to a working state (try it 
if you don't believe me - dd if=/dev/zero of=/fill.bin and then try to 
get back to a working state).


Regards,

Daniel




Em qua, 30 de mar de 2016 02:30, Michal Hrusecky 
escreveu:


Luiz Angelo Daros de Luca -  1:41 30.03.16 wrote:

Michal,

Google is your friend ;-)


He pretends he is, but didn't provided the answer I was looking for, just
plenty of workarounds I mentioned ;-)


But I'll easy your search
https://wiki.openwrt.org/doc/techref/opkg

Check the upgrade description.


Reread and the only thing that is mentioned there is general discourage to
do
upgrades and be careful what you are doing and that there are generally no
updates available apart from trunk and that opkg will not upgrade kernel.
No
technical problem and no specific issue with upgrade all.


Regards

Em ter, 29 de mar de 2016 às 04:45, Michal Hrusecky <

michal.hruse...@nic.cz>

escreveu:


Hi,

there is a patch in OpenWRT that disables option to upgrade all

packages

and
allows upgrading only specified packages which leads to plenty of

answers

online how to do that[1][2][3][...] Does anybody remembers the reason

for

disabling it? The only thing I can think of is discouraging people from
doing
upgrades and encourage them to reflash new squashfs image as they

might not

have enough free space. But as you can see, people will try and do it
anyway so
it might be a good idea to let the command there as it will be probably
safer
with integrated command than with random scripts on internet. Or is

there

some
other reason and some real problem?

[1] https://sandalov.org/blog/1777/
[2]


https://www.codeden.net/2015/05/upgrade-all-openwrt-packages-with-a-single-line-command/

[3] http://blog.vanutsteen.nl/2014/01/12/openwrt-upgrade-all-packages/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


--

Luiz Angelo Daros de Luca
luizl...@gmail.com



--

Luiz Angelo Daros de Luca
luizl...@gmail.com

___
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