TXLAB

Digital Ocean is offering a private LAN for internal communication between the VMs, and they claim it’s isolated from other customers. You get some random addresses within 10.133.0.0/16 (or maybe some other range), and they can talk to each other on dedicated virtual NICs.

But that’s it. You cannot run OSPF because multicast packets are not let through. Even if you manage configuring direct neighbors in OSPF, it renders useless because the private LAN does not allow packets with destination IP addresses outside of the LAN range. So, any kind of routing with next hop in the private LAN would not work.

Too bad guys, very disappointed. So, we need to resort to Tinc VPN for internal routing, and this private LAN doesn’t make any sense.

A Linux device, such as PC Engines APU, can be equipped with an LTE modem, but sometimes it’s desirable to use the mobile connection only if the wired connection is unavailable.

The following scenario is for Debian 9 on an APU box, but it’s also applicable to any other Linux device.

The DHCP client is tweaked to ignore the DNS server addresses that are coming with  DCHP offer. Otherwise, the LTE provider may provide DNS addresses that are not usable via the ethernet WAN link.

The “ifmetric” package allows setting metrics in interface definitions in Debian. This way we can have two default routes with a preferred metric over LAN interface. The default route with lower metric is chosen for outbound traffic.

The watchdog process checks availability of a well-known public IP address over each of the uplinks, and shuts down and brings up again the corresponding interface. It only protects from next-hop failures. If you want to protect from failures in the whole WAN service, you need to increase the Ethernet port metric if it fails, and then start checking the connectivity, and lower the metric when it’s stable again.

Also the second NIC on the box is configured to provide DHCP address and to NAT all outbound traffic.

Detailed installation instructions are presented here: https://gist.github.com/ssinyagin/1afad07f8c2f58d9d5cc58b2ddbba0a7

 

Ubiquiti EdgeRouter X is a tiny and cheap (around $50) router with a decent amount of memory: 256MB RAM and 256MB flash. The router offers 5 GigE copper ports, and there’s also a model with an additional SFP port. The device is produced since 2014, and it’s still up to date and a good value for money.

On hardware level, the device consists of a Gigabit Ethernet switch, with one GigE port attached to the MIPS CPU and used as a 802.1q trunk. Also inside the enclosure, serial console port is available for easy debugging or manipulating the boot loader.

The router comes with stock Ubuquiti software which is based on Debian Wheezy, so many files are from 2013-2014. OpenVPN package is pre-installed, but only version 2.3 is available. The software offers a nice GUI and SSH access.

OpenWRT provides excellent support for this hardware. The router is able to perform IP routing at more than 400Mbps (I haven’t tested it with back-to-back connection, so I don’t know the limit).

Also with OpenVPN 2.4 that is available in up-to-date OpenWRT packages, the box performs at up to 20Mbps with 256-bit AES encryption, and at about 55Mbps with encryption and authentication disabled.

In default OpenWRT configuration, the switch port 0 is dedicated to WAN link, and ports 1-4 are used as a LAN bridge. The WAN link acts as a DHCP client, and LAN is configured with DHCP service in 192.168.1.0/24 range. The command-line configuration utilities are quite straightforward, and there’s a Web UI as well.

Here’s a new repository for OpenVPN deployment scenarios and example configurations:

https://github.com/txlab/ovpn-scripts

At the moment it lists two scenarios with configuration generation scripts:

1. routed VPN for remote management
2. bridged VPN for anti-censorship isolation of a home LAN

 

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

 

Filed under: Networking Tagged: 3G, GSM, linux, lte, pcengines

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.

Filed under: Hardware Tagged: arm, friendlyelec, linux

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/

 

Filed under: Networking Tagged: vmware

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 (4 pieces)
• 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)

Filed under: Networking Tagged: arm, friendlyelec, linux

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.

Filed under: Networking Tagged: 3G, linux, lte, pcengines

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.

Filed under: Networking Tagged: debian, hosting, linux

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).

 

Filed under: Networking Tagged: arm, iot, linux, networking

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.

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.

Filed under: Networking Tagged: arm, linux, networking, wifi

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.

Filed under: Networking Tagged: ipsec

Chuwi Hi10 Protablet 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 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 lightd

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.

