Quick question.  How can you see the revision number in LEDE prior to compiling?

./scripts/getver.sh

Or

$ git describe

So while i got no response from anyone, i thought i would post my findings here for someone else who might run into the same problem.
So it seems that "Enable SYN-flood protection" which is enabled by default sometimes goes nuts and starts blocking the WOL packets coming from the the WAN. Now i've gone ahead and disabled that feature for now, which i know is opening up connection for actual DOS attacks that might occur on my router. But i saw no other fix now.

Does anyone have any better suggestions? Thanks

@alirz
Sorry, I don't have an answer for what you are seeing.
May I suggest that you try a newer version .
The darkside has came a long way since that version and trunk has been stable.
Who knows? Maybe your issue will be gone.

Edit:4.4.22 builds fine with no mods and so far so good.

(Last edited by northbound on 25 Sep 2016, 00:52)

Thanks but I already updated to the latest build from today. In fact with the new build, my wake on wan didn't work at all unless I disabled SYN flooding protection.

@alirz
Sorry for a couple of stupid questions.
Did you save settings? When you flashed.
What trunk did you use?

Thanks northbound & Borrowmini

Both work

(Last edited by Phil-bkk on 25 Sep 2016, 04:07)

Questions are welcome all the time.
I just have too much configured to do a full factory flash, so I just sysupgraded keeping the settings.
It's CC trunk.

I don't know if this is affecting just wake on wan packets or the router could be blocking other type of traffic also such that others may not have noticed? Wake on wan is barely used by anyone from what I know.

I use WOL all the time.  But, my WOL traffic is not passing thru the firewall which I think is what you are doing.  If I understood you correctly, you are passing WOL outside to inside.  Am I wrong?

(Last edited by kirkgbr on 25 Sep 2016, 14:55)

You are right. I'm sending wol packets from the internet to inside my Lan. I think I will put some rules in the firewall to specifically allow incoming traffic on my wol ports, then enable the SYN flood protection to see if it still keeps working.
Now keep in mind I've been using this for years without any problem. Only until last year I started having problemsthat wol would stop working until I rebooted the router. And then as of yesterday with the new cc build, my wol doesn't work at all if syn flood protection is enabled.

(Last edited by alirz on 25 Sep 2016, 15:39)

A note to the security conscious doing their own owrt build. This note about the issue and openssl release 1.0.2i to address. I have not seen anything in the owrt github so you may have to patch up your build to use that release.

@alirz, Been a long time since I looked at WOW, but I thought all the recipes I saw required FW rule, some even had some C programs required to accomplish getting the broadcast packet through. But it has been a while.

Edit: Not sure how you are implementing things but... In a secure manner the package luci-app-fwknop / fwknop daemon may offer a way; they even have an Android client app. But does not offer the old port knockers flexibility of just configuring a WOL in the config file. You could just grab some code for a port listener in language flavour of choice and modify to implement a simple, but specific to device on LAN, maybe just table driven.

(Last edited by Villeneuve on 25 Sep 2016, 19:13)

@alirz Did you by chance build with debug messages set/selected for uhttpd?  I accidentally selected it a few weeks back and ended up with tons of the daemon.err messages for uhttpd in the logs.

As to the WoL, have you verified the WoL and firewall configs aren't missing a single quote or have a typo?  This would make sense if it works after saving and applying via LuCI, as anything done via LuCI rewrites the entire config file(s).

(Last edited by JW0914 on 26 Sep 2016, 14:40)

I did not choose anything for uhttpd logging. Not even sure where i would have selected the debug log. Anyways, logging is not my problem. Seems like my port forwarding stop working sometimes.

As for the WOL, my setup has been the same for 2 years.
I think im going to do factory reset on all settings and configure all over again.. what a pain and may not even fix the issue.

uhttpd debug would be under network -> web servers -> uhttpd - build with debug messages (or something to that effect) within menu config

• I accidentally selected it when I wasn't paying enough attention to enabling TLS support

(Last edited by JW0914 on 26 Sep 2016, 16:25)

Thanks, but that option is not checked for me.

Would someone mind giving me some tips on https://forum.openwrt.org/viewtopic.php?id=67757
Thanks

What is the max firmware image size, as well as as the sysupgrade tar, for the armada XP & 385 [as both have differing sizes for the kernel and rootfs partitions]? 

