Usb tty usage on unrooted

[short trail]

Im guessing its not in the api yet, I didnt see it

Just got some tty lora modules; rq question about it, because I want to use in termux is there a easy way now, or are we still stuck with using a diffrent app, or writing a usb parser in termux?

If proot can parse, thats fine too; I just want to mess with them in python, instead of directly sending at commands to it.

[polar grotto]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[hot sluice]

What proot really is, is just a pseudo AKA fake root. Termux is just an ordinary Android app, and as such, has no special access to the USB controller.

[short trail]

I understand; but other apps can access it, and its able to be parsed from the usb passthrough given from the termux api; so is there a known way to use this easily?

I mean I can run a vm to parse the usb stuff

but thats stupid

[hot sluice]

It depends on if your device's ROM supports it or not.

[short trail]

Other apps can read it; its able to work over usb, I mean is there a way to get a serial connection out of that tho

easily

[hot sluice]

Did you read the EULA / ToS / whatever for the device and its official mobile app? There might be something that talks about not being allowed to decompile, use 3rd-party accessories to interact with it, or something.

[short trail]

I dont think there is an official mobile app for a usb uart adapter from pine64 (https://pine64.com/product/serial-console-woodpecker-edition/), nor the serial RYLR998 with datasheet published on their website for use in applications https://reyax.com/products/RYLR998

and even if there was; if I never installed, interacted with, or used the official app. Doing so would mean attempts to interact with the device is allowed. And I don't think those clauses are even legally enforceable if it was in there as long as it is not for personal gain, nor to the determent of the company, most can only remove your account.

anyway, this joke about this being in any applicable has gone on long enough; its not.

I just want to talk serial over termux, thats entirely legal, there is no official anything, and I just want to send AT commands automatically like I do on a computer

waiting for the "using this product is illegal" clause to be added to everything I interact with

[short trail]

This is why right to repare is important; it shouldnt be illegal to use my own purchased hardware for whatever I want; even if the hypothetical app says I cant, I own the hardware, and they cant stop me from decompiling the app and using that in my personal projects. That is only a factor in public information, or releases for non personal reasons

and thats only the code its self; I can still make a tool for it as long as I dont use anything from the hypothetical app

[short trail]

Can someone please help with this

[hot sluice]

First question:
Are you actually using a physical Android phone / tablet, or are you using a Chromebook / etc.?

[short trail]

Android phone

Github apk

Android 13

[upper portal]

@short trail the problem you're having is that linux-flavored programs expect to talk to serial devices (USB or otherwise) via /dev/tty*, which android doesn't give apps access to. any android app talking to a USB serial device is doing it via android's own APIs, which no linux-flavored program is going to be able to talk to. USB passthrough to a VM should work, as you said; reimplementing raw USB access into something that looks like a tty would work but sounds like a bad time; a proot cannot help.

[narrow path]

Hm... But pty should be compatible with tty. I'll try to open feature request in termux:api repo for this.

Oh, there is no java api for working with serial devices. Sad. But probably we could write some termux-usb + libusb based project which could spawn pty redirecting all input and output to serial usb device.

[short trail]

I was thinking of just doing that lol, seams not tooo bad. I was hoping this existed hense the question.

[upper portal]

think you might be underestimating it. you have to fork or reimplement the entirety of the kernel drivers for these things, plus whatever common kernel functionality they use, for each chipset you want to support.

might not be that much code but I will be very proud of you if you send a mergeable PR for this

[narrow path]

Probably I could implement something similar, but I do not have any usb serial devices for tests.

[short trail]

1. USB is a standardized protocal, so I dont think it would be for "each chipset you want to support"
2. I think usb parsers already exist in userspace (https://github.com/pyusb/pyusb) from a google search seams to work, but we would prob want a java one if we wanted a termux api for it
3. Not sure if I have the time; Right now got a whole bunch of tests and finals to study for, may look into it in a bit

If your device is not one of the above listed devices, compatible with the above models, you can try out the “generic” interface. This interface does not provide any type of control messages sent to the device, and does not support any kind of device flow control. All that is required of your device is that it has at least one bulk in endpoint, or one bulk out endpoint. - https://docs.kernel.org/usb/usb-serial.html

Looks like generic works for alomst everything; so would need to look at it

but if using somthing like https://github.com/pyusb/pyusb, adding somthing simplistic like usb parsing to fake uart should be easy

if we do that, would it be part of termux api? and if so, should it make a fake file like the ones generated by termux already, or should it just allow for specifying a location for the pty / fifo?

https://github.com/mik3y/usb-serial-for-android found this as a base, let me check license

[short trail]

Is termux api MIT compatable, and dose it use 3rd party libs, or are we going to just write a new lib for it;I think https://github.com/mik3y/usb-serial-for-android?tab=MIT-1-ov-file Being MIT should work, or if not can use used as a basis for termux-api's

[upper portal]

do you see how this specifically lists the hardware it supports

[short trail]

All we need for a generaly working one without all the extra cool features https://github.com/mik3y/usb-serial-for-android/blob/master/usbSerialForAndroid/src/main/java/com/hoho/android/usbserial/driver/CdcAcmSerialDriver.java

[upper portal]

USB is standardized; I don't think the way you implement a serial adapter over USB is

[short trail]

That is extra things like control flow that are not in the CDCAMC spec

[upper portal]

sure

that's the point

[short trail]

serial its self is tho, thats why you can just add https://github.com/mik3y/usb-serial-for-android/blob/master/usbSerialForAndroid/src/main/java/com/hoho/android/usbserial/driver/CdcAcmSerialDriver.java

and it will cover almost every device

just not the extra features

[upper portal]

if you think that's enough to be useful (and I don't know that it isn't), go for it

if you want an unmodified program to work, the only option is LD_PRELOAD shenanigans

[short trail]

Will see if I have time; do we know if we can just include https://github.com/mik3y/usb-serial-for-android/tree/master as MIT code into termux or should I rewrite it?

If I rewrite, can I use the MIT code (with credit) to the author in termux api? Its GPL v3 so it should be applicable

[short trail]

Most dont actualy scan for the port, they just use one in /dev/ttyUSB0 or similar

and in most cases thats specified on the cmdline

Do you know if termux api exposes a overlay fs on the /dev folder?

[upper portal]

^

[short trail]

can we just add a fake fifo / pty object there, or do we really need LD_PRELOAD?

I mean I can write a proxy for open and read.... but is there no day?

[upper portal]

it cannot

you really need LD_PRELOAD, I think

I don't think a fifo is expressive enough, but if you think it is, go for it

"fake pty object" I don't think is a real thing

you're referring to a device node there

[short trail]

I just mean a pty genearted by termux and as in faking it being a usbtty; sorry if I was not clear

https://man7.org/linux/man-pages/man7/pty.7.html

I mean socat can make one, and that works for almost any program, so I would assume that works https://unix.stackexchange.com/questions/493572/create-pty-and-connect-it-to-a-serial-port-dev-ttyusb0

[upper portal]

you should try that on termux

don't know if it'll work, this exceeds me

[short trail]

Last question because I am not really in on how termux dose some stuff; is there any overlay fs in /dev/ or are they just raw android /dev?

If it has a overaly fs it should be easy, if not, I need to do it in a diffrent folder, prob specified by a argument

[upper portal]

there is no overlay fs in dev

you need proot or other LD_PRELOAD shenanigans if you want things to see stuff in /dev/

[short trail]

Also, should we do this inside termuxapi, or should this just be a userprogram? beacuse it currently would work as a package requiring the usb forward function in termux api

[short trail]

Thanks for the help btw

[upper portal]

you'd have to modify something outside termux:api for this to be possible, for the reason you've been circling

I'm not totally sure it's useful for this to be in :api? seems like it's implementable within the app, depending on termux-usb

[short trail]

You mean the /dev/? For almost all programs this is just the default place, but not required.

I am kinda asking the same thing; should this be just a userspace package, I can make it easily in python based on a few projects?

[upper portal]

yeah, I don't think it can be done without a termux-app-side userspace program, because :api isn't positioned to lie to programs about their vfs. and I'm not seeing why you'd bother having anything at all in :api when the part you really need (the raw USB access) is already exposed to the termux app.

[short trail]

Should I fully implement it there, and just put a request in at the packaging system? I have never made a project like this before, nor really worked on termux, so honestly asking

[upper portal]

I would focus on a proof of concept first

much easier to talk about where it might live once you've got something working

[short trail]

I understand; just asking how you would suggest I do this if I ever get there, also so I can deside how to implement it (language, and if its compiled or not)

[upper portal]

(and faster to get something working if you're not immediately preparing for a full review / debate about where it should live)

I don't think that matters

[short trail]

nodejs 😎

[upper portal]

I guess it might be easier to get python reviews than js

[short trail]

Yeah looks like I may do this in python later then; it looks possiable on termuxapi with the returned fd from a api call; but most likely more versitial to do it this way

[upper portal]

maybe take a look at termux-usb

since it is already in the business of lying about the contents of the vfs to unmodified programs in the app

[short trail]

Just did; I just dont think thats how I will implement it, they seam to not actualy lie, termux dose that. Termux api just send a fd that termux can then access in that subprocess (being inherited from the upper process that calls to the termux api after termux api uses outputSocket.setFileDescriptorsForSend(fds); in sendFd(PrintWriter out, int fd) {)

[upper portal]

I'm missing something about the implementation but I think that's the point

if API is providing the raw USB access, and the lying must be done in the main app, what else would you actually want or need in :api?

[short trail]

Looks like pyserial plus reimplemented usb CDC parser would be fine, then just open a pty in python for that

https://github.com/ezramorris/PyVirtualSerialPorts is a good example it seams (for creating fake usb location) then just symlink from pty to specified path

https://allican.be/blog/2017/01/15/python-dummy-serial-port.html

[upper portal]

I am not particularly confident this line is going to work in android https://github.com/ezramorris/PyVirtualSerialPorts/blob/b624c5f91715ccd5b180c22fa130a0b5af48238f/virtualserialports.py#L90

I'd check that first

huh

welp. cheering for your success in this

[short trail]

Update!
Finished AP's, still got finals soon, but im done now

Lookin into it, I prob need to write this in c, libusb and the direct usb file descriptor seam to like being used directly, most wrapers for other langs abstract away the low level function it needs to not do scanning, and take the fd.

it seams not too hard, just gonna put some stuff here for my notes if anyone wants to take it too:
https://wiki.termux.com/wiki/Termux-usb
https://man7.org/linux/man-pages/man3/openpty.3.html
https://man7.org/linux/man-pages/man2/ioctl_tty.2.html -- need to figure this out, because these devices can take data at diffrent speeds, how can I find what speed the terminal reader is requesting? I think I can just get the CBAUD as discussed shortly here https://man7.org/linux/man-pages/man2/TCGETS.2const.html -- oh god https://stackoverflow.com/questions/4968529/how-can-i-set-the-baud-rate-to-307-200-on-linux -- may only support normal bauds then lol

mby https://libusb.readthedocs.io/en/latest/#libusb can be used, but its a lot smaller of a project, and is just a ctypes wraper for libusb

Posting an image from prob lying google AI bs

looks like we have to use ioctl, because termios only supports some baud rates????

linux is strage lol

I may have to support both, because I dont know if they convert properly, I think they do, but not sure lol

[hot sluice]

Don't trust AI-generated code.

Often times it will contain unnecessary code, or even malicious code.

Also, since when did C/C++ allow code to execute outside of a function?

[short trail]

Its not, its a separate idea its just writing out

[short trail]

Oh yeah I know, I hate it, just was including that because the documentation for usb is long af

[hot sluice]

AI might help but it is up to the user of the AI to verify everything that the AI generated is correct.