Windows recognizes the WiFi hardware as “Realtek RTL8723BS Wireless LAN 802.11n SDIO Network Adapter”, so I need to figure out how to make it work in Linux. This fix does not work with kernel 4.10.0-11 (bug is already filed: https://github.com/hadess/rtl8723bs/issues/119)

Filed under: Networking

Here’s a sequence of commands in an ssh session to an ESXi host that creates a VM backup without interrupting its work. Of course it’s only a snapshot of the disk, so there may be corrupted files as a result. vmkfstools command requires full file path for the source and destination VMDK files.

# This lists all virtual machines and their IDs. # Further in this example, our VM is number 18 vim-cmd vmsvc/getallvms cd /vmfs/volumes/datastore1/VMNAME vim-cmd vmsvc/snapshot.create 18 mybackup mkdir /vmfs/volumes/nas1/backup/VMNAME vmkfstools -i VMNAME.vmdk /vmfs/volumes/nas1/backup/VMNAME/VMNAME.vmdk cp VMNAME.vmx /vmfs/volumes/nas1/backup/VMNAME/ vim-cmd vmsvc/snapshot.removeall 18
Filed under: Networking Tagged: vmware

In this github repo, I put together my knowledge about WWAN cards setup, alongside with all initialization scripts.

Filed under: Networking Tagged: 3G, GSM, linux, pcengines, UMTS

Huawei ME909s-120 is the newest modem of Huawei LTE/UMTS family, and it is sold for around $70 at TechShip.se and at Aliexpress.

The modem is immediately recognized as CDC Ethernet device in Debian 8 kernel, and is visible as usb0 interface. In the scripts below, the ttyUSBx serial ports are aliased to ttyWWANxx, and usb0 is renamed to lte0, in order to avoid any naming conflicts with other devices, and also to avoid possible name changes  due to a kernel upgrade.

cat >/etc/udev/rules.d/99-huawei-wwan.rules <<'EOT' SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", SYMLINK+="ttyWWAN%E{ID_USB_INTERFACE_NUM}" SUBSYSTEM=="net", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", NAME="lte0" EOT cat >/etc/chatscripts/sunrise.HUAWEI <<'EOT' ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR TIMEOUT 10 '' ATZ OK 'AT+CFUN=1' OK 'AT+CMEE=1' OK 'AT\^NDISDUP=1,1,"internet"' OK EOT cat >/etc/chatscripts/gsm_off.HUAWEI <<'EOT' ABORT ERROR TIMEOUT 5 '' 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.HUAWEI >/dev/ttyWWAN02 </dev/ttyWWAN02     post-down /usr/sbin/chat -v -f /etc/chatscripts/gsm_off.HUAWEI >/dev/ttyWWAN02 </dev/ttyWWAN02 EOT
Filed under: Networking Tagged: 3G, GSM, pcengines

Sometimes there’s a need to reset a GSM module on a Yeastar GSM gateway. For example, SIM cards of one of our providers get into faulty state every few weeks, and only a reset helps.

The GSM module can either be rebooted via Web GUI, or from the Asterisk console. But the Asterisk console can only work on the same host where the asterisk daemon runs, so you need to make an SSH connection into the Yeastar box to do that. Also it’s impossible to save a public SSH key in a Yeastar box, so only password authentication works.

Ansible is a powerful toolset for managing remote hosts, and it appears to be perfectly suitable for managing the GSM gateways.

Ansible 2.x is available for Debian 8 from jessie-backports repository. There are some important differences from version 1.7 that is installed from default repositories, and in particular, ansible_host and ansible_port variables.

After installing Ansible, uncomment host_key_checking = False in /etc/ansible/ansible.cfg , so that the SSH client stops verifying the remote host SSH signatures. Otherwise the host signatures should be listed in your known_hosts file.

The following lines in /etc/ansible/hosts list your GSM gateways:

[yeastar] gsm01 ansible_host=192.168.99.66 ansible_ssh_pass=kljckhjeswvdfesv gsm02 ansible_host=192.168.99.67 ansible_ssh_pass=dmnckjfvrever gsm03 ansible_host=192.168.99.68 ansible_ssh_pass=dcmnkljdfhfe [yeastar:vars] ansible_user=root ansible_port=8022

If you use the same root password on all devices, the password variable can be moved to the group variables.

Ansible uses SFTP for ad-hoc commands, and SFTP is not available on Yestar gateways. But the raw module works just fine, and resetting a GSM module can now be done with a simple command from your management server:

ansible gsm03 -m raw -a '/bin/asterisk -rx "gsm power reset 2"'

 

Filed under: Networking Tagged: GSM, linux, pbx, sip, voip

Our good old Samsung Galaxy Tab 3 7.0 Kids Tablet has finally died after over 3 years of everyday heavy use, so I needed a new solution. So far, here is the best combination that I could find:

This silicon case for Samsung Galaxy TAB A 7″ SM-T280 is a solid and protective piece, and it allows the kids hold the tablet with their little hands without slipping off. It also works as a stand, so it’s very convenient for watching videos.

The Samsung Galaxy Tab A (7″, 8GB, Metallic Black) fits perfectly into the protective case. The tablet is coming with preinstalled “Kids Mode” application, which is pretty neat, but very restrictive: the kid can watch only the videos on SD card that you mark as safe, and YouTube is not available. You can install kid-safe YouTube wrappers from the Play market, but it’s a bit too much hassle to my taste.

So, instead of the Samsung Kids Mode, I installed Kids Place by kiddoware. With a little payment, you get a good child protection mode, and you can enable YouTube directly on the child screen. The payment is also transferable to other devices under your account.

Also, this portable Bluetooth speaker works as a stand for a tablet, and it produces a much better sound than the tablet’s own speaker. Unfortunately the silicon case is too thick for this stand, but it’s a minor issue, and the speaker can easily be placed behind the tablet.

 

Filed under: Hardware Tagged: kids

In my particular case, there are two physical USB devices that are represented as TTY devices in the kernel: a Gobi2000 3G modem, and a 4-port USB-to-serial adapter. The modem is presented by two ttyUSB devices, and the USB-to-serial adapter adds four more. At the machine boot, these devices get assigned random numbers ttyUSB0 to ttyUSB5, and this assignment changes between reboots.

So, this needs udev rules which would assign symlinks to these devices, and the symlinks should remain valid between the reboots.

As there’s only one physical device of each type attached to the host, we can base our udev rules on idVendor and idProduct attributes. If you need to distinguish between multiple physical devices of the same type, you have to match serial numbers in your udev rules.

The next task is to distinguish between virtual TTY devices within the same physical device. The easiest way to perform this is to extract all available attributes for two devices and look at the difference between them:

udevadm info -a -n /dev/ttyUSB4 >x4 udevadm info -a -n /dev/ttyUSB5 >x5 diff -u x4 x5

The challenge with the 3G modem is that the two TTY devices are only differing in bInterfaceNumber attribute:

-    ATTRS{bInterfaceNumber}=="01" +    ATTRS{bInterfaceNumber}=="02"

This attribute is derived during the device initialization and is not available for udev matching rules. Instead, there is environment variable ID_USB_INTERFACE_NUM which represents these values. The following commands help in identifying the needed match. The full device strings are taken from the output of “udevadm info” command:

udevadm test '/devices/pci0000:00/0000:00:13.0/usb3/3-1/3-1.3/3-1.3:1.1/ttyUSB4/tty/ttyUSB4' >z4 udevadm test '/devices/pci0000:00/0000:00:13.0/usb3/3-1/3-1.3/3-1.3:1.2/ttyUSB5/tty/ttyUSB5' >z5 diff -u z4 z

The output identifies clearly that ID_USB_INTERFACE_NUM is the variable that we can rely upon in fixing to a particular port inside the 3G modem.

Analogous comparison for the USB-to-Serial adapter shows that the ports are differing in “devpath” attribute.

So, we add the following udev rules:

cat >/etc/udev/rules.d/99-usb-serial.rules <<'EOT' SUBSYSTEM=="tty", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="251d", SYMLINK+="ttyGOBI%E{ID_USB_INTERFACE_NUM}" SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyFTDI%s{devpath}" EOT

The “udevadm test” commands as specified above help in testing udev rules without the need to reboot the host.

After rebooting, we get the following devices with persistent names:

# ls -al /dev/tty* | grep USB lrwxrwxrwx 1 root root          7 Jun 14 11:22 /dev/ttyFTDI1.1 -> ttyUSB0 lrwxrwxrwx 1 root root          7 Jun 14 11:22 /dev/ttyFTDI1.2 -> ttyUSB1 lrwxrwxrwx 1 root root          7 Jun 14 11:22 /dev/ttyFTDI1.3 -> ttyUSB2 lrwxrwxrwx 1 root root          7 Jun 14 11:22 /dev/ttyFTDI1.4 -> ttyUSB3 lrwxrwxrwx 1 root root          7 Jun 14 11:33 /dev/ttyGOBI01 -> ttyUSB4 lrwxrwxrwx 1 root root          7 Jun 14 11:35 /dev/ttyGOBI02 -> ttyUSB5 crw-rw---- 1 root dialout 188,  0 Jun 14 11:22 /dev/ttyUSB0 crw-rw---- 1 root dialout 188,  1 Jun 14 11:22 /dev/ttyUSB1 crw-rw---- 1 root dialout 188,  2 Jun 14 11:22 /dev/ttyUSB2 crw-rw---- 1 root dialout 188,  3 Jun 14 11:22 /dev/ttyUSB3 crw-rw---- 1 root dialout 188,  4 Jun 14 11:33 /dev/ttyUSB4 crw-rw---- 1 root dialout 188,  5 Jun 14 11:35 /dev/ttyUSB5

 

Filed under: Networking Tagged: 3G, linux, pcengines