Can't work in tp-link WR720N

[carneyzhang]

Hi,thank you for share this code.
I follow the readme buliding the firmware for WR720N router.In the menuconfig I also check uhci ohci usb2 usb3 module support,but when router connect the NS that nothing happened，the screen is black.
Could you help me,how can i do for this,thank you!

This is lede system log:
Tue Jun 19 12:27:29 2018 daemon.notice netifd: Network device 'wlan0' link is up Tue Jun 19 12:27:31 2018 kern.info kernel: [ 126.439156] br-lan: port 2(wlan0) entered forwarding state Tue Jun 19 12:31:24 2018 kern.info kernel: [ 359.069087] usb 1-1: new high-speed USB device number 2 using ehci-platform
This is console info:
root@LEDE:~# lsusb Bus 001 Device 002: ID 0955:7321 NVIDIA Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[DavidBuchanan314]

Did you add the kernel patch?

https://github.com/DavidBuchanan314/fusee-lede/blob/master/899-ehci_enable_large_ctl_xfers.patch

[carneyzhang]

Thank you in advance.
I follow the readme steps to build the firmware.
1.git clone https://github.com/DavidBuchanan314/fusee-lede/
2.git clone -b lede-17.01 https://git.lede-project.org/source.git lede
3.cp -r fusee-lede/fusee-nano lede/package/utils/
4.cp fusee-lede/899-ehci_enable_large_ctl_xfers.patch lede/target/linux/generic/patches-4.4/
5../scripts/feeds update -a
6../scripts/feeds install -a
7.make menuconfig
8.Utilities > fusee-nano => <*> and OHCI UHCI USB2 module support.
9.make -j8 V=99

I'm not sure whether already add the kernel patch.How to confirm it was patched?
Which process is 'fusse' in LEDE system?I want to use 'top' command view it.

[DavidBuchanan314]

The program only runs when a USB device is plugged in

https://github.com/DavidBuchanan314/fusee-nano/blob/master/files/20-tegra_rcm#L5

If you edit the command to BINARY="/usr/bin/fusee-nano /usr/share/fusee-nano/payload.bin > /tmp/fusee.log", then hopefully you can get some debug output.

Alternatively, you can run the program manually over ssh with /usr/bin/fusee-nano /usr/share/fusee-nano/payload.bin, and you should be able to see any errors.

[carneyzhang]

Thanks,I copy the patch and rebuild the firmware.It seems work correct,but NS is still not work。
Please see the system log:
[ 2.084755] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2.091206] ehci-pci: EHCI PCI platform driver
[ 2.095675] ehci-platform: EHCI generic platform driver
[ 2.100901] ehci-platform ehci-platform: EHCI Host Controller
[ 2.106549] ehci-platform ehci-platform: new USB bus registered, assigned bus number 1
[ 2.116558] ehci-platform ehci-platform: irq 3, io mem 0x1b000000
[ 2.136502] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00
[ 2.141565] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 2.148125] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.155292] usb usb1: Product: EHCI Host Controller
[ 2.160165] usb usb1: Manufacturer: Linux 4.4.135 ehci_hcd
[ 2.165620] usb usb1: SerialNumber: ehci-platform
[ 2.171319] hub 1-0:1.0: USB hub found
[ 2.174486] hub 1-0:1.0: 1 port detected
[ 2.178618] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2.184150] ohci-platform: OHCI generic platform driver
[ 2.189514] uhci_hcd: USB Universal Host Controller Interface driver

When i connect NS:
[ 1510.766503] usb 1-1: new high-speed USB device number 2 using ehci-platform
[ 1510.917316] usb 1-1: New USB device found, idVendor=0955, idProduct=7321
[ 1510.922584] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1510.929752] usb 1-1: Product: APX
[ 1510.932994] usb 1-1: Manufacturer: NVIDIA Corp.
[ 1587.643307] usb 1-1: USB disconnect, device number 2

This time i run the program manually in the lede system,it has some error:
root@LEDE:# /usr/bin/fusee-nano /usr/share/fusee-nano/payload.bin
[-] Failed to read device ID: Operation timed out
root@LEDE:# /usr/bin/fusee-nano /usr/share/fusee-nano/payload.bin
[-] Failed to read device ID: Operation timed out

