SIMCom SIM7100E LTE modem

SIMCom SIM7100E is a recent LTE modem released by Simcom. It’s approximately $20 cheaper than Huawei LTE modem, and also it provides USB voice function, so it could be integrated with FreeSWITCH mod_gsmopen module (this needs development).

My set of udev rules and chat scripts is updated with SIM7100E information, and here’s a copy:

cat >/etc/udev/rules.d/99-wwan.rules <<'EOT'
# SIMCom SIM7100
SUBSYSTEM=="tty", ATTRS{idVendor}=="1e0e", ATTRS{idProduct}=="9001", SYMLINK+="ttyWWAN%E{ID_USB_INTERFACE_NUM}"
SUBSYSTEM=="net", ATTRS{idVendor}=="1e0e", ATTRS{idProduct}=="9001", NAME="lte0" 
EOT

cat >/etc/chatscripts/sunrise.SIM7100 <<'EOT'
ABORT BUSY
ABORT 'NO CARRIER'
ABORT ERROR
TIMEOUT 10
'' 'AT+CFUN=1'
OK 'AT+CMEE=0'
OK 'AT+CGDCONT=1,"IP","internet"'
OK '\dAT\$QCRMCALL=1,1'
OK
EOT

cat >/etc/chatscripts/gsm_off.SIM7100 <<'EOT'
ABORT ERROR
TIMEOUT 5
'' 'AT\$QCRMCALL=0,1'
OK AT+CFUN=0
OK
EOT

cat >/etc/network/interfaces.d/lte0 <<'EOT'
allow-hotplug lte0
iface lte0 inet dhcp
 pre-up /usr/sbin/chat -v -f /etc/chatscripts/sunrise.SIM7100 >/dev/ttyWWAN02 </dev/ttyWWAN02
 post-down /usr/sbin/chat -v -f /etc/chatscripts/gsm_off.SIM7100 >/dev/ttyWWAN02 </dev/ttyWWAN02
EOT

 

Advertisements

FriendlyELEC NanoPi NEO Plus2

NanoPi NEO Plus2 is a brand new board released by FriendlyELEC. It’s slightly bigger than the NEO2 board, and packed with much more cool stuff: 1GB RAM, Wifi+Bluetooth module, and 8GB eMMC chip. It has also two USB2.0 port connected to independent USB controllers.

The NanoPi NEO Plus2 Basic Kit accompanies the board with an acrylic enclosure, and the first orders are delivered with an UART USB adapter. They also listed an antenna, but I did not receive it in my kit. Anyway I have a better option, a flat self-adhesive antenna like this one.

The acrylic enclosure is about two times thicker than that for NEO boards, and it also has a hole for antenna mount. I added 8 pieces of M2.5 washers and 4 M3 pillars to the original design, to make it more long-lasting. The photo below has the UART adapter plugged in.

Armbian still needs some work to be done to support this new board. But the Ubuntu image that is available from FriendlyELEC is quite enough to demonstrate all the hardware capabilities. Unlike Armbian, it does not mount /tmp and /var/log as tmpfs, so the SD card may experience a faster wearing.

Installing vSphere Replication from Linux CLI

tested with VCSA 6.1 and vSphere replication 6.1.1. OVF Tool 4.2.0 is installed on a Debian Jessy machine.

ovftool --acceptAllEulas -ds=datastore1 \
-n=<VMname> --ipAllocationPolicy=fixedPolicy \
--prop:password='*******' \
--prop:ntpserver=******* \
--vService:installation=com.vmware.vim.vsm:extension_vservice \
vSphere_Replication_OVF10.ovf  vi://vcenter01.domain.com/DC1/host/Cluster1/

 

Acrylic enclosure for FriendlyElec NanoPi NEO2

The NanoPi NEO2 board by FriendlyElec has several options for an enclosure in their webshop. The 3D-printed plastic enclosure is of too poor quality, and it doesn’t fixate the heatsink properly on the CPU.

