EtherUSB with CDC-ECM support

I was browsing the “More Info” link in the Bounties page and noticed that today a beta EtherUSB was available for community testing.

What’s the point if you hide it there?

What’s the point if you hide it there?

Perhaps they want to more widely test it, outside a group of alpha/beta testers who may know what they are doing or not, but don’t want to make it generally available in case issues/bugs cause issues with users systems?

This way the ones who want to try it can and the more cautious ones can leave to a later date.

Any way tested on my two Pinebooks, one earlier version and a Pro, and it works well with my U Green USB3/1000Mbps USB to Ethernet adaptor that didn’t work with the standard EtherUSB module.

@Andre many thanks for pointing out the beta EtherUSB. It works well on my Pinebook Pro with a USB Modem adaptor, so great to have an internet onnection.

Perhaps they want to more widely test it, outside a group of alpha/beta testers who may know what they are doing or not, but don’t want to make it generally available in case issues/bugs cause issues with users systems?

And the reason they don’t announce it in the news section or at least in the forum is…making sure to not get it tested properly?

Much the same as with the RCs for 5.30. And putting the rather important “HardDisc4” into a download area called “Miscellaneous”, but of course not at the top – after “Ancillary downloads” and the all-important “Backdrops”. And hiding the DDE behind a link to “Buy RISC OS Open merchandise”.

My guess is that the enhancements Thomas Milius implemented into EtherUSB (main driver for him was that with changes in mobile networks the need to support LTE came up) are in this new version from ROOL (Thomas certainly did pass on his stuff to ROOL).

For those rather wanting to wait for the final release feel free use Thomas’ version that is hosted on https://gag.de/software/etherusb.html since quite a few users use it with no issues.

Note: The beta EtherUSB from ROOL is not the same like Thomas offer.
No user report an issue to Thomas but ROOL remove two.
I’m not at home since friday. I think I can try tomorrow.

No user report an issue to Thomas but ROOL remove two.

I’m not sure what you mean here?

This looks like the code that we identified the other month, with an additional commit made in the past couple of days. Are you saying that this commit has broken things?

For those rather wanting to wait for the final release feel free use Thomas’ version

Looking at the merge request logs, the ROOL version is the same as Thomas’s one, with some additional improvements.

Are you saying that this commit has broken things?

No. That was a swipe at ROOL…

… with some additional improvements.

… in Thomas code?

It looks like Thomas is going through the painful process of tarting his code up to suit ROOL.

I’d be interested to see the usb descriptors for a CDC Ethernet device. If anyone who has one could send me the descriptors using USBDescriptors from my website and send it to the contact on this page I’d appreciate it – thanks.

USB CDC Ethernet has meanwhile 3 subclasses:
My EtherUSB version only supports the CDC ECM variant.
The second variant seems to be very unpopular. I never got an according descriptor. I think the reason for this was that M$ never supported it but only CDC ECM and now the third variant and of course its own RNDIS class (used by LINUX devices like smartphones running Android).
Third variant is quite new even exisiting since some years.

The problem is that most devices are also supplied with a proprietary interface and this is in general the default. CDC ECM must be activated by changing the configuration of the device. Huawei sticks are a class of its own. My one toggles between a regular USB memory stick containing the Windows driver and CDC ECM. Raiks stick must be switched by a SCSI sequence using my !USBDevSwp program which is the RISC OS pendant to the LINUX usb_modeswitch program.

So are you autodetecting devices with CDC in another configuration? In SerialUSB I get cdc devices in the normal configuration so those devices work without altering SerialUSB. It’s something to watch out for though. I may have to check other configurations if I find a device that has one.

That was a swipe at ROOL…

Ah, thanks for clarifying… Anything specific, or just a general “how dare they look after the sources for RISC OS for us, and make sure that it all still builds after each code submission”?

Anything specific, …

Interpersonal interaction, dealing with programmers… you should try to keep the few and not scare them away with misplaced arrogance.

Oh, like dealing with degenerates that use tabs instead of spaces! ;)

degenerates that use tabs instead of spaces!

+1E99

Interpersonal interaction, dealing with programmers… you should try to keep the few and not scare them away with misplaced arrogance.

Hmm. Can you be more specific, as that’s an “interesting” allegation. There’s always two sides to any story: this wouldn’t be another of the “throwing some code over the fence and running away” episodes that ROOL have spoken publicly about, by any chance?

Can you be more specific, as that’s an “interesting” allegation.

I could but I don’t want to.

@Steve
I drop you an email.

I’d be interested to see the usb descriptors for a CDC Ethernet device

Hi Colin, I sent the descriptors when using the new ROOL USB module to the address on your webpage and the email bounced, so is there an alternative address?

Also it seems , as is the case with Thomas’s module, that there is an issue with the PBPro in that ShareFs doesn’t work.

This may be to do with various issues that surfaced when the new sound enabled ROM came out or to do with the XHCI module working of the USB3 port on the the PBPro, as that port is required by my device, rather than the USB2 type one, for the device to actually work even though it works on both the original PineBooks USB2 ports.

Thanks for trying. Raik sent me lots of stuff including PBPro so there’s no need to send more.

that there is an issue with the PBPro in that ShareFs doesn’t work.

Is that using ROOLs Ethernet stack or the new one from RComp?

This may be to do with various issues that surfaced when the new sound enabled ROM came out or to do with the XHCI module working of the USB3 port on the the PBPro.

The port that uses the XHCI module will not be affected by any changes to the USB Stack for isochronous transfers. I’ve had problems with XHCI on a pi. I run my pi headless and if I plug my powered hub (powered or unpowered) into usb ports it doesn’t start up. If I plug in a monitor to see what is happening it will start up. Unplug the monitor it fails to startup. It crashes a pi when a pico changes from a serial device to a mass storage device. Neither of these are a problem if I use the DWCDriver at the power port. Linux has no problems being headless and the hub plugged into the usb ports. The crash may be a reentrancy problem with the xhci driver judging by the code.

Looking at the XHCI driver it looks like a more modern – I use the term loosely – driver shoehorned into an older stack. I think we are in desperate need of the latest USB stack from netbsd. Had a look myself, Theres a lot of work before you get feedback that you are heading in the right direction. At least the Norcroft compiler now compiles most of the stuff except empty arrays in structures. Netbsd uses array⁰ norcroft array[].

There is a iusse in conjunction with ShareFS. I detected it several months ago at my machines too. ROOL has been informed about this. However I think it has nothing to do with EtherUSB directly. During my tests of my version of EtherUSB I detected silly unlogical errors “share disc0 not available” or something like this or more worse machine crashes. I began to search. However it was silly. Sometimes every thing worked fine and next day there were this faults again and again. After a while I detected that the errors only occurred some minutes after I unplugged my USB network adapters.

ROOL was the oppinion and I am thinking that they are right in this point that it is an old bug inside Freeway. I assume that at the time when Freeway was designed related interfaces were inbuild into computers. Of course you were able to add or remove them like Elesars new Econet card for RiscPCs. But you always better switch off the machine before doing so.

So my assumption is that Freeway simply has no handler for removing an interface and keeps an according structure internally. Of course with USB you can simply unplug the adapter. Freeway keeps trying to access the meanwhile invalid structure and this is causing the trouble.

I assume that this will happen with any other hotplugable network adapter too but I am not aware of any other ones. Perhaps this is not entirely correct. If thinking some years backward I won’t exclude that I faced this already in conjunction with COMCentre, UMTS and PPP but I am not sure.

Thanks Colin and Thomas for your thoughts on the matter.

Is that using ROOLs Ethernet stack or the new one from RComp?

Happens with both stacks.

Looking at the XHCI driver it looks like a more modern – I use the term loosely – driver shoehorned into an older stack.

Hopefully now that someone has quickly taken up the mantle as the second developer for the USB bounty then this will get resolved.

A new beta test version is available.

Any link?

https://www.riscosopen.org/binaries/test_EtherUSB_05-Dec-2023.zip

Any link?

Yeh, I am sure ROOL will tell you “But how can you not find it? it’s location is obvious.”