Orange Pi 2G-IOT: minefield map

Some time ago, I was offered to work a little with a single-board PC Orange Pi 2G-IOT (built-in 2G and the price looks very attractive). After reading a post about the Orange Paradise , I thought that I would repeat this path without difficulty, especially since with Linux I am on the “you” (or rather, I thought about three weeks ago) and already had experience with Raspberry Pi 2 B +. In practice, this path turned out to be much longer. There was a feeling that our Chinese friends intentionally created difficulties (and sometimes with special cynicism). If you want to save money and buy this board, then first read this post and think again.

If possible, I will try to restrain emotions or at least translate them into humor.
So, here I get into the hands of the board and the SD card of the tenth class. Go.

Everything written below refers to the Orange Pi 2G-IOT model, but in the Telegram chat (look for “Orange Pi and not only”) they say that the 2G, 3G and 4G models behave the same way (equally bad). The written does NOT apply, for example, to the Orange Pi PC and Orange Pi One, which, according to reviews, behave stably.

Mina No. 1 (training): downloading the OS image

It would seem that could be easier? We go to the manufacturer’s website and download. However, all links lead to mega.nz, which collects it directly in the browser. My cheap laptop with 4 GB of RAM did not pull such a task and the tab fell. One could use a proprietary program for downloading from Mega, but it did not inspire confidence in me (especially since some people write on the Internet that the program is recognized by antiviruses as malware). Solution options: download from an unofficial site (for example, here ), deploy a virtual machine and put in it a client for downloading from Mega, ask someone with a more modern PC to download the image.

Mina No. 2: Internet access via modem

Following verbatim the configuration of wvdial and pppd on the Internet, I suddenly found out that ping requests were passing fine, but regular TCP packets weren’t in any way:

orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32
curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32
curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32
curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface wlan0 195.201.201.32
46.0.208.54
orangepi@OrangePi:~$ ping 195.201.201.32 -I ppp0
PING 195.201.201.32 (195.201.201.32) from 10.33.64.21 ppp0: 56(84) bytes of data.
64 bytes from 195.201.201.32: icmp_seq=1 ttl=52 time=664 ms
64 bytes from 195.201.201.32: icmp_seq=2 ttl=52 time=240 ms
64 bytes from 195.201.201.32: icmp_seq=3 ttl=52 time=234 ms
64 bytes from 195.201.201.32: icmp_seq=4 ttl=52 time=246 ms
64 bytes from 195.201.201.32: icmp_seq=5 ttl=52 time=241 ms
64 bytes from 195.201.201.32: icmp_seq=6 ttl=52 time=237 ms
^C
--- 195.201.201.32 ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 6032ms
rtt min/avg/max/mdev = 234.634/310.971/664.998/158.370 ms
orangepi@OrangePi:~$

The solution prompted edtun : https://www.linux.org.ru/forum/admin/12135523 , although I admit that it could have been somehow simpler.

Immediately alerted that the IMEI modem is packed with zeros. Fortunately, the red-white telecom operator does not pay attention to this. (By the way, the built-in WiFi similarly does not have a MAC address: it is randomly generated with every jerking of the power supply.)

Mina No. 3: USB port

We stick a WiFi whistle in the USB connector and ... Nothing happens. lsusb displayed an empty USB port. A little digging showed that the board really only has one USB. And by default, it is connected to the microUSB port. To switch it to a regular USB HOST, you need to switch the jumpers on the board, which are located next to the jumper to select the boot. Their description is on w3bsit3-dns.com: Solution: switch jumpers to position: 1234 down, 5678 up. Only then did I find a small mention of this nuance in the Orange Pi manual.

Mina No. 4: Drivers

Now the device is detected in the system, lsusb displays the manufacturer and product code, but the wireless network interface is not detected in the system. Because the developers did not deliver drivers for WiFi adapters on an orange. And none at all. There is a driver only for built-in WiFi, no more and no less. And what do we do when we do not have a driver for our hardware? That's right, let's collect them from the source code !

Mine # 5: Preparing to Build

In correspondence, bad__day suggested assembling directly on Orange Pi. Maybe this is possible, but I failed.

For Orange Pi, the developers made a special Orange Pi Build System, with the help of which, in theory, to assemble the kernel or modules, it is enough to simply follow the instructions on the screen. Detailed instructions are given in the manual starting on page 61. It would seem that just follow, and everything will be fine, but no.

Firstly, in order not to manually edit all the dependencies on my computer (I regularly update software, this is great, but not this time), I deployed a virtual machine with Ubuntu 16.04 and carried out all the actions there. Secondly, an error crept in the scripts somewhere, and the Build System did not put a toolchain for cross-platform compilation. This is solved such a crutch:

1. Manually apt-get'om put the toolchain for cross-compilation for ARM.
2. Making symlinks:

   mkdir $HOME/OrangePiRDA/toolchain/bin
   ln -s $(which arm-linux-gnueabi-ld) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-ld
   ln -s $(which arm-linux-gnueabi-gcc-4.9) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-gcc
   ln -s $(which arm-linux-gnueabi-g++-4.9) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-g++
   ln -s $(which arm-linux-gnueabi-ar) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-ar
   ln -s $(which arm-linux-gnueabi-nm) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-nm
   ln -s $(which arm-linux-gnueabi-objcopy) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-objcopy
   ln -s $(which arm-linux-gnueabi-size) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-size

   Please note: the compiler is taken version 4.9, nothing will be collected on versions above.