The acrylic case does not include washers, which makes the whole construct too fragile, as the screws can easily damage the plastic.  Also the M2.5 screws for fixing the heatsink are too short.

So, I added the following components to the design:

• M3*16mm  screws and M3 nuts (4 pieces each)
• M3 washers (24 pieces)

Also the following parts came with the acrylic case:

• M3*6mm screws (4 pieces)
• 6.3mm plastic spacers (4 pieces)
• 25mm female-female M3 spacers (4 pieces)
• 6mm male-female M3 spacers (4 pieces)

As a result, we get a sturdy case that is able to sustain some rough handling, like carrying it in a toolbox among other hardware.

(scratches on my phone camera made the pictures a bit too soft)

Two LTE modems with PC Engines APU3

PC Engines GmbH has recently released a new board, APU3. The difference from APU2 is that two mPCIe slots are suitable for 3G or LTE modems, whereas APU2 had only one such slot. This article explains how to utilize two HUAWEI ME909 LTE modems, and it’s applicable to other modems too.

One of the LTE modems has to occupy the slot which is otherwise usable for mSATA storage. So, the board has to use the SD card for booting, and Voyage Linux is designed for such setup. The scripts in this article are tested against Voyage Linux version: 0.11.0 (Build Date 20170122).

As with APU2, the Linux kernel assigns ttyUSB port numbers randomly, so two ME909 modems produce 10 ttyUSB devices with random numbers which change after a reboot.

The modems have identical serial numbers “0123456789ABCDEF”, and the only thing that allows distinguishing them reliably is the PCI slot number of the corresponding USB controller.

Luckily, APU3 board slots designed for LTE modems, J14 (mSATA/mPCIe 3), and J15 (mPCIE 2), are attached to different USB controllers. The third slot, J16 (mPCIE 1), shares the same USB controller with J15.

USB EHCI Controller at PCI device 00:12.0 is attached to J14, and the controller at 00:13.0 is attached to J15 and J16.

So, the udev rules require a small Shell script that translates DEVPATH variable into the PCI slot and function number, and the resulting string will persistently distinguish the devices attached to USB interfaces in J14 and J15:

cat >/etc/udev/devpath_to_pcislot <<'EOT'   
#!/bin/sh echo ${DEVPATH} | sed -r \
    -e 's,^\/[^\/]+\/[^\/]+\/[0-9af]{4}:[0-9af]{2}:,,' \
    -e 's,\/.+,,' -e 's,\.,,g' 
EOT 

cat >/etc/udev/rules.d/99-wwan.rules <<'EOT'
SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", PROGRAM="/etc/udev/devpath_to_pcislot" SYMLINK+="ttyWWAN%c{1}_%E{ID_USB_INTERFACE_NUM}"
SUBSYSTEM=="net", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", PROGRAM="/etc/udev/devpath_to_pcislot" NAME="lte%c{1}"
EOT

After rebooting, you can see “lte120” and “lte130” network interfaces, and devices suitable for configuring modems: “/dev/ttyWWAN120_02” and “/dev/ttyWWAN130_02”. There are few other TTY interfaces for various purposes, as explained in HUAWEI documentation.

cpio: cap_set_file error when installing httpd RPM inside an LXC container

My physical machine runs Debian Jessie, and it has several LXC containers (mostly Debian and Ubuntu). Now I needed to test some software under CentOS, and I bumped into the following error when installing Apache HTTP server:

Downloading packages:
httpd-2.4.6-45.el7.centos.4.x86_64.rpm                                                                        | 2.7 MB  00:00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : httpd-2.4.6-45.el7.centos.4.x86_64                                                                                1/1 
Error unpacking rpm package httpd-2.4.6-45.el7.centos.4.x86_64
error: unpacking of archive failed on file /usr/sbin/suexec;590112cd: cpio: cap_set_file
  Verifying  : httpd-2.4.6-45.el7.centos.4.x86_64                                                                                1/1 

