Fender Rumble LT 25 support?

I do know this project is for the Mustang amps, but I was wondering if the bass amp support was ever considered.

At the moment I still do not own the bass amp, but I wanted to check whether anyone using it with Linux, when I found this project.
I know it is wishful thinking, but I hope that it may have the same or very similar hardware in respect of the connectivity and I could use it under Linux.

Thanks in advance,

I don't have any experience with the amp unfortunately. Is there a software like the former FUSE to control it?

Now, I have the device.

lsusb output:

Bus 002 Device 005: ID 1ed8:0038 FENDER MUSICAL INSTRUMENTS CORPORATION Rumble LT 25

dmesg:

[ 3852.321058] usb 2-1.2: new full-speed USB device number 6 using ehci-pci
[ 3852.420588] usb 2-1.2: New USB device found, idVendor=1ed8, idProduct=0038, bcdDevice= 2.00
[ 3852.420600] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3852.420606] usb 2-1.2: Product: Rumble LT 25
[ 3852.420610] usb 2-1.2: Manufacturer: FMIC
[ 3852.420614] usb 2-1.2: SerialNumber: 00000000001A
[ 3852.422940] hid-generic 0003:1ED8:0038.0008: hiddev97,hidraw3: USB HID v1.11 Device [FMIC Rumble LT 25] on usb-0000:00:1d.0-1.2/input0

Let me know If there are any other output, that can be useful.

I have installed plug from AUR, version 1.4.2-1, it does not recognize the amp: ERROR: Failed to open usb device

Is there a software like the former FUSE to control it?

Fender Tone shoud be used, but I still haven't got any time to test it via wine. I will report if I had any success.

edit: dmesg output added

I have installed plug from AUR, version 1.4.2-1, it does not recognize the amp: ERROR: Failed to open usb device

Even though this version is old, the USB PID isn't implemented. The main question is: Does this type of amp use the same protocol as the Mustangs?

Does this type of amp use the same protocol as the Mustangs?

I don't know. I would use the same (or as close as possible) , because it is more expensive to develop and maintain a completely different one, just because it is a bass amp and not a guitar amp.

Do you have any idea how could I find out?
I haven't read every paper I've got, but I do think those are for the end users and not hackers.
By the way, the mustang amp protocol are completely reverse engineered or there are some documentation available?

No, everything is reverse engineered and without any docs unfortunately. I don't assume there's one for newer generations :-/ .

I don't know. I would use the same (or as close as possible) , because it is more expensive to develop and maintain a completely different one, just because it is a bass amp and not a guitar amp.

Yea, wouldn't make sense to me too.

Do you have any idea how could I find out?

Do these amp share any settings like amps with the mustang series? If so, maybe we can use the current configurations and try. Or, we send an init sequence and see what we get back.

The best way would be to dump the communication of the official software though.

Hi, I own the Mustang LT 25 and have used the Rumble LT 25. They both have the exact same user-interfaces - the only difference seems to the the amps & stompboxes themselves.

So it could work to dump the values.

I have a Mustang LT25. I'd be happy to help get this supported!.

How would I go about getting a communications dump? I have access to a Windows machine.

How would I go about getting a communications dump? I have access to a Windows machine.

You can use Wireshark and record the communication of the official software with the amp.

What we can try: Add the USB VID / PID mentioned above and see how far we get.

Update: I have prepared a branch: experimental/lt25

Alright I'm up and running. On Windows and I have Fender Tone LT Desktop version 1.5.0.10741 installed and have successfully captured packets with it with Wireshark. Able to see what looks like volume adjustments and such when I make them on either side.

I'm new to reverse engineering a binary protocol, so I might need a little help getting started. I didn't quite follow what you were saying. It sounds like you want me to checkout that branch then build and run the app and just see if it works with those changes?

Also just to clarify, I have the Mustang LT25 and not the Rumble LT25.

Let me know if you'd like me to send you some capture data from Wireshark. I'm also happy to jump on Discord, IRC, etc. if that would help!

Also just to clarify, I have the Mustang LT25 and not the Rumble LT25.

Thanks for pointing that out, didn't know there ware different types of LT25.

It sounds like you want me to checkout that branch then build and run the app and just see if it works with those changes?

Yes (if you have some minutes spare). But before this I have to change PID. I assume the VID is same, but can you post the Mustang LT25s PID?

Let me know if you'd like me to send you some capture data from Wireshark. I'm also happy to jump on Discord, IRC, etc. if that would help!

The first thing to figure out: Does the device use the same protocol as the others? So the initial two packets send to the amp are most interesting I guess (these initialize the communication).