3. Open OrangePiRDA / scripts / Prepare_toolchain.sh and just in case, comment on lines that mention the toolchain.

In fact, all these scripts just call apt-get install -y ... and make. The script does not offer the user to change the configuration in any way (or didn’t I find it?).

But after all, nothing prevents us from calling ourselves

make menuconfig

and mark the necessary drivers. We do this and collect again (now only modules are possible) and ...

Mine # 6 (with a screwed-on IR motion sensor and a spare detonator): Driver assembly

... And then the script kindly began to ask questions about how to configure the kernel. He called up the old-fashioned kernel configurator, but why ?! What's wrong?

It turned out that the Makefile is written to check the TIME (!!!) changes to the config!



The comment reads literally "someone was digging." (In the screenshot, the already modified Makefile, I prescribed menuconfig.) I tried calling make oldconfig, I didn’t notice that this changed anything somewhere. Okay, now after the menuconfig is called during the assembly, it's not scary. I call the assembly again, the assembly notices that “someone was digging into the config”, calls menuconfig, I exit and wait for the completion. Now imagine my surprise when I did not find the driver I selected.


Well, we climb to understand. It turns out that make creates the modules.order file, which describes all the modules that will be compiled. And even after all the configuration changes and its saving, this file is filled with the same set. I did not come up with anything better than manually adding lines to it (my whistle is assembled on the RTL8192CU chipset):

kernel/driver/net/wireless/rtlwifi.ko
kernel/driver/net/wireless/rtlwifi/rtl8192cu.ko

All references to this file in the Makefile were replaced by modules.order.fake. I start the assembly. This time, the assembly went, but broke off, since there is no similar file in the rtlwifi source code folder. I renamed the modules.order.fake files to modules.order in this folder and subfolders, and this was my last adventure in building the driver. After that, the system showed me menuconfig two more times, as if asking me “do you really want this?”, But nevertheless collected three more treasured .ko files, which wound up as expected.

Mina No. 7: Joint work of an external WiFi and a modem

Having played a little with airodump and making sure that the device can at least catch packets in monitor mode, I decided to check the modem again. Doing

sudo wvdial

And the LED on the external WiFi adapter goes out, and SSH falls off. Then I read in the logs that the adapter was disconnected. The first thought is a nutrition problem. Until that moment, I used my charger for 1.5 Amperes, and the manufacturer recommends as many as 3 (so much? She doesn’t even eat one Ampere ). At hand was a 2-amp charger, which for years regularly fed the Raspberry Pi.

At the moment, I have not found any stable solution to this problem. Here are some solution attempts:

• With a 80% probability, you can disable external WiFi using:
  
  

  chmod 777 /sys/bus/usb/drivers/usb/unbind
  echo 1-1 > /sys/bus/usb/drivers/usb/unbind

  
  and then run wvdial, which will establish a connection with 1-3 attempts and you can go online. In 20% of all kinds of hangs and glitches.
• Once, by chance, it turned out that wvdial was killed, but pppd remained working (how could it be?), After which external WiFi rose (see above, we write bind instead of unbind) and there was a connection through the modem. It was not possible to reproduce the situation.
• It turned out that without rebuilding the kernel, you can turn off the power to USB using such a utility with the command
  
  

  ./hub-ctrl -h 0 -P 1 -p 0

  
  and turn on the power

  ./hub-ctrl -h 0 -P 1 -p 1

  On 2G-IOT, the behavior is unpredictable: a power outage can be either for one second, or before a reboot. In some phases of the moon, an attempt to return power causes the board to freeze.
• Switch the jumpers to OTG (1234 up, 5678 down), feed power to the legs of GPIO 2 and 6 (ringing, they are directly connected to microUSB power)
  
  
  Pinout

  
  
  
  Connect the WiFi adapter via the USB-OTG adapter from the smartphone. The system does not see the USB device at all. Perhaps you need to persistently play with jumpers.
  

Not tested, but it may work (plans to try all of these options):

• Another WiFi adapter.
• Very stable power supply with a maximum current of 3 Amps.
• Extra power to USB feet.
• Gasoline and matches.

In general, the task looks like pulling a triangular blanket over a quadrangular orange.

That's all for now.



UPD: Today they brought me a power supply with a 5V 3A output. With it, it was possible to simultaneously launch both the modem and the USB WiFi adapter. The modem spills errors, stops responding, but on average it connects from the third attempt. After that, you can use USB WiFi.

Summarizing.

The single-board Orange Pi 2G-IOT is very raw and almost not supported by the manufacturer. Even on simple things, where it seems that nothing portends trouble, something may go wrong. If you need to use a device with Internet access via a mobile network and you are not sure that you can cope with Orange Pi, then it is better to pay extra and take something more reliable and debugged. Save time and nerves.