[jnxfzhzx]

I have the same problem with tp-link mr11u.
First , the error message is same as carneyzhang :
[] device id: xxxxxxxxxxxxxxx
[] Read 92 bytes from intermezzo.bin
[] Read 71608 bytes from fusee.bin
[-] Sending payload failed: Operation time out .
After I modified the "TIMEOUT 1000" in exploit.c to "TIMEOUT 10000" ,and rebuild it.
It turn out to be the error:
[] device id: xxxxxxxxxxxxxxx
[] Read 92 bytes from intermezzo.bin
[] Read 71608 bytes from fusee.bin
[-] Sending payload failed: Broken pipe .

[xyqkent]

@jnxfzhzx Me too, me be we should modify the EHCI patch?

[jnxfzhzx]

@xyqkent No, I think it is the flaw of AR9331 chip set.

[sweetlilmre]

I have a similar issue with the TP-LINK TP-WR703N. Either the device generates USB errors:

usb 1-1: new high-speed USB device number 14 using ehci-platform
usb 1-1: device descriptor read/64, error -145
usb 1-1: device descriptor read/64, error -71
usb 1-1: new high-speed USB device number 15 using ehci-platform
usb 1-1: device descriptor read/64, error -145
usb 1-1: device descriptor read/64, error -71
usb usb1-port1: attempt power cycle
usb 1-1: new high-speed USB device number 16 using ehci-platform
usb 1-1: device not accepting address 16, error -71
usb 1-1: new high-speed USB device number 17 using ehci-platform
usb 1-1: device not accepting address 17, error -71
usb usb1-port1: unable to enumerate USB device

Or I get:

[   81.666491] usb 1-1: new high-speed USB device number 3 using ehci-platform
root@LEDE:/# lsusb
Bus 001 Device 003: ID 0955:7321 NVIDIA Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@LEDE:/# /usr/bin/fusee-nano /usr/share/fusee-nano/payload.bin
[-] Failed to read device ID: Operation timed out

[sweetlilmre]

Further info, when I prevent hotplug from automatically executing the binary I get this:

[] device id: 80050419000000xxxxxxxxxxxxxxxx62
[] Read 92 bytes from /usr/share/fusee-nano/intermezzo.bin
[*] Read 38168 bytes from /usr/share/fusee-nano/payload.bin
[-] Sending payload failed: Operation timed out

So this seems to be the same issue as the other folks are reporting.

[DavidBuchanan314]

@carneyzhang It's suddenly occurred to me what might be causing this.

What is the endianness of you device's CPU?

[sweetlilmre]

@DavidBuchanan314
In my case its a mips 24k chip, which apparently can be either. Google suggests big endian for the openwrt build, but I can check this explicitly.

[DavidBuchanan314]

@sweetlilmre assuming it is bigendian, I've just pushed what I hope is a fix. Would you mind building from the latest commit, and let me know how it goes?

[sweetlilmre]

@DavidBuchanan314
Looks like a link issue:
exploit.c:(.text.startup+0x12c): undefined reference to `htole32'

[DavidBuchanan314]

@sweetlilmre Ooops. I think adding #define _BSD_SOURCE to the top of exploit.c fixes that. Sorry, my build machine is slooooow, so it's taken me a while to get to this point...

Edit: I fixed the code in the repo with a force-push, because I'm evil.

[sweetlilmre]

That's hilarious :) I just discovered the _BSD_SOURCE requirement before I saw this.
Building now. It seems that the OpenWRT uClibc is not glibc:
https://stackoverflow.com/questions/19525378/be64toh-not-linking-or-being-declared-when-compiling-with-std-c99

[sweetlilmre]

I finally got a build up and flashed (comedy of errors). Unfortunately it doesn't seem to work. I still get the same USB errors.
I'm running a clean build now and will test at some point later, possibly tomorrow night (it's late here now).
Thanks for looking at this.

[sweetlilmre]

@DavidBuchanan314 confirmed. Completely fresh build and I still have the same USB errors.

[DavidBuchanan314]

Oh well. Thanks for trying though.

[jnxfzhzx]

I builded a x86 version 2 month ago and it worded fine in my HP Notebook. I think it is the flaw of AR9331 chip set , so I give up.