Can you attach the first two packets (or the wireshark dump)?

~~Sorry, not familiar with what a VID and PID are. How would I find them?~~

Nvm, will use lsusb when I boot back into Linux to get this.

Will get some Wireshark data shortly.

Would it be safe to attach a dump here or could there be sensitive data in it?

Here's what I believe you're looking for for the VID/PID:

Bus 003 Device 017: ID 1ed8:0037 FENDER MUSICAL INSTRUMENTS CORPORATION Mustang LT 25

Let me know what I should do about the dump file and if it would be safe to just attach it here. Happy to email it to you or by other means.

Will get some Wireshark data shortly.

Would it be safe to attach a dump here or could there be sensitive data in it?

If it's only the usb communication with the amp, there's no sensitive data in it. Just make sure you filter right.
You can also paste the hex bytes of the first packets here, that should enough for the first steps.

Here's what I believe you're looking for for the VID/PID:

Exactly! 👍 1ed8 is the vid and 0037 is the pid.

I have updated the branch with this pid.

Ok well here is the first packet:

0000   1c 00 20 fa 3e eb 86 86 ff ff 00 00 00 00 0b 00   .. .>...........
0010   00 03 00 10 00 80 02 08 00 00 00 00 80 06 00 01   ................
0020   00 00 12 00                                       ....

It's info is "GET DESCRIPTOR Request DEVICE". And I guess I'll paste the second packet here that was the "Response" while I'm at it:

0000   1c 00 20 fa 3e eb 86 86 ff ff 00 00 00 00 08 00   .. .>...........
0010   01 03 00 10 00 80 02 12 00 00 00 03 12 01 00 02   ................
0020   00 00 00 40 d8 1e 37 00 00 02 01 02 03 01         ...@..7.......

Let me know if this looks right.

Thanks! From a first look it looks like the device uses a different protocol format. The other Mustangs use 64 byte (16 byte header + 48 byte payload) and the initial first two packets (send to the amp) use other values.

So testing the branch mentioned above wont help much :-(

Are request / response constant between connections or are there values that change?

Sorry, not sure I understand your question or would know what to look for.

Here's my .pcapng file: mustang_init.zip

Let me know what else I can do to help.

Thanks! Regarding my question: If you connect your amp multiple times, are the bytes always as listed above or is there a difference?

Update:

The amp seems to use a different (but similar?) format.

Sorry for the very long delay! Hadn't booted up Windows in a while.

I ran a capture again and these were the results:
mustang_init2.zip

Does it seem like there's a difference compared to the first?

No problem. Thanks, I'll have a look at it.

Update

The first packet sent uses some different bytes (unlike normal mustang devices do!?)

I just got a Mustang LT25, and took a quick look in Wireshark.

It looks like the Fender Tone application communicates with the amp over HID messages. I've only had a quick look, but at startup, the amp sends all the current presets as JSON. Selecting a preset in the application sends a message that starts with an integer corresponding to the preset bank to switch to.

I haven't had a chance to really dive into it, but I hope to have some time over the next month.

I'll start putting together some documentation of the protocol, and share the link here once I get started.

I've got some good news and bad news.

Bad news is that the protocol seems to be different enough from the previous amp versions that it will likely require a complete rewrite of the code to handle communications with the amp (I have only scanned the current code, not familiar enough with it to say for sure).

Good news is that Fender used protobuf for their new amps, and using this tool on the Fender Tone LT executable file, I was able to pull the entire protobuf spec!

Basically, the Fender Tone software and the amplifier communicate over USB HID data messages, and the data is sent as protobuf, with json embedded in the protobuf messages for the preset settings.

I'm in the process of documenting it and putting together a library and a simple dotnet core application to allow for importing and exporting the presets to files. I'll be expanding that to a more powerful amp controller after I finish the initial library and documentation.

I haven't done much C/C++ programming (other than Arduino) in a very long time, and I'm more comfortable in C#, but everything will be dotnet core so that it will be able to run on Linux. Of course I will be sharing all the documentation I come up with so anyone else can implement it as they would like.

I have documented the protocol used by the amp, and created a rough implementation of a library in dotnet.

I haven't had a chance to test this on linux yet, but it uses HidSharp, which is cross platform, and that's the only thing that reaches outside of the code itself.

There is literally no user code at the moment, but my next step will be to create a UI. I'm still trying to figure out which cross-platform UI in dotnet will work best. I have to find a raspberry pi (I have a billion of them, and I don't know where they all are - even some of the ones that are running!), and try some of the toolkits out (but if anyone has any suggestions).