Failed:
  httpd.x86_64 0:2.4.6-45.el7.centos.4

The thing is, that by default “/usr/share/lxc/config/centos.common.conf” defines the following capability drops:

lxc.cap.drop = mac_admin mac_override setfcap setpcap
lxc.cap.drop = sys_module sys_nice sys_pacct
lxc.cap.drop = sys_rawio sys_time

So, setfcap capability is required in order to install Apache. Use the following lines in your “/var/lib/lxc/NAME/config” to drop previously defined drops and set up a new list:

# flush all defined drops and define a new list
lxc.cap.drop =
lxc.cap.drop = mac_admin mac_override setpcap
lxc.cap.drop = sys_module sys_nice sys_pacct
lxc.cap.drop = sys_rawio sys_time

then restart the container, and “yum install httpd” should run as expected.

FriendlyElec NanoPi NEO2, a better sub-$20 Linux computer

NanoPi NEO2 by FriendlyElec is a new sub-$20  Linux microcomputer, built on Allwinner H5 SoC, providing a Gigabit Ethernet and USB 2.0 interface. Also additional interfaces are possible via expansion headers (needs some soldering work). The board is equipped with 512MB DDR3 RAM.

It is highly recommended to buy the heatsink alongside with the board. The CPU is heating up quite significantly, and it needs cooling. With “stress -c 4” CPU load test, “armbianmonitor -m” shows the core temperature rising up to 75C. The board sustains long-term load under such conditions. But with a fan, the core temperature drops below 40C, and the power consumption drops significantly too.

The plastic 3D-printed enclosure is of little use. First, it’s quite easy to break when you insert the board. Also it does not fixate the heatsink properly.

So, I ended up in using the original cardboard packaging as a base for the board, just to avoid extra touching of electronic circuits, and to fixate the USB power cable:

Armbian nightly image booted without problems. Up to now, I noticed the following minor problems with it:

1. it does not come up after reboot;
2. “cpufreq-info” complains about unknown driver.

Network traffic tests with tcpkali (debs, deb build scripts) demonstrated that the CPU is able to saturate the Gigabit Ethernet port with TCP traffic, reaching above 900Mbps throughput.

All in all, this board looks much more reliable than Orange Pi Zero: it can work for long hours with an  USB Wifi dongle, whereas OPI0 was hanging up after few minutes of work (using the same USB power cable and power source and the dongle). UPD: the board doesn’t actually hang up, but the WiFi interface stops transmitting packets for some reason. Needs further investigation.

UPD: I tried to flip the board with the hope for better heat dissipation (below), but it appeared to be much worse, and the peak temperature reached 85C:

Orange Pi Zero, a sub-$20 Linux computer

Orange Pi Zero with 512MB RAM, expansion board and black case is sold for sub-$20, including postal costs, and it is so far the cheapest Linux device you can buy.

Armbian project provides a dedicated image for this board. The nightly build is quite stable, and there’s also legacy kernel which works well.

The computer is equipped with a 100/10 Ethernet NIC, and the top throughput that I could achieve was about 90Mbps.

The on-board WiFi adapter is of very poor quality: regardless of the antenna attached, it gives about 6Mbps connection speed and excessive packet loss (up to 20% lost pings). It’s useless for any practical application, and it’s easier to disable it completely.

The two USB ports on the expansion board are not enabled by default in the legacy kernel. You need to add the following line to /boot/armbianEnv.txt file, and reboot the box:

overlays=usbhost2 usbhost3

In order to disable the onboard WiFi, comment the top line, and add another line in /etc/modprobe.d/xradio_wlan.conf:

#options xradio_wlan macaddr=DC:44:6D:1F:3C:14
blacklist xradio_wlan

Then, run the following commands to update the kernel boot parameters:

depmod -ae
update-initramfs -u

