Is there anything on the roadmap to support this hardware revision ? I received my CPE510 and realized that it is not a V3, It's a V3.8 . Thanks in advance for any info.
Looking around at a similar article for the CPE210, I've included a file with the same info provided there.
File Attachment:
Support for this device will not make our next production release, but should be in a patch release a short time thereafter.
Andre, K6AH
I've been playing around with the development environment, but I'm a little at a loss as to what makes this particular hardware different from the v3.0 hardware. I'm gonna keep poking at it. Thanks for the update.
-John
What have you tried so far and waht errors do you receive?
Have you tried the Binary from the CPE510 V3?
Lets start by trying the Generic Openwrt Ath79 Software for the CPE510 V3
https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_cpe510-v3-squashfs-factory.bin
You will need to use SSH to connect to the device on IP 192.168.1.1 if it loads
-John
Ok, I got this thing loaded with that firmware. It did take it and I am able to access the SSH server on it. I was also able to update and get LuCi on the device as well.
Ok Log on to the device using ssh
cd /tmp/sysinfo
cat *
and let me know what the output is.
tplink,cpe510-v3
TP-Link CPE510 v3
OK. Next step is to make sure you know how to recover the Pharos Firmware.
If you know the process we can then try the following
use scp to copy http://downloads.arednmesh.org/snapshots/trunk/targets/ar71xx/generic/aredn-1409-7243fe0-ar71xx-cpe510-v3-sysupgrade.bin to /tmp on the device
then force it to install with
sysupgrade -v -n -F /tmp/aredn-1409-7243fe0-ar71xx-cpe510-v3-sysupgrade.bin
Let me know if it runs. If so you should be able to configure the device as usual.
If you are using Windows here are the Windows Instructions. Note on Windows 10 you may need to disable the fireall while doing this
https://www.tp-link.com/fr-be/support/faq/844/
I normally recover using my Linux Laptop and a tftpd server
Well, looks like it may have worked, I can reach the web interface at 192.168.1.1, I haven't poked it too much yet.
Poking a little, normally the mesh ip auto-generates, in this case it did not, and I'm not sure what the algorithm is that would normally generate that. I get that I can use something in 10 space, but not sure if there are any limitations imposed in the code around what nets are ok and what aren't.
tried setting the mesh ip to something reasonable and I'm getting this when trying to save
parameter 'MAC2' in file '_setup.default' does not exist
OK Reboot the device and lets see if it helps.
Once rebooted if possible attach a copy of the Supportdata from the Admin Page.
Another thing to try is to reload the software now using the Aredn Software and see if it fixes the MAC2 error.
All that I did was just default the values and reboot the node, that seemed to clear it up. It seems to be working. I've attached the support data.
Also, have been able to confirm wireless function with a CPE610 peer.
One thing that is a little weird, is that the CPE510 does not issue a 10.0.0.0 route when it provides an IP. Also even once I have added a default route on my client (laptop), I'm not able to ping the wireless side of the CPE510 or the peer CPE610. Just something I guess, I've tried to re-acquire an IP several times with no change in behavior. So far this is the only real issue I'm seeing. Update: Solved this issue with the routes, may have been something to do with the version of dhclient that I was running.
Great. I am glad to hear that it seems to be working correctly now
The next thing to try is to download and upgrade to the latest stable release for the CPE 510 V3 located here
http://downloads.arednmesh.org/firmware/html/stable.html
Once it it running the Stable release 3.20.3.0 lets see if it works correctly.
Additionally it is a good idea to have a dumb switch between your computer and the Device when updating or configuring it.
The process did not produce any responseBad Gateway
It appears that the upgrade process did not proceed at all. I'm gonna try to do it from the command line and see how that goes.
Joe
Yes use the method we used before
If Possible please add a Photo Showing the Device Name and version from the Box and on the device
A new Supportdata would be helpfull if it upgrades to this version using the sysupgrade command
holding off, I was just about to upgrade it.
I have a second unit that has the same hardware revision, I've gone through the previous upgrade steps and I'm getting the same weirdness, where on reboot, it seems like the ethernet port, while link comes up, isn't passing any traffic. I have to do a reboot with 5-10 second reset, and this brings it back to normal.
I have compiled a version that I think fixes the problem you have.
It is a zip file located at https://andynet.duckdns.org/nextcloud/index.php/s/E7J9ryPiAp8Qbqd
I will be removing this file in a few days.
Please let me know if it works. The binaries are in files/target
Thank you Bill NG1P
Great. Once http://github.com/aredn/aredn_ar71xx/pull/497 is Accepted it will be part of the Nightly Builds
I upgraded using the nightly build, I'm getting the same behavoir. On hard power reset, dhcp not working, no frames. Takes a power reload + 5-10 seconds of reset button to restore normal behavoir. Update: Tested with your fix Andrew and got the same behavoir also.
Bill, Have you tried this ?
Joe AE6XE
Clarification,
The firmware that was used is both the nightly build, and Andrew's fix. They both show the same issue.
Will provide the support info within the next day or so.
Update:
I think that this is a symptom of the problem
[268809.057558] ------------[ cut here ]------------
[268809.062357] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:320 0x802ef55c
[268809.069618] NETDEV WATCHDOG: eth0 (ag71xx): transmit queue 0 timed out
[268809.076325] Modules linked in: ath9k ath9k_common ath9k_hw ath10k_pci ath10k_core ath mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CLASSIFY x_tables nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_log_common nf_flow_table_hw nf_flow_table nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack compat ipip tunnel4 ip_tunnel gpio_button_hotplug
[268809.135544] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.171 #0
[268809.141643] Stack : 8041f700 800b4114 80430000 803faac4 00000000 00000000 00000000 00000000
[268809.150246] 00000000 00000000 00000000 00000000 00000000 00000001 83c07db0 21973b21
[268809.158841] 83c07e48 00000000 00000000 00002778 00000038 8039f0d8 00000007 00000000
[268809.167421] 0000008a eb5d327f 00000089 73776170 83c07d90 00000000 00000000 803f6244
[268809.176012] 802ef55c 00000140 8041f754 8041f714 00000003 8024c614 00000000 80480000
[268809.184598] ...
[268809.187169] Call Trace:
[268809.187181] [<800b4114>] 0x800b4114
[268809.193414] [<8039f0d8>] 0x8039f0d8
[268809.197044] [<802ef55c>] 0x802ef55c
[268809.200684] [<8024c614>] 0x8024c614
[268809.204313] [<8006c20c>] 0x8006c20c
[268809.207952] [<8006c214>] 0x8006c214
[268809.211582] [<80086900>] 0x80086900
[268809.215210] [<802ef55c>] 0x802ef55c
[268809.218853] [<80086988>] 0x80086988
[268809.222499] [<802ef55c>] 0x802ef55c
[268809.226127] [<802ef3f8>] 0x802ef3f8
[268809.229766] [<800bfb60>] 0x800bfb60
[268809.233390] [<8006f614>] 0x8006f614
[268809.237037] [<800bfd2c>] 0x800bfd2c
[268809.240694] [<803a4478>] 0x803a4478
[268809.244320] [<800ba304>] 0x800ba304
[268809.247956] [<800b5860>] 0x800b5860
[268809.251590] [<80212ba0>] 0x80212ba0
[268809.255217] [<80067498>] 0x80067498
[268809.258862]
[268809.260468] ---[ end trace 1aa0c5b83df41e72 ]---
[268809.265236] eth0: tx timeout
[268825.057575] eth0: tx timeout
[268840.097560] eth0: tx timeout
[268860.097558] eth0: tx timeout
[268880.097559] eth0: tx timeout
[268900.097559] eth0: tx timeout
[268920.097564] eth0: tx timeout
[268940.097600] eth0: tx timeout
[268960.097562] eth0: tx timeout
[268980.097555] eth0: tx timeout
[269000.097559] eth0: tx timeout
[269020.097578] eth0: tx timeout
[269035.057582] eth0: tx timeout
[269055.057555] eth0: tx timeout
[269075.057558] eth0: tx timeout
[269095.057557] eth0: tx timeout
[269110.097560] eth0: tx timeout
[269125.057563] eth0: tx timeout
[269140.097564] eth0: tx timeout
[269160.097555] eth0: tx timeout
[269180.097561] eth0: tx timeout
[269200.097561] eth0: tx timeout
Sounds as though it might be driver related see
https://dev.archive.openwrt.org/ticket/18616
What version is the other CPE510 Neighbour your have?
What version of the software is it running?
It will be interesting to see if this is just a Problem with the V3.8 and not with other versions of the CPE510 v1, v2
What happens if you log on to the device and issue a reboot command? Does it behave the same way?
A soft reboot (Via UI or command line) results in the same no ethernet functionality. Unfortunately, I just got into this TP-link game, so both of my CPE510's are the v3.8 hardware. The other CPE510 has the same symptoms.
I know this is not a full time job for anyone, but I really appreciate the effort. This is a really great project and I appreciate how much help I have received from you folks. Thanks for all the hard work.
-John
OK, so I wimped out on the CPE210 v2.8 tests, so I decided I had a CPE510v3 which was running 3.19.3.0 that I could take the risk of semi-bricking (aka required mud-wrestling) and attempt to upgrade that to the new 3.20.3.0 release. Nope!
I removed the infamous MeshChat, stood on one foot and rebooted a few times (from 2 meters away) and then attempted to do a local file upload of 3.20.3.0 sysupgrade on a direct link from my laptop and it *failed* several times despite choosing to NOT keeping settings etc. Luckily nothing got changed so I can pretend that I didn't place its digital life in danger ...
I'll downloaded the support file and will email to Joe.
- Don - AA7AU
Joe AE6XE
That node was in running just fine with 3.19.3.0 - why would it now be considered a "new model". I'm confused.
TIA,
- Don - AA7AU
Joe AE6XE
Sorry, should have been more clear. Label says CPE510(US) Ver 3..0 s/n 2183092000164, p/n 015350335. sku 45973 07092 2
Was responding to "It will be interesting to see if this is just a Problem with the V3.8 and not with other versions of the CPE510 v1, v2".
Emailed support dump earlier,
Thanks for all your support!
- Don - AA7AU
N3XKD As the CPE510 V3.8 Is relatively new it is possible that the chipset has changed from the V2 or V3 devices.
I will look at building a version based on the ATH79 Branch of Openwrt for you to test but it may take a few days.
Once I have it ready I will provide a link for you to download it.
-John N3XKD
N3XKD I have created a build based on the ATH79 Branch.
Please download it here https://andynet.duckdns.org/nextcloud/index.php/s/E7J9ryPiAp8Qbqd and let me know the results .
NOTE: My Internet is currently down so only try it this evening
Thanks Andrew for your good work.
Andre, K6AH
-John
I really appreciate your efforts. I will await the nightly build.
-John
Pages