If anyone is interested in porting this to another language, it's actually a pretty simple protocol. All the "messages" sent between the computer and amp are protobuf, and all the protobuf schema documents were extracted from the Fender Tone executable. From there it was just generating the stubs for my programming language with protoc, and wrapping it with the USB HID code. I feel like I've documented it pretty well in my repo, but if there are any questions, I'm glad to help out. I will be taking a stab at a C++ version sometime in the future, if only to help build my skills back up.

Take a look. I know that there are probably some major issues with the design; I was mostly focused on having something "work" and getting it documented.

@offa

I did some work in late 2024 and early 2025 on the codebase of this project and managed to get a fork of this project running which was able to download and save the presets from a Fender Mustang LT40S. I did raise PR #28 with some of this work, but after a bit of thought I realized that the volume of change in this PR was too extensive for @offa to accept it as a single PR.

After a couple of weeks reflection I also became concerned that it might be a bad idea for me to make major changes to the plug codebase as I didn't (at that time) have access to a device which spoke the original FenderFUSE protocols implemented in plug, so I couldn't run any physical tests to confirm that I hadn't broken anything major in relation to the original Mustang ranges supported by FUSE.

Since April, I've been working on my own project for the LT series, for which the USB comms component is implemented in Java, at:

There's a demo of what I've got working so far in this YT video.
I've also started work here on a body of code and documentation trying to explore the relationship between the XML-based .fuse format used by the FenderFUSE program and the (different but similar) JSON-based formats used by the USB/Desktop and BluetoothLowEnergy/Mobile variants of the FenderTone app. It's reasonably clear that these formats are based on the same relational data model of a preset, and that translation between the formats is very feasible.

As of earlier this week, I became the owner of a pre-owned Mustang I v2 amp, so my earlier concern about being able to test that I haven't broken support for older devices from the ranges supported by FenderFUSE are less of an issue.

If @offa is still keen to have LT-series support in plug, I'll be happy to start work on it in 2026, but I think this is going to need multiple PRs over an extended period of time to get going, and it is probably that the first one or two PRs would need to contain some refactoring to establish a common interface that can have at least two separate implementations for the 'classic' and 'LT' generations (I note that there might be a third implementation if @offa is happy for me to split the existing 'classic' code to have separate implementations for V1 and V2 devices rather than continuing with the current isV2amp() function).

I feel that this is probably going to need some design discussions rather than just communicating via PRs and issue tickets - is it possible to get GH Wiki behaviour enabled on the project, or would there be a forum @offa or others would prefer? I could fork the project (again) and enable wikis on my fork of course, but I see this as @offa's project and I think he should probably own the design forum if there is to be one.

Finally, if anyone is interested in the work I've done at GitHub in the two repos of my own referenced above, please contact me via my LinkedIn profile. I plan to continue working on both of these repositories, but the UX I'm aiming at with my work has a different focus from plug, and I'm keen to make a contribution to plug as well if it is welcome.

While the UI part isn't covered by tests, the communication is very well – so you can check other devices there too, even without an actual amp.

Wiki is enabled on this project, as well Discussions.

Support for non-Mustang devices is still somewhat of a headache. As you already mentioned, more extensive refactorings are necessary for this – however, at both ends, communication and UI. Contributions are still welcome.

However, I often find myself wondering to what extent refactoring is still practical, or if rewriting might be more effective?

@offa

Thanks @offa for the very prompt response to my questions.

you wrote:

Wiki is enabled on this project, as well Discussions.

I'm not sure what you meant by this, I can't see either of those items in the GitHub tab headings (i.e. between 'Code' and 'Insights' in the screenshot below). Maybe you can see them but access control prevents me seeing them.

For the moment, I've opened these GH features on my own reverse engineering documentation repository (not the one containing the code of my Maneline app), and you and anyone else who contributes to plug are welcome to start discussions or edit the wiki there. I didn't want to open the discussions/wiki up to uninvited authors as I expect that will bring spam, so I've sent invitations to become collaborators there to you and everyone else who has commented on this ticket. Obviously my repository is a fine place to post discussions about the .fuse format and the JSON-based formats used at the protocol level by later companion applications, I have no objections if people want to have discussions there about possible plug future refactors but I'd expect that you would probably prefer these to be in your space rather than mine.

The initial wiki page is here:
https://github.com/tim-littlefair/moonshine-wrangler/wiki

you also wrote:

Support for non-Mustang devices is still somewhat of a headache. As you already mentioned, more extensive refactorings are necessary for this – however, at both ends, communication and UI. Contributions are still welcome.

However, I often find myself wondering to what extent refactoring is still practical, or if rewriting might be more effective?

Obviously, my Maneline project is an completely alternative implementation to plug in a different primary language and framework, apart from saying how grateful I am that you've chosen to push plug this far up the hill I can't second guess whether you should choose to continue with the existing implementation, start a new one yourself, or take a well deserved rest and let somone else pick up the task of supporting later generations of devices.

If you're considering the third option above, I've got a couple of comments about how I see the relationship between plug, Maneline and the reverse engineering/doco at moonshine-wrangler:

@piorekf's original plug is still a package in the outer subdivisions of the Debian/Ubuntu distro infrastructure. That's not nothing in terms of ease of access for people who might find it useful. Given that @piorekf does not seem to be Have you considered getting someone (I'm prepared to volunteer) to offer to Debian to package your fork as an update relative to the original?
plug is a desktop app, and while Maneline has a command line app and a web app (which is really just a wrapper around the command line), I see the common Java library used by these two apps as the main product of Maneline projects, and the CLI and web apps (and the android app which I confess to having lost interest in to some extent) as just a-bit-more-than-minimal worked examples of how the library can be integrated. I get some sense @brentmaxwell's LtAmp maybe has a similar motivation. On my part this plays into a general dislike of mobile-app-dependency as a path to premature obsolesence and enshittification - lets move on from "there's an app for that" to "there's a library for that".
in regard to my personal plan for Maneline, I'm not a fan of intricate GUI's, having established that the GT(X)-/LT(X)- protocol preset objects in JSON, as an old school Unix guy I regard /usr/bin/vi as a perfectly adequate answer to the question 'How should we edit our presets when they are stored on a computer?'. I don't plan adding parameter editing to any of my example apps (but I'm completely open to others picking up the library and doing their own spin of an app).
finally, in relation to plug refactoring (should that be something that happens), one of my hopes for the work I'm doing in the moonshine-wrangler repo is that I hope to be able to automate transcoding the 9000+ .fuse files rescued when fuse.fender.com closed down into a format which can be loaded into the LT-, MMP, GT(X)-, LTX- (at least in relation to modules for which a corresponding version is available in the target device). A probable side effect of this would be being able to generate Java and C/C++ header files linking the UI-visible names for DSP modules and their parameters to the relevant numeric constants (for the .fuse format).

Anyway, apologies for turning this into a bit of a rant, please enjoy the festive season and thanks for everything you've done to date on plug.

@piorekf

I'm not sure what you meant by this, I can't see either of those items in the GitHub tab headings (i.e. between 'Code' and 'Insights' in the screenshot below). Maybe you can see them but access control prevents me seeing them.

Thanks for bringing this up. Indeed both weren't configured correctly. Should be fixed now.

@piorekf's original plug is still a package in the outer subdivisions of the Debian/Ubuntu distro infrastructure. That's not nothing in terms of ease of access for people who might find it useful. Given that @piorekf does not seem to be Have you considered getting someone (I'm prepared to volunteer) to offer to Debian to package your fork as an update relative to the original?

I'm not involved in the Debian packing, but an updated packaged would be great.

Navigation Menu

Repository navigation

Fender Rumble LT 25 support? #7

Update:

Update

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Fender Rumble LT 25 support? #7

Description

Activity

offa commented on Oct 18, 2021

pintergreg commented on Oct 22, 2021

offa commented on Oct 22, 2021

pintergreg commented on Oct 22, 2021

offa commented on Oct 24, 2021

Luhav commented on Dec 24, 2021

offa commented on Dec 27, 2021

ScottG489 commented on Apr 4, 2023

offa commented on Apr 4, 2023

ScottG489 commented on Apr 5, 2023

offa commented on Apr 5, 2023

ScottG489 commented on Apr 5, 2023

ScottG489 commented on Apr 6, 2023

offa commented on Apr 6, 2023

ScottG489 commented on Apr 7, 2023

offa commented on Apr 8, 2023

ScottG489 commented on Apr 11, 2023

offa commented on Apr 12, 2023

Update:

ScottG489 commented on May 18, 2023

offa commented on May 21, 2023

Update

brentmaxwell commented on Dec 23, 2023

brentmaxwell commented on Jan 6, 2024

brentmaxwell commented on Jan 23, 2024

tim-littlefair commented on Dec 18, 2025

offa commented on Dec 19, 2025

tim-littlefair commented on Dec 24, 2025

offa commented on Dec 27, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions