[OpenWrt-Devel] [WDR3600] factory using WPS-button and tftp doesn't work anymore (new hardware?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi :-) briefing: the automatic flashing-process - holding down the WPS-button in order to flash an image downloaded via TFTP - no longer works for certain WDR3600-devices with hardware revision 1.5 that have only minor (visible) differences to working devices with the same revision. .. this is going to be long - sorry for that. i'm trying to provide as many details as possible. I'm working on a factory-process for TP-Link WDR3600. Last week we have encountered an error where we were ( headache-english :-D ) not able to flash the last shipment using an automated process. There seems to be new hardware with the revision still being 1.5 but the u-boot behaving differently. - From the outside, these devices look quite similar - the only differences we've found so far are: - -there are four labels on the backside (as opposed to 3) the new one showing custom SSIDs (much like the one on the Archer-C5) - -a label on the inside on the yellow LAN-ports has a string 4FC-1, which we have not seen yet - the working boards have 3FC-3 The only way to flash our image to this new hardware is to either: - -flash manually using the u-boot-prompt (t ; e; cp.b; reset) - -upload it to the firmware-update-page of the stock-firmware The images then boot and seem to be happy. That, however, is not acceptable for a factory-process.. Turns out that our image was 6815748 bytes in size (we forked from openwrt a while ago) which is not accepted by these new devices using the existing process. The router instantly resets after the firmware has been received (before hte flash is erased). Have a look at Flashing via TFTP in http://wiki.openwrt.org/toh/tp-link/tl-wdr4300 to see what we're doing - - no magic involved :-) 'wrong_filesize.log' contains the serial-output when the file size is not 'correct'. So far, i've come to the conclusion that only files with size 8192512 / $7D0200 (bigger than the rootfs-mtd!) make it past the tftp download. I've tried padding the file with \x00 or \xFF. The file is then copied to the flash but will not boot. See 'successfull_flash.log' for the output. Notice the 'boot up image' after the transmission. You can see the error while booting at the end of that file (LZMA-length ). The last thing i've tried, is to use an image produces from OpenWRT-trunk - i gather you have introduced padding to the image since our fork. That image would also NOT be copied to the flash. Flashing does work if the file is padded to the 'magic' size but the boot-issue remains. I'm still working on this and will keep you informed - but if anyone of you has an idea on how to address this issue.. any help would be highly appreciated! The next thing on my TODO-list is to see how the image can be modified to make it boot. I'm comparing it to the firmware-upgrades from TP-Link (which do work using this process). But first: a good night's sleep :-p hoping this might help someone, kind regards, nice evenings to you, Leon M. George -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVuRlUAAoJEPImwNGZR6nxiNUH/RrfGmGI22Y5Vx3VwL3ub42v aTHAYGCEAKSLH3XFoxGOMJD0WU7YY1RqB7SAWghyghnGf1rK9IT+TELnjRkseB5u HpvG2sCb95ORCSXbxoPo9h6HRjZIH478MzVjoVAFO5EK37F/z4wSZd3rRz12Z6R2 NOej/Ie1mFO5Aqdzbpw7yhdDWNId+kzhULQeahyzIP7rExZzxOzLmnfhbb4gWueQ BK8TPtlFi7qQLyvE9SKsiXPWt6koprWbqW3EQOS/640AERaZbDgrzre5QZXBtrkI q+pSZw9KY98suPgZJe33/5nP23QaXsZjtAbg81KN9Smcelp6QeqS9f9ZMC5yI2I= =jBUP -END PGP SIGNATURE- U-Boot 1.1.4 (Oct 21 2014 - 12:49:00) U-boot DB120 DRAM: 128 MB id read 0x10ff flash size 8MB, sector count = 128 Flash: 8 MB Using default environment PCIe Reset OK!! In:serial Out: serial Err: serial Net: ag934x_enet_initialize... No valid address in Flash. Using fixed address wasp reset mask:c03300 WASP S17 PHY * : cfg1 0x7 cfg2 0x7114 eth0: ba:be:fa:ce:08:41 athrs17_reg_init: complete eth0 up eth0 dup 1 speed 1000 Using eth0 device TFTP from server 192.168.0.66; our IP address is 192.168.0.86 Filename 'wdr3600v1_tp_recovery.bin'. Load address: 0x8006 Loading: # # # # # # # # # # # #
Re: [OpenWrt-Devel] [WDR3600] factory using WPS-button and tftp doesn't work anymore (new hardware?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Just in case anybody was following this; i've worked around the issue by prepending the first 257 blocks from an official firmware-upgrade and than padding to the required size (8192512). It seems that the automatic process now expects u-boot and and an ominous info-block to also be contained in the image. that might not be the proper solution. if anyone of you has a better idea - i'd like to hear it :-) kind regards On 29.07.2015 20:20, Leon George wrote: Hi :-) briefing: the automatic flashing-process - holding down the WPS-button in order to flash an image downloaded via TFTP - no longer works for certain WDR3600-devices with hardware revision 1.5 that have only minor (visible) differences to working devices with the same revision. .. this is going to be long - sorry for that. i'm trying to provide as many details as possible. I'm working on a factory-process for TP-Link WDR3600. Last week we have encountered an error where we were ( headache-english :-D ) not able to flash the last shipment using an automated process. There seems to be new hardware with the revision still being 1.5 but the u-boot behaving differently. From the outside, these devices look quite similar - the only differences we've found so far are: -there are four labels on the backside (as opposed to 3) the new one showing custom SSIDs (much like the one on the Archer-C5) -a label on the inside on the yellow LAN-ports has a string 4FC-1, which we have not seen yet - the working boards have 3FC-3 The only way to flash our image to this new hardware is to either: -flash manually using the u-boot-prompt (t ; e; cp.b; reset) -upload it to the firmware-update-page of the stock-firmware The images then boot and seem to be happy. That, however, is not acceptable for a factory-process.. Turns out that our image was 6815748 bytes in size (we forked from openwrt a while ago) which is not accepted by these new devices using the existing process. The router instantly resets after the firmware has been received (before hte flash is erased). Have a look at Flashing via TFTP in http://wiki.openwrt.org/toh/tp-link/tl-wdr4300 to see what we're doing - no magic involved :-) 'wrong_filesize.log' contains the serial-output when the file size is not 'correct'. So far, i've come to the conclusion that only files with size 8192512 / $7D0200 (bigger than the rootfs-mtd!) make it past the tftp download. I've tried padding the file with \x00 or \xFF. The file is then copied to the flash but will not boot. See 'successfull_flash.log' for the output. Notice the 'boot up image' after the transmission. You can see the error while booting at the end of that file (LZMA-length ). The last thing i've tried, is to use an image produces from OpenWRT-trunk - i gather you have introduced padding to the image since our fork. That image would also NOT be copied to the flash. Flashing does work if the file is padded to the 'magic' size but the boot-issue remains. I'm still working on this and will keep you informed - but if anyone of you has an idea on how to address this issue.. any help would be highly appreciated! The next thing on my TODO-list is to see how the image can be modified to make it boot. I'm comparing it to the firmware-upgrades from TP-Link (which do work using this process). But first: a good night's sleep :-p hoping this might help someone, kind regards, nice evenings to you, Leon M. George ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVuofgAAoJEPImwNGZR6nx1dMIANVEkO3ERaqLn9sPRUWxQrSo 5BN9locEKM43DbV0qFFLQOZdOGjyfhon2WQTnh1yLf/1uiM5YcmJNSQSg8Cmt9cG h0Z+JgMVCj7T++6VYMqfqChilN1NXo6UB27qLiC2PGlp0MiTJB/XQzUQHS77jzTR p0ihP2Ie82DsLXCBLB0UAMyG6eyqxvWnwlTgrq6AWN/8nKWWQBIESoGltW016qMT DRfQc8Z9vy/HMcPC9yBRRD3Vk4tzUZ+5Y+5sTum9eBEmEUaQJXzmJAmJ9nNzgzrY NUjzhNIrnmYmDu0HHaecXL/aDIb4ZyvqtBbQMwBROtK45z+ZpZV2I4F67pJ1O1Q= =/A24 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [L2TP] Bad UDP Checksum on TP-LINK hardware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi :-) The UDP checksum for outgoing L2TP datagrams seems to be broken. It has been tested with TP-LINK's WR842n, WDR3600, and WDR4300. On two normal Linux computers it's working. We've tried disabling UDP offloading using ethtool without success. Is there any way we can make OpenWRT emit the datagrams with the checksum in place? This shows up in Wireshark. The first two datagrams are being received on the other side. The ones after the l2tp aren't. #this is received on the other end. normal udp 14.6944 UDP 575 52958 → 53201 Len=513 14.8159 UDP 152 53201 → 52958 Len=90 #ip l2tp add tunnel tunnel_id 52958 peer_tunnel_id 53201 encap udp local '2001:920:18ae:3:20b:c0ff:fe46:42b0' udp_sport 52958 remote '2a03:b0c0:3:d0::bb5:6001' udp_dport 53201 14.9130 UDP 184 52958 → 53201 Len=122 [ILLEGAL CHECKSUM (0)] 15.3230 UDP 152 52958 → 53201 Len=90 [ILLEGAL CHECKSUM (0)] 15.6929 UDP 184 52958 → 53201 Len=122 [ILLEGAL CHECKSUM (0)] 15.8198 UDP 164 53201 → 52958 Len=102 hoping somebody has an idea :-) cu, Leon -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEwBAEBCAAaBQJXmiiKExxsZW9uQGdlb3JnZW1haWwuZXUACgkQ8ibA0ZlHqfFq nAf/euEN7F1A80U8c6J4NE89qHiA98Nzjf1GorjhlOL5H2qQivxLp82ETQmJdUPt fzOqpOT3T2bCeR2G0HBtFVMvaHm5fc2cua2hguo+53NFR1oBHl85jsW9zt+AzIaD LPoi1nJqcLzLj7JjjYkoR8RIfBU8stq3YgLM78tvOKHmO/RYHbgOosJaIrgH2vZM VvBRLe6ro+snHrYeko570uke+M3/sURhFjL8wWKqzwqr/RGF0H4oF+X06/f1VB9J TLF/eA1JGTlL5RrjTZ6xVE2qFSa0uzNMtP3RgjRlBQj1tq1+AScRkn6loQ6bkKY8 MrbZSB0dURwCKNQ8P2sAVQzccw== =2r70 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
