I have multiple server rack style test stations that have there own power, ethernet, and usb hubs used for serial that run back to a server for embedded devices that we load and test our software on. We connect to the server and use ser2net to talk to the devices. I have been using the buspirate locally without any issue to help with some reverse engineering work and have a few more in the rack, but I seem to be running into disconnect/reconnect issues with the buspirate in ser2net upon initial connection. Was wondering if anyone else has used it in this way and had any recommendations? We make both ports available over ser2net because we actually operate the buspirate in bpio2 binmode for the most part at least at this point in time. I think its related to the disk image loading and unloading once a connection is started. Its right when I try to connect to the device that things get a little weird and then it suddenly disconnects. I need to unplug and plug it back in for ser2net to recognize it again. I am on the latest firmware. Just trying to work out what could be going on here and hopefully find some stability with it…
I’ll be jumping into the firmware next and can see if I can hunt down exactly where it falls apart next, but figured it was worth asking to see if anyone else uses the buspirate in this way.
When the Bus Pirate first connects the internal disk is read/write. When you open the terminal the disk detaches and switches to read only mode. I’d guess it may be related to that.
Since you mentioned that these all have ethernet, have you considered using usbipd to redirect the entire USB device over ethernet, rather than a serial port?
I use usbipd to redirect the USB devices to WSL2 … but the same concept would seem possible. usbipd does require a client-side component, of course … but it might avoid the issue you refer to altogether.
@ian BPIO2 has been a game changer from a host tool side of things. I am writing some pio extensions, to use for our own internal tools, that may be of use to the community. They are some pretty big changes. I will be posting them to github after some cleanup next week. We needed to do some analysis between two devices at the same time and have uart access at the same time so some lightweight pio programs were called for.
Also unfortunately @henrygab we write networking software for embedded devices so typically the networking software is unreliable until after we are done integrating. Which leaves us with a hard serial requirement to poke at the device until we are done. I like the thinking though.
We do integrations with a lot of equipment, for scaling purposes, and because a lot of my engineering talent is scattered to the four winds we need to be able to access devices remotely and ser2net (Or some other serial to networking translator) is required. I am going to poke at the firmware and see what is actually causing ser2net to freak out. I am only correlating the usb mass storage device transition, and have not found true causation just yet. I just know the issue occurs right when that event happens. So I’ll dig around and see if I can come up with an exact cause.
It might be fairly easy to hack a firmware that never gives the host device read/write access (sticking with read-only access) to the built-in mass storage device. If that works, then longer-term, maybe forcing read-only host Mass-Storage Class device can be a configuration file option.
However, it would still need someone to actually go through the code, find how and where to modify, … just to enable testing. If you’re comfortable making code changes, I might be able to look later this week and point out the key variables / code flows in play … at least enough to likely enable testing…
