Hacking I'm having trouble pushing payloads on Ubuntu 20.04 once again

Worldblender · Oct 11, 2020

I'm trying all that I can to be get into using CFW onto my unpatched Switch unit, after about a year of not doing so. After getting a payload to launch successfully, everything else works well, however. My setup currently consists of:

Use fusee-launcher, or the interface at https://github.com/nh-server/fusee-interfacee-tk
My SanDisk 64GB microSD card already has the latest Atmosphere (0.14.4) and Hekate (5.3.3) installed
I'm exclusively using USB 3.x ports to connect my Switch unit to my desktop computer
fusee-launcher is running on Python 3.8.5

However, in the most recent cases today, I've only been able to push the test payload once today, and not fusee-primary or Hekate payload. Both of these show no change; the Switch screen stays black, making it harder for me to pinpoint the exact issue with my setup (sometimes without a microSD card, or different ones). Force power off and powering on again is not always reliable in terms of whether I can get payloads to load successfully. I know I can alos use TegraRCMGUI, but it exists only for Windows, and I wish to avoid or reduce my usage of proprietary OSes.

If I try again to send the same payload if it failed, I'm greeted with this traceback:

Code:

Important note: on desktop Linux systems, we currently require an XHCI host controller.
A good way to ensure you're likely using an XHCI backend is to plug your
device into a blue 'USB 3' port.

Identified a Linux system; setting up the appropriate backend.
Traceback (most recent call last):
  File "fusee-launcher.py", line 606, in <module>
    raise e
  File "fusee-launcher.py", line 601, in <module>
    device_id = switch.read_device_id()
  File "fusee-launcher.py", line 543, in read_device_id
    return self.read(16)
  File "fusee-launcher.py", line 500, in read
    return self.backend.read(length)
  File "fusee-launcher.py", line 118, in read
    return bytes(self.dev.read(0x81, length, 1000))
  File "/usr/lib/python3/dist-packages/usb/core.py", line 983, in read
    ret = fn(
  File "/usr/lib/python3/dist-packages/usb/backend/libusb1.py", line 828, in bulk_read
    return self.__read(self.lib.libusb_bulk_transfer,
  File "/usr/lib/python3/dist-packages/usb/backend/libusb1.py", line 936, in __read
    _check(retval)
  File "/usr/lib/python3/dist-packages/usb/backend/libusb1.py", line 595, in _check
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 110] Operation timed out

This makes me think that the problem lies in the Linux kernel I'm using (5.6.0-1028-oem), or the hardware I'm using to send the payload. It is my desktop computer with the following main specs:

AsRock B450-Pro4 ATX motherboard, AMD B450 chipset
AMD Ryzen 3 3200G APU

With the B450 chipset, there are only XHCI controllers, no EHCI controllers of any kind (the USB 2.0 ports are also using XHCI). With a blank Switch screen, it makes it hard for me to determine exactly where my problem lies at. Repeated failures to successfully get other payloads to launch on my unit, despite being unpatched, may frustrate me to the point where I may stick only with OFW, because sending payloads left a bad taste with me.

Update: I was using the archives from https://www.sdsetup.com for the payloads. I was able to solve this problem for once by using the Hekate payload from the Github releases page. Instead, the problem could be to look like malformed payloads.

Draxzelex · Oct 28, 2020

Have you tried using another OS such as Windows or Android?

Worldblender · Oct 28, 2020

Draxzelex said:
Have you tried using another OS such as Windows or Android?

I have already tried Windows before, but it is not always an option for me. The point is that I can do my whole setup without having to rely on proprietary software, except for whatever is on my Nintendo Switch.
Sometimes I am successful in getting a payload to successfully load; it is not that I never can get one to load. Through my testing, I have determined that it could be related to payloads getting corrupted on a filesystem before I can send them, on a SSD or HDD. However, I discovered that I may have a better chance of success if I place a payload on a ramdisk, such as in "/tmp", as less things are likely to be corrupted over there. Maybe I should file an issue over this problem, and see if it can be investigated further.

Hacking I'm having trouble pushing payloads on Ubuntu 20.04 once again

Well-Known Member

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum