The licensing method being correct has nothing to do with ADB being enabled/disabled.
(Does anybody know where the 'scope's "Internal storage" is mounted in the file system?)
Has anyone tried the vendor.bin swap with the new firmware yet? Rigol didn't put additional checks in place for that, or did they?
The licensing method being correct has nothing to do with ADB being enabled/disabled.
So I do see Fungus' point: If Rigol wanted to close the "hack door", they could also have disabled ADB access. Anyway, they took a different approach.
Has anyone tried the vendor.bin swap with the new firmware yet? Rigol didn't put additional checks in place for that, or did they?
vendor.bin works perfectly.
How would they check it anyway? They'd have to add some hardware to the PCB to identify the model.
The start scripts in /rigol/shell/ are interesting.
Some lines of the shell scripting seem to be extraneous/useless.
But today I did set a screen dim timer so if you walk away for an hour or so the screen will dim to about -95% after the timer, and lowered the overall screen brightness from 255 to 200.
They also set a boot count tracker, does a "+1" to the counter on each boot and set into a property key. I fixed that, changed +1 to a +0
getprop, setprop, settings are all good to know commands.
Not sure why they don't use hwclock and set it to OS date.
Btw, it also starts ftpd, and has sshd running. Do I need ftp? I shut down ftpd. ssh can be handy for not wanting to use adbThanks, interesting information.
I also set automatic screen dimming, but through the Android settings. And I use FTP to take screenshots, so I probably won’t disable it
Regarding the download counter - very interesting, is it just for statistics or can it be used somehow? Well, for example, every 100th boot, request an update via OTA, or something similar.
And I found the time zone setting for Asia/Shanghai, I’ll try to replace it with my own zone and see what happens, maybe there will no longer be a need for a separate application to force installation when loading the correct time zone.
I was trying to do scpi commands from droid shell, but it's not easy to do, they use an encoding scheme in the web ui page via .js scripts. The actual encoded scpi command gets pushed direct to tcp port 9004 vis basic web socket. If you run the same command in web ui, the actual encoding sent changes. I want the unit to boot up and then go to STOP state with CH1 off.
I was trying to do scpi commands from droid shell, but it's not easy to do, they use an encoding scheme in the web ui page via .js scripts. The actual encoded scpi command gets pushed direct to tcp port 9004 vis basic web socket. If you run the same command in web ui, the actual encoding sent changes. I want the unit to boot up and then go to STOP state with CH1 off.Hmm, it seems that no coding is performed to send the command, the command text is sent as is. Here the answers come in a hex that needs to be converted to UTF8.
But I can’t help here - I’m very unfamiliar with Linux and web programming
The javascript used on the SCPI page does some form of coding beyond just a UTF8. Using Wireshark I can see the payload each time I send command via web ui, I will send :RUN numerous times and each payload is different, but 10bytes with 1st four the same for the :RUN command
The javascript used on the SCPI page does some form of coding beyond just a UTF8. Using Wireshark I can see the payload each time I send command via web ui, I will send :RUN numerous times and each payload is different, but 10bytes with 1st four the same for the :RUN commandStrange, I see on the page sending text directly from the command input field to the websocket: websocket.send(command.value);
No coding is done before this.
I even created a local page for sending SCPI commands and disabled external scripts - and it worksI checked it with a Java script trace.
There's 2 .js files loaded in.
open each .js, there's an obvious encoding scheme going on, on "input" data, which then comes back as command.value
They appear to encode the data prior to websocket.send()
in config.js you'll see the "function encode(input)" section
So... It seems that the issue of licenses and keys is not dealt with by the application itself, but by one of the binary libraries in it - libscope-auklet.so
I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.
Really? Is that how it works? The drivers are totally agnostic of any details of the specific SoC the OS is running on?Must be compiled against android sdk (OS), and the platform architecture.
disagrees about version of symbol module_layout
when insmodding, so Module.symvers has to be extracted from the kernel partition and used for the build.8188fu.ko 8189fs.ko 8723bs.ko 8723cs.ko 8822be.ko mlan.ko
I don't own any of these models, but if someone does and wants to give it a try:well, some sleuthing around, dug up some info.
@hpmaxim, when you plug in that nano wifi into Windows, what RT chipset is identified?
If the v2 with 8188EUS works (8188CU from v1 did not), then I would expect v3 v3.6 v3.8 (v3.x) to also work, they (v2 v3) should all have the RTL8188EUS wifi chipset. I say that because the current downloadable driver package for linux is for RTL8188E.
RT has variants of 8188E (EUS, ETV, etc). Feature diffs, etc. I suspect the drivers provided by TP-link are source code snipped to accomodate 8188EUS.
Side note, the driver package has lines in makefile for compiling against an android sdk, but those lines are commented out.
browse into /system/lib/modules
read the readme.txt file
then
modinfo /system/lib/modules/8188eu.ko
I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.
The kernel thenCode: [Select]disagrees about version of symbol module_layout
when insmodding, so Module.symvers has to be extracted from the kernel partition and used for the build.
I did this and here are the Wifi modules that fall out of an Advantech rk3399 BSP build:Code: [Select]8188fu.ko 8189fs.ko 8723bs.ko 8723bu.ko 8723cs.ko 8822be.ko mlan.ko
I don't own any of these models, but if someone does and wants to give it a try:
https://sven.killig.de/android/DHO/system/lib/modules/
I went to the page you listed, browser gave me the big red DANGER warning and blocked page.
I went to the page you listed, browser gave me the big red DANGER warning and blocked page.
Oh my, what did it say? Perhaps a homepage on a server behind DSL is too unusual these days...
insmod /system/lib/modules/8188eu.ko
I don't own any of these models
0b05:184c
0bda:b812
0bda:b82c
13b1:0043
7392:b822
7392:c822
and insmoddedNew update for the RT 8188eu v3.6 nano wifi
From my testing, it appears that when you attempt to insert the nano after the DHO is running, the 8188eu.ko KLM fails to load in.
If you boot with the nano in USB port, the system loads the 8188eu.ko KLM.
I fix this issue by doing an insmod in the "/rigol/shell/start_rigol_app.sh" script
I added the following just after the section (near top) where it loads the Motorcomm ETH KLMCode: [Select]insmod /system/lib/modules.8188eu.ko
Now I can insert the nano after boot time and there's no issue of the wifi coming up.
The system should just do a insmod of the ko KLM when it recoginizes that device being inserted into USB port, and then do a rmmod to pull the KLM out when the nano gets pulled from USB port.
That said, most will just leave the wifi nano in the USB port, so it's always there at boot. However, some like me have a USB hub in USB-A port, and the hub has ports that have on/off switches. I don't always have the nano wifi up and running, I turn it on when needed, etc.
Update: another odd thing. You have to insert the nano and manually turn on the wifi slider (android). Leave the slider as is (on position), now the wifi goes on/off in sync with presence of the nano. However, if you manually have the slider to off, the insertion of the nano will not turn on the wifi. That's some odd functionality.
Sorry for taking so long, here's what I got:
rk3399_rigol:/ # dmesg
rk3399_rigol:/ # lsusb
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # lsusb
Bus 003 Device 002: ID 0bda:8179
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[ 271.381320] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[ 271.500329] usb 3-1: New USB device found, idVendor=0bda, idProduct=8179
[ 271.500409] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 271.500424] usb 3-1: Product: 802.11n NIC
[ 271.500437] usb 3-1: Manufacturer: Realtek
[ 271.500461] usb 3-1: SerialNumber: 00E04C0001
[ 271.753363] SELinux: Unable to set superblock options before the security server is initialized
I then tried your insmod command (although you had a typ-o, should be /system/lib/modules/8188eu.ko), it now seems to be mostly working:
I booted several times in a row. First two worked great. Third time it still worked, but seemed a bit slower to start. I also tried unplugging and plugging it back in and this didn't seem to work. Fourth time, I plugged in the hub and keyboard along with the WiFi dongle and it didn't seem to work. Fifth and sixth times I went back to just WiFi, and it worked but was a bit slow to start. Then I unplugged and plugged back in, and that worked. Repeated a few times. All good. Then tried a 7th time with the hub, and it still worked.
So weird that mine is behaving so differently from other people's... Should I edit the file /rigol/shell/start_rigol_app.sh and add the insmod command in there? How do I edit it? vi?