I have tried changing the DNS servers before and it did not help in my case.
I guess the mtr part was a suggestion on how to analyze the problem, not how to fix it.
I have tried changing the DNS servers before and it did not help in my case.
The problem with images on Instagram and other sites should be somewhere in the wireless bridging of the firmware, because I had the issue while using my EA6350v3 router as a simple access point in bridge mode. Another machine (a Linux server) was the DNS forwarder, firewall, DHCP server, NAT, connect to my ISP with PPPoE, etc. My Linksys was only working to bridge the wireless clients to the LAN network and even then the issue was present, however if I connected the client PCs to the Linksys using a cable, the images load fine.
I'm trying to resolve an issue with the boot counter code that was apparently modified for this device, without breaking this device.
If someone has some time, I could use two diagnostics on the
s_env partition, which I believe is mtd9.
mtdinfo /dev/mtd9 -u hexdump -C /dev/mtd9ro
The first prints general information about the partition, and is not intended to modify it in any way
The second I expect will print the boot-count records from the partition. On a different device, the output looks like
00000000 11 08 11 20 01 00 00 00 12 08 11 20 ff ff ff ff |... ....... ....| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000800 11 08 11 20 02 00 00 00 13 08 11 20 ff ff ff ff |... ....... ....| 00000810 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00001000 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00001010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * [...] 00017000 11 08 11 20 01 00 00 00 12 08 11 20 ff ff ff ff |... ....... ....| 00017010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00017800 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00017810 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00040000
If it's crazy long, the first several records and the last couple should be fine.
Post or PM is OK, as this output likely doesn't have general interest to most readers of the thread.
I have noticed that when I connect to Internet through the 4G modem connected to the router USB port (instead of the WAN port) Instagram works perfectly. But on the other hand that traffic goes through another ISP so I'm not sure if it brings me any closer to why this happens.
A chrome debug also showed that it uses different hostnames in the Instagram image URLs for that ISP.
What's the issue exactly?
I've been going through the commits for this device, comparing changes with other linksys devices and trying to clean up differences and remove some ambiguities. One thing I was wondering about was why
/etc/init.d/linksys_recovery needs to reset a boot count in both
s_env. Other devices only access
s_env. Any ideas?
s_env is mtd8, so there's this from my EA6350v3 w/snapshot:
# mtdinfo /dev/mtd8 -u mtd8 Name: s_env Type: nor Eraseblock size: 65536 bytes, 64.0 KiB Amount of eraseblocks: 2 (131072 bytes, 128.0 KiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:16 Bad blocks are allowed: false Device is writable: true Default UBI VID header offset: 64 Default UBI data offset: 128 Default UBI LEB size: 65408 bytes, 63.8 KiB Maximum UBI volumes count: 128
# hexdump -C /dev/mtd8ro 00000000 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00000010 11 08 11 20 01 00 00 00 12 08 11 20 ff ff ff ff |... ....... ....| 00000020 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00000030 11 08 11 20 01 00 00 00 12 08 11 20 ff ff ff ff |... ....... ....| 00000040 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00000050 11 08 11 20 01 00 00 00 12 08 11 20 ff ff ff ff |... ....... ....| 00000060 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00000070 11 08 11 20 01 00 00 00 12 08 11 20 ff ff ff ff |... ....... ....| 00000080 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00000090 11 08 11 20 01 00 00 00 12 08 11 20 ff ff ff ff |... ....... ....| ... 00000340 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00000350 11 08 11 20 01 00 00 00 12 08 11 20 ff ff ff ff |... ....... ....| 00000360 11 08 11 20 00 00 00 00 11 08 11 20 ff ff ff ff |... ....... ....| 00000370 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00020000
Let me know if you need anything else (maybe PM if it's big). Any links to the above record format too?
Thanks, yes, that was was I was hoping/expecting to see.
The boot loader writes a new "record" on each boot consisting of
11 08 11 20-- "magic number" (marker)
01 00 00 00-- boot count
12 08 11 20-- checksum
From what I can tell on my EA8300, if the boot count is 3, the boot loader rewrites the environment and sets the next boot count to 1. I haven't confirmed it, but this should be what "flips" the partition on a boot-loop situation.
On "successful" boot, the OS is responsible to write a "0" record so that the boot loader knows boot went well.
The record is not overwritten, but appended. This reduces flash wear and is perhaps also the reason that
boot_count from the environment is not used. (I've never seen anything but 0 in there and 3 in
boot_part_ready). When the partition is "full", it gets erased and starts over -- only the last-written record has significant value.
The "challenge" is that NAND flash typically has a minimum write size, 2048 bytes, for example. So on a NAND-based Linksys device, these boot-count records are 2048 bytes long. When the Linksys device(s) was ported to the IPQ40xx platform, someone noticed that it was writing 16-byte records, not the 1-byte record that the MTD parameters show, and hard-coded 16 in for the platform in general. As a result, the "pure NAND" EA8300 had some pretty strange boot behavior because the code to reset the boot count was silently failing.
I've since rewritten
- Actually log success and failure
- Auto-detect if the record size should be 16 or the MTD parameter (E6350v3 being the only exception I have found)
- Return a meaningful error value (and update init scripts to ignore it, so as not to stop boot)
I'll make sure it's clean and put in a PR/patch as it impacts more than just the EA8300. If you have a chance to check it, that would be great!
If you like to amuse yourself, here's what I run from /etc/profile to "see" this in action. Yes, my
s_env partition "rolls" one a week or so. Yes, it's an ugly script, but cut-and-paste for what was intended to be a diagnostic tool was the fastest as it evolved
root@OpenWrt:~# boot-info.sh rootfs: mtd13 boot_part=2 boot_count=0 89 bootcount entries. Last ten: 02 00 01 00 01 00 01 00 01 00
#!/bin/sh printf "rootfs: mtd%i\n" $( cat /sys/devices/virtual/ubi/ubi0/mtd_num ) fw_printenv boot_part fw_printenv boot_count printf "%i bootcount entries. Last ten: " $( hexdump -C /dev/mtd8ro | sed -nEe 's/^[0-9a-f]+00 11 08 11 20 ([0-9a-f][0-9a-f]).*$/\1/p' | wc -l ) hexdump -C /dev/mtd8ro | sed -nEe 's/^[0-9a-f]+00 11 08 11 20 ([0-9a-f][0-9a-f]).*$/\1/p' \ | tail -n 10 | tr '\n' ' ' printf "\n"
Thanks for the careful, detailed response around the boot count management. That's been helpful, and left me more puzzled about why
boot_count from the environment is also reset for EA6350v3. I'll need to make some tests for my cleanup PR...
I'll certainly keep an eye open for your PR/patch, and look into testing using your scripts too. Thanks!
Well, looks like my RFC / RFT ended up on patchwork -- https://patchwork.ozlabs.org/patch/1060597/
At least it hasn't gone down in flames yet!
Testing would be greatly appreciated!
- EA6350v3 (NOR boot)
Does this also apply to EA6350v3? I ask because this thread is for that device, however I do not see it in the list. Thanks!
My typo -- edited, thanks.
To be clear, the boot-counter reset works properly for the EA6350v3 without the patch!
I don't want to be rude but you are plain wrong.
Not all my job is merged. Since I've gone from this thread I've received 50+ PMs (which I will not answer) agking me to help them to revert bact to stock.
I've made a script which safely and easily can do that. It does a full check of the image (version, integrity, size, etc) and is an one-liner, it literally can't be easier than copying the image to the router and calling the script with the path to the image. That is a big value which is not upstream because it does not belong there.
Not to mention that all of we have a good wireless performance because @anders and I used another script that I made (for easily and safely testing calibration boards, again with full check and all the available calibration files from stock crafted with love to the right format, as they are not usable as-is) to get the best performance possible.
Also they were built using Linaro GCC and stripped using binutils's strip instead of sstrip, resulting in a objectively faster yet smaller binary. Not to mention the convenience of a binary that just works as expected for a home/small business router (with web GUI and such).
Let me tell you that the script for reverting to stock by itself is a big deal.
Hi @NoTengoBattery thanks for the reply, however: care to explain which of all my posts is plain wrong? and care to help us solve the issue here? the problem we see is that the images form instagram and other social network sites do not load when using the wifi. Wifi speeds are OK, and if using the LAN cable, images load fine, but we do not know for sure where the issue lies.
Has anyone managed to get the DLNA server running on this? I have the service installed and its showing under Services in the fw and my devices are detecting it, but no media is detected. Is it just a matter of creating a folder hierarchy on the storage device or is it something more involved than that?
Moving discussion of this specific issue to
Hi i've just noticed something weird.
I've not been able to update my maps on here maps (android) for a while. But today i disabled the wan6 IP6 DHCP client in the interfaces section. and now i am able to update my maps, before the app would complain it was offline.
My ISP does not provide IP6 addresses, could someone please try this on their setup to see if it fixes the instagram problem
I am also using OpenDNS addresses
Following the recomendations given to me in this community while seeking for a good cheap router with wifi ac support compatible with openwrt, I will buy this router.
I know I have to install the development snapshot.
Is there any drawback right now? Something that is not working or is working weird?
Something like wifi 5 GHz not working?
As long as I have read in this post it is working correctly.
If I have understood well, after installing the snapshot version provided in the router page, I will have openwrt with no luci web interface, and I will have to install luci afterwards.
If something goes wrong and the router bricks, is there an easy way to go back to stock firmware without soldering a serial interface?
I mean if there is a reset method that lets you upload the firmware via web or TFTP.
The documentation sends you the the generic debricking instructions, which does not help to know if you can debrick it without a serial interface (soldering in a new router will void warranty completly).
Thank you all for your work.
I will try to help in testing the router (I am not a low level developer, I cannot help in that).
Somebody told me therewas a pool for voting for inclusion of this router in the liist of compatibility hardware, but I don't find it.
Because such a pool does not exist.
There is still the issue with that for certain ISP:s, Instagram and similar applications may not work properly from Wifi on this router. I have not checked for the latest month or so but I guess the bug is still there.
Regarding reverting back there is a good script for this but unfortunately the author decided to shut down the repo some months ago. But being a big fan of @NoTengoBattery's work I of course had a copy of the repo so I can probably dig the script up if it's needed.
Thanks a lot.
I am afraid of jumping in this router and having problems, as you say.
I am deciding between this and the AVM friztbox 4040.
May be I would better wait a bit to see if the problem you comment gets solved.
If my daughters don't get access to photos in Instagram they will hang me.
Reverting back to oem firmware in case of problems is important too, but it seems to be solved with the script you mention.
It is a pity it seems a wonderfull router. I will see if I can debrick my tp-link 1043N v1.3 and install openwrt in it in order to wait a bit before buying.
What's the status of this?
I flashed the OpenWRT snapshot [http://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/openwrt-ipq40xx-linksys_ea6350v3-squashfs-factory.bin] as per https://openwrt.org/toh/linksys/linksys_ea6350_v3 and I'm struggling to configure the EA6350v3 like I configured my other OpenWRT devices, which is: Access point only, WAN as VLAN trunk, LAN 1 untagged to WAN VID n, LAN2/3 to WAN VID m, LAN4 untagged fallback port, SSIDs 1 to 4 to WAN VIDs a to d.
Does it not work b/c a) I don't understand how to do that properly for a eth0 + eth1 HW, b) it's not supported and a "VLAN on WAN port" not working marker is missing for the EA6350 (it's present for the FB4040), or c) the exact switch details aren't clear?
Is there a recommended way to configure such a scenario if eth1 is also available as a port of eth0?