Config files export successfully, yet writing them doesn't work (except for --hard_reset flag)

[doccnova]

Hello. Had such a dillema. I decided to test the software and set it up, yet met an unexpected turn of events. The software can pull the current config from the mouse, yet can't write it to it, whatever you do, - only --hard_reset flag works. Is there any workaround with it?

Specs, just in case:

Laptop: Lenovo ideapad Y700-15ISK
Processor: Intel Core i5-6300HQ
GPUs: Intel HD 530 + Nvidia GTX 960M
RAM: 2x8 GB
Hub that connects the mouse: some Novodesk I bought from ozon.by for 'round 20 BYN
OS: openSUSE Tumbleweed

[so1der]

Hello there! That's interesting.
Does any error appear, or something?
Does the mode change command not work as well?

python cli.py -m 1  

That's interesting because, to pull the config from the mouse, this software needs to send a specific command to it. So it can communicate with the mouse, but still, it can't send the new config. Hmm.

[doccnova]

Hello there! That's interesting. Does any error appear, or something? Does the mode change command not work as well?

python cli.py -m 1  

That's interesting because, to pull the config from the mouse, this software needs to send a specific command to it. So it can communicate with the mouse, but still, it can't send the new config. Hmm.

Just checked. No errors. Neither there are in attempt to load the modified config. The software thinks that the config is uploaded, yet it's not

[so1der]

Hmm, are you familiar with Wireshark? It can "sniff" USB packets, and it would be really helpful to look at them. For example, we could compare your packets with mine.
Also, do you have the M601-RGB version of the mouse, or just the M601? Because when I created this repository, I simply didn't know about the existence of the regular M601 version :D
That's why the repository name may be misleading.

[doccnova]

Hmm, are you familiar with Wireshark? It can "sniff" USB packets, and it would be really helpful to look at them. For example, we could compare your packets with mine. Also, do you have the M601-RGB version of the mouse, or just the M601? Because when I created this repository, I simply didn't know about the existence of the regular M601 version :D That's why the repository name may be misleading.

First, not really, yet can easily install it. Second, I definitely have the M601-RGB (they differ with both code and name: the M601 is just Redragon Centrophorus, and the M601 RGB is Redragon Centrophorus 2)

[so1der]

Great! Then we can use Wireshark to check whether the packets are being formed correctly and whether the mouse reacts to them at all.

For example, I just tried switching the mouse mode to the first mode. You can unpack and open this file in Wireshark. I can see that the packet was formed correctly (the control bytes are visible – 05 02 01), and the mouse responded to it by sending some kind of package.

You can try capturing an attempt to change the mode and an attempt to send the config using Wireshark (preferably as separate files). This article might help.

One more thing – since Wireshark will capture ALL packets of specific USB port, it's best to connect the mouse directly rather than through a hub during testing. Also, flip it upside down so that the sensor doesn’t work, and use laptop's touchpad, because every mouse movement generates thousands of packets that Wireshark will also capture, making it extremely difficult to find required packages.

I'll try my best to understand something from packages that You will provide.

change_mode.tar.gz

[doccnova]

Great! Then we can use Wireshark to check whether the packets are being formed correctly and whether the mouse reacts to them at all.

For example, I just tried switching the mouse mode to the first mode. You can unpack and open this file in Wireshark. I can see that the packet was formed correctly (the control bytes are visible – 05 02 01), and the mouse responded to it by sending some kind of package.

You can try capturing an attempt to change the mode and an attempt to send the config using Wireshark (preferably as separate files). This article might help.

One more thing – since Wireshark will capture ALL packets of specific USB port, it's best to connect the mouse directly rather than through a hub during testing. Also, flip it upside down so that the sensor doesn’t work, and use laptop's touchpad, because every mouse movement generates thousands of packets that Wireshark will also capture, making it extremely difficult to find required packages.

I'll try my best to understand something from packages that You will provide.

change_mode.tar.gz

Okay... Either I'm doing something wrong, or I don't know. I honestly didn't understand the article, and there are 3 usbmon mount points - usbmon0, usbmon1 and usbmon2 (the last one is from the laptop's webcam, I guess), and I just can't detect the exactly needed thing as it all moves TOO fast xD

[doccnova]

I'll tell you more: in neither of the mount points, I didn't caught any URB_CONTROL signals, which's weird by itself

[so1der]

No, if you were able to see the USB packets, then the article has already done its job :)

Regarding usbmon0, usbmon1, usbmon2 – if I'm not mistaken, these are the USB ports. However, it seems that this could also be a USB hub inside the laptop if the laptop has more than three USB ports. Or some other devices connected to the internal USB bus, yes.

You can identify the correct usbmon interface by opening it and moving the mouse back and forth – a whole bunch of USB_INTERRUPT packets will be generated. That’s the one you need. If other packets appear even when the mouse is inactive, then that’s strange.

When I move my mouse, it generates USB_INTERRUPT packets. USB_CONTROL appears only when I try to change the mouse mode (or trying to upload config, if I recall correctly)

[doccnova]

No, if you were able to see the USB packets, then the article has already done its job :)

Regarding usbmon0, usbmon1, usbmon2 – if I'm not mistaken, these are the USB ports. However, it seems that this could also be a USB hub inside the laptop if the laptop has more than three USB ports. Or some other devices connected to the internal USB bus, yes.

You can identify the correct usbmon interface by opening it and moving the mouse back and forth – a whole bunch of USB_INTERRUPT packets will be generated. That’s the one you need. If other packets appear even when the mouse is inactive, then that’s strange.

When I move my mouse, it generates USB_INTERRUPT packets. USB_CONTROL appears only when I try to change the mouse mode (or trying to upload config, if I recall correctly)

Fun thing is, that the usbmon2 is inactive, and there's one DEVICE request from the webcam (to be exact, from it's depth sensor), and after 68th package, it halts. Yet the other two ALWAYS send packages from the mouse, which's weird (I even disconnected all the cables and hubs except for my mouse (yet I guess that the right two USBs are connected in one hub, yet I'm not sure), so it's weird

[doccnova]

Okay, hol' up! I got it, I guess. The URB_CONTROL flag appeared ONLY when I used the CLI tool, not via the button. On the upload (not switching mode), it gives from 00 02 01 to 83 02 01, I'll try with mode switch now

[so1der]

Oh, yes, right, I should have mentioned that I used the CLI for that :D

[doccnova]

Uh-huh... yet on the mode switch, it simply gives 00 02 01, not the 05 02 01, which already is weird...
It's on lines 739 and 740:

urb_control.tar.gz

[so1der]

Hmm, but I can see the correct data on line 739 – 05 02 02, switching to mode 2

Yet, on line 751, there is another control packet that seems weird

So, the mouse didn’t react to the packet on line 739 at all?

Because no matter what mode it was in before, when I try to change the mode (even from the 1 mode to the 1 mode), the mouse still reacts by displaying the mode color. (It can be changed in the software, but by default, it seems to be blue and red.)

[doccnova]

...Huh? Now that's somethin' definitely weird... When I press the button, it changes color to red and blue indeed... yet just re-checked, it just refreshes the lighting when the python3 cli.py -m 1/2 is written, aka "resets" the lighting to the start point, without changing the mode

[so1der]

That's really interesting..
Well, as far as I can tell, there are no issues with the packets, so the program is functioning as it should, and the system isn't interfering either. Yet, the mouse still doesn't react to the packets or reacts strangely...

Could they have somehow changed the protocol? But then it would be strange that the program can still fetch the settings from the mouse.

Have you ever tried to use a program from the manufacturer that is for Windows, or is this your first attempt at setting up a mouse?