1. How does one go about determining how large the kernel portion of an image is, and conversely, how large the rootfs part of the image is?

2. Is my assumption correct that a firmware image is compressed, and if so, how does one determine the uncompressed [flashed] size of an image (prior to flashing)?

3. Is there a way to determine what packages/features are taking up the most space within an image

(Last edited by JW0914 on 27 Sep 2016, 19:03)

What type of NAND have 1900acx SLC or MLC?

I'm not sure but this command seems to give some hints.

dmesg |grep -i nand

@sera in your kernel 4.8 build, you use ubifs instead of jffs2 only or instead squashfs? SLC can survive 100M -1G writes, MLC 1-10k writes, so....
I'm still experiencing this errors after running router for one week

Mon Sep 26 02:59:52 2016] SQUASHFS error: Unable to read page, block de334a, size 18c64
[Mon Sep 26 02:59:52 2016] SQUASHFS error: Unable to read fragment cache entry [de334a]
[Mon Sep 26 02:59:52 2016] SQUASHFS error: Unable to read page, block de334a, size 18c64
[Mon Sep 26 02:59:53 2016] SQUASHFS error: xz decompression failed, data probably corrupt
[Mon Sep 26 02:59:53 2016] SQUASHFS error: squashfs_read_data failed to read block 0xde334a
[Mon Sep 26 02:59:53 2016] SQUASHFS error: Unable to read fragment cache entry [de334a]
[Mon Sep 26 02:59:53 2016] SQUASHFS error: Unable to read page, block de334a, size 18c64
[Mon Sep 26 02:59:56 2016] SQUASHFS error: Unable to read fragment cache entry [de334a]
[Mon Sep 26 02:59:56 2016] SQUASHFS error: Unable to read page, block de334a, size 18c64
[Mon Sep 26 03:00:10 2016] SQUASHFS error: xz decompression failed, data probably corrupt
[Mon Sep 26 03:00:10 2016] SQUASHFS error: squashfs_read_data failed to read block 0xde334a
[Mon Sep 26 03:00:10 2016] SQUASHFS error: Unable to read fragment cache entry [de334a]
[Mon Sep 26 03:00:10 2016] SQUASHFS error: Unable to read page, block de334a, size 18c64

@nitroshift some news about this newly rewritten flash driver?

(Last edited by gsustek on 27 Sep 2016, 18:58)

@gsustek

No one is using jffs2. All use squashfs with ubifs overlay, the exception are the ubifs only images that are available via my patch series. The errors you are seeing are with lede, right?

"master" support was handy while I started out with the series. Since "files" are gone and kernel patches are format-patches there is not much point in keeping it any longer. Instead "next" is now usable just like 4.7 or 4.8, meaning the sources will get fetched.

Also few of the patches are now in openwrt and so no longer part of the series. There was also a security update for openssl, so regardless what you used before the time for a new build is due.

Issue.
Who knows the purpose of chip serial SPI, what data it recorded?
[3.060112] m25p80 spi 0.0: mr25h256 (32 Kbytes)

openwrt build is failing right now, seems to be at compiling busybox, worked fine two days ago. Already tried cleaning directory etc..

make[5]: *** [editors/vi.o] Error 1
make[4]: *** [editors] Error 2
make[4]: Leaving directory `/media/ali/2a31be03-830e-4b99-ac3f-10a60ac8d2d0/openwrt/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.15_eabi/busybox-1.24.2'
make[3]: *** [/media/ali/2a31be03-830e-4b99-ac3f-10a60ac8d2d0/openwrt/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.15_eabi/busybox-1.24.2/.built] Error 2
make[3]: Leaving directory `/media/ali/2a31be03-830e-4b99-ac3f-10a60ac8d2d0/openwrt/openwrt/package/utils/busybox'
make[2]: *** [package/utils/busybox/compile] Error 2
make[2]: Leaving directory `/media/ali/2a31be03-830e-4b99-ac3f-10a60ac8d2d0/openwrt/openwrt'
make[1]: *** [/media/ali/2a31be03-830e-4b99-ac3f-10a60ac8d2d0/openwrt/openwrt/staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.15_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory `/media/ali/2a31be03-830e-4b99-ac3f-10a60ac8d2d0/openwrt/openwrt'
make: *** [world] Error 2

(Last edited by alirz on 27 Sep 2016, 23:01)