The onboard USB ports are not extremely fast: with an GigE or Wifi USB adapter, the maximum speed that I could achieve was about 40Mbps. But at least you get a stable and reliable connection.

The micro-USB OTG port is used for powering the device, and the board can freeze if the power consumption on USB ports is too big. For example, an external USB drive is very likely to knock the whole thing off. A WiFi dongle can freeze at bulk traffic loads. So, it’s advisable to use an external USB hub for attaching devices.

Network Manager is installed by default by Armbian, and that allows easy plug-and-play WiFi configuration, adding new SSID and passwords from “nmcli” command-line interface.

All in all, it’s still quite a pretty device in a small enclosure. It can be used as a low-cost or throw-away network agent or VPN gateway for remote access. Also it can act as a measurement agent for all kinds of network testing, especially if you need a massive deployment and price difference is important.

Building a remote office VPN with FortiGate firewalls

A customer has its own PI range of public IP addresses, and they way to use part of this range in a remote office and place some servers there. The remote office is connected via some third-party ISP. So, the VPN tunnel should route the customer’s addresses and provide full Internet access to the remote office. Both sides should use Fortinet’s FortiGate firewalls.

It is quite natural to use a policy-based VPN for the remote side: the policy would match “all” destination addresses, and send all Internet traffic to the IPSec tunnel. But the central site is a firewall on a stick, so both Internet and IPSec traffic are going through the same wan1 interface.

Professional support at a local Fortinet partner gave an idea that I could not derive from any documentation: policy-based VPN and interface-based VPN can work together within the same IPSec tunnel.

So, the remote site is configured with policy-based VPN. The tunnel’s Phase 2 selector is 0.0.0.0/0.0.0.0 for both source and destination. The VPN policy matches all traffic from the local LAN addresses to “all”.

The central site is configured as interface-based VPN. The tunnel is pointing to a dynamic DNS endpoint, and the Phase 2 selector is also 0.0.0.0/0.0.0.0 (as it must match the selector on the other side of the tunnel). Then, it’s accomplished with in- and outbound policies that “ACCEPT” all traffic from and to the remote LAN, and a static route that sends all traffic toward remote LAN through the tunnel.

Running Ubuntu on Chuwi Hi10 Pro tablet

Chuwi Hi10 Pro (CW1529) tablet is sold for about $200 with an attachable keyboard, which makes it a potential candidate to replace my old Acer Aspire One and run Linux on it. It’s also equipped with a high-quality 10″, 1920×1200 IPS screen.

The tablet is based on Intel Atom x5-Z8350 Cherry Trail CPU, which requires a fresh Linux kernel. So I started with pre-release of Lubuntu 17.04 (Zesty Zapus).

So far, out of the box:

• screen is oriented vertically, which makes it difficult to operate with the keyboard.
• Touchscreen, sound, Bluetooth, and Wifi are not visible to the kernel.

Solving the screen orientation:

In /etc/default/grub, edit the following setting:

GRUB_CMDLINE_LINUX="fbcon=rotate:1"

Then, add the following to make lightdm rotate the screen automatically:

cat >/etc/lightdm/chuwi_hi10_screen_orientation.sh <<'EOT'  #!/bin/sh xrandr --orientation right  EOT  cat >/etc/lightdm/lightdm.conf.d/50_chuwi_hi10.conf <<'EOT'
[SeatDefaults]
display-setup-script=/etc/lightdm/chuwi_hi10_screen_orientation.sh
EOT
# this will apply the setting immediately:
systemctl restart lightdm

There is one bug though: for some reason, the display manager still thinks it’s the old resolution, e.g. 1920 on vertical resolution,  so all fonts look much smaller than they are, and window closing buttons are hardly visible. If I start lightdm without my customization and login, and then run “xrandr –orientation right”, all fonts and window controls are of normal size.

With Hopkins Kong’s kernel patches, Wifi adapter is now working. Touchscreen is responding, but acts randomly.