Using a Pine Phone as a SMS gateway - Part 2

I've noticed that SMS messages weren't being sent and discovered that  mmcli -L  was yielding  No modems were found . This is annoying. After checking through several online forums where folks reported similar disappearing modems, including one that turned out to be a hardware failure (hopefully not my problem!), I ran across a suggestion to change  /usr/lib/udev/rules.d/80-modem-eg25.rules  to replace  {power/control}="auto"  with  {power/control}="on"  and then issued a  systemctl restart udev  for good measure.

 

We'll see how it goes...

Using a Pine Phone as a SMS gateway

Having become disenchanted with the unreliability of using email to send SMS messages, I decided that it was finally worth the cost and effort to add a new line to my mobility account and use that SIM card in a modem that is capable of sending SMS directly.

I started with a modem from Amazon. This was a "OSTENT WCDMA/UMTS/HSDPA/HSPA+/FDD-LTE 4G Modem with SIMCOM SIM7600A Module USB Port at Commands Bulk SMS MMS TCP/IP" modem which, based on the description, seemed like exactly what I wanted. Unfortunately, the item I received was either a lemon or just not friendly with the AT&T network. After many hours of fiddling with it, and struggling with zero documentation, I threw in the towel and returned it.

Next I picked up a "4G LTE" USB modem dongle from Aliexpress. At $10 it was an order of magnitude less expensive than the OSTENT modem and I figured it was worth the gamble. Upon arrival and attachment to PC I found that this dongle was actually a WIFI to LTE router, which isn't exactly what I needed, but I figured I could just ignore the WIFI functionality and just try to manipulate the LTE modem directly. I discovered that this dongle actually runs Android 4.4.4 (KitKat) and that I could attempt to send SMS directly via the adb shell. This was exciting and seemed to be exactly what I was looking for. Unfortunately, again, I found that even though i was sending properly formatted service commands to the modem via the adb shell, the messages never got sent. I assume that there was just something not exactly right about the APN, SMSC, or other parameters, or perhaps it was just that AT&T wasn't allowing (whitelisting) the IMEI. Whatever the cause, this was another failure that didn't seem immediately surmountable. I'll store this dongle away for future experimentation.

Finally, I pulled out my old Pine Phone (running Mobian) and discovered the (relative) pure bliss of the mmcli interface. Within ten minutes I had worked out the command structure I needed and wrote a base script that would discover the modem id, craft the SMS for that modem, and then send the SMS. It works beautifully, and I can send SMS from various machines on the network using SSH to the Pine Phone to invoke the bash script. It's just fantastic.

Actually, let me step back for one minute. The initial attempts to send SMS from the Pine Phone failed. I was following some steps to enable the modem via mmcli and was running into the following:

mobian@mobian:~$ mmcli -L /org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] QUECTEL Mobile Broadband Module mobian@mobian:~$ sudo mmcli -m 0 -e [sudo] password for mobian: error: couldn't enable the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.WrongState: modem in failed state' mobian@mobian:~$ sudo mmcli -m 0 --messaging-create-sms="text='Hello world',number='+1xxxxxxxxxx'" error: modem not enabled yet mobian@mobian:~$

 

It turns out that the "chatty" messaging application in Mobian was preventing mmcli from manipulating the modem. I renamed /usr/bin/chatty and killed the existing chatty process to release the modem and instantly mmcli started behaving as expected and I was off and running.

The friendly Linux environment of Mobian on the Pine Phone is just a dream compared to the nightmare of the undocumented OSTENT interface and the frustration of the Android dongle. Yeah, using a full-blown phone to perform this function is overkill and more expensive than it should have been, but I had the Pine Phone already from previous tinkering and it was just sitting on the shelf doing nothing, and now it's serving a useful purpose again.

BONUS - Here is the intial script I wrote to accept the target phone number and message as arguments. This is then easily invoked either locally or via ssh (zero interaction if using keys) from a remote host. Perhaps it's useful as a starting place for you.

#!/usr/bin/env bash _DEST_NUMBER=$1 shift _SMS_MESSAGE="$@" echo "Sending \"${_SMS_MESSAGE}\" to ${_DEST_NUMBER}" _MODEM_NUM=$(basename $(mmcli -L | awk '{print $1;}')) _MESSAGE_CREATION=$(mmcli -m ${_MODEM_NUM} --messaging-create-sms="text='${_SMS_MESSAGE}',number='${_DEST_NUMBER}'") _MESSAGE_ID=$(basename "${_MESSAGE_CREATION}") mmcli -m ${_MODEM_NUM} -s ${_MESSAGE_ID} --send exit 0

 

That's all for today.

FreeNAS zvol, iSCSI, VMware ESXi, and accessing that datastore from Linux

I am shuffling things around here. Initially, I had setup a file-based iSCSI target on my FreeNAS box for VMware ESXi to use as a datastore. Lately, I've had the desire to access those VM files from outside of ESXi (backup, etc.) and at first thought I would try to move one or two VMs to a NFS datastore served by the same FreeNAS box, but the performance was atrocious.

Right now, I am tinkering with a new zvol-based iSCSI target and accessing those VM files from my Manjaro-based laptop. The ESXi system creates a VMFS file system on the iSCSI target, and from Linux I had to install open-iscsi and vmfs-tools to make this happen.

As is usual with different distributions of GNU/Linux, the locations of files will vary from one distribution to the next. On some, you'll find the iSCSI target datbase in /var/lib/iscsi, while on Manjaro it's located in /etc/iscsi.

Legend:

• FreeNAS box is 169.254.20.100 (not really, documentation only)
• zvol is 1TiB in size
• iSCSI Extent is using FreeNAS defaults, nothing custom
• iSCSI Portal is not using authentication
• Domain name is 'example.net' (not really, documentation only)

On my Linux client, I opened a terminal...

# iscsiadm --mode discovery -t sendtargets --portal 169.254.20.100 169.254.20.100:3260="" iqn.2019-06.net.example.istgt:zvol.target # iscsiadm --mode node --targetname iqn.2019-06.net.example.istgt:zvol.target --portal 169.254.20.100 --login Logging in to [iface: default, target: iqn.2019-06.net.example.istgt:zvol.target, portal: 169.254.20.100,3260] Login to [iface: default, target: iqn.2019-06.net.example.istgt:zvol.target, portal: 169.254.20.100,3260] successful. # fdisk -l Disk /dev/sdb: 1 TiB, 1099511627776 bytes, 2147483648 sectors Disk model: iSCSI Disk Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 32768 bytes I/O size (minimum/optimal): 32768 bytes / 1048576 bytes Disklabel type: gpt Disk identifier: 79E7F7EF-EB2E-4086-9924-8E1730F8A54B Device Start End Sectors Size Type /dev/sdb1 2048 2147483614 2147481567 1024G VMware VMFS # vmfs-fuse /dev/sdb1 /mnt/freenas-iscsi-zvol     # /bin/ls -alF /mnt/freenas-iscsi-zvol total 794660K drwxr-xr-t 7 root root 1820 Jun 11 15:10 . drwxr-xr-x 9 root root 4096 Jun 11 13:23 .. -r-------- 1 root root 5439488 Jun 11 14:11 .fbb.sf -r-------- 1 root root 267026432 Jun 11 14:11 .fdc.sf -r-------- 1 root root 1179648 Jun 11 14:11 .pb2.sf -r-------- 1 root root 268435456 Jun 11 14:11 .pbc.sf -r-------- 1 root root 262733824 Jun 11 14:11 .sbc.sf srwx------ 2 root root 280 Jun 11 14:11 .sdd.sf= -r-------- 1 root root 4194304 Jun 11 14:11 .vh.sf

That's it, nothing else required. I can now access the iSCSI zvol using vmfs-fuse on my Manjaro Linux laptop.

Converting WMV screen recording (FastStone) to MP4 with VLC

I had a lot of trouble with this. The video would convert without an issue, but I couldn't get the audio to encode with AAC. I searched deep into the VLC forums and found a solution for my particular case. To start with, here is the error from the messages log in VLC:

stream_out_transcode error: cannot find audio encoder (module:any fourcc:mp4a). Take a look few lines earlier to see possible reason.

 When searching for info on that error, here is the working solution I found:

I'm having this exact same problem; I have never been able to transcode to mp4a without some kind of difficulty since the update to v2 (this is why I still have v1.1.12, but it has compatibility issues of its own).

I've managed to get it to work sometimes by going into VLC's preferences, choosing show all/advanced and going into video codecs > ffmpeg, and setting strict standards compliance to -2. I'm not sure how you would do this with the command line but there must be an option somewhere, though setting it via the GUI may be good enough. But this only solves the problem for some files, not all, even though as far as I can tell all the files I've been trying to process are identical.

The ones that give me trouble are usually ones with AC3 audio (which I try to transcode out since AC3 audio codecs on OS X are a pain in the ass), but if I transcode only the video the audio won't be passed through as normal, it will simply be missing. I don't know why this happens, but it means that instead of having a nice folder of widely compatible .mp4 files I instead have a mix of files that worked and ones I had to copy at full-size because I can't seem to do anything with them, very annoying.

After changing the "strict standards compliance" from the default of 0 to -2 I was able to convert the WMV screen recording from FastStone Capture into MP4 (H264 / AAC). Good stuff!

The life of IPv6

A friend today sent me a link to an old blog post from a very well respected man regarding IPv6 planning and design:

http://www.networkworld.com/community/blog/ipv6-address-design

I had seen this before, but after reading it again I sent the following to my friend. While I've had this opinion for many years, and have said as much to those I know for just as long, I had never published this opinion outside of IPv6 mailing lists and IRC channels. So, here it is here, take it for what it's worth.

Thanks for sending that!

It’s hard to argue with that man on any point in networking, but I still take issue with 64-bit interface identifiers. He admits that it’s extremely wasteful and he’s right, but the way he blows it off is troubling. Pretty much all of his design points with regards to organization using bits of the address could easily be shifted 24, 32, 40 (or more) bits to the right to make longer prefix lengths and extending the life of IPv6. Of course this would kill SLAAC, but SLAAC should never have existed in the first place (IMHO). The inclusion of a node addressing algorithm into the protocol itself is a huge fail.

The logic I use to advocate against SLAAC and 64-bit interface identifiers is based in both memory of shifting to IPv4 CIDR and also in today’s difficulty in IPv6 deployment. Yes, I fully understand that IPv6 != IPv4, but that doesn’t mean throwing away sane network design principles. Further, if you extrapolate today’s difficult and protracted IPv4->IPv6 transition to the IPv6->IPv? transition that our progeny will be stuck with then you’d start to realize that a much more conservative approach to IPv6 addressing today would mean a *much* longer life for the protocol. I’m talking about millennia, not decades, and well beyond the reach of this solar system. If something new comes along in 1200 years that deprecates IPv6 due to its superiority and simplicity to implement then that’s an easy case to make for transition. If our g-g-g-g-g-grandchildren run out of IPv6 in 400 years and have to move to IPv? then they are going to rightfully curse our names.

Or, maybe I’m wrong.

So, there you go. As I said to my friend, maybe I'm wrong, but given the facts and history I am going to stand by this opinion. What do you think?

FreeNAS 8 - getting out of my comfort zone

Well, I have been using a different version of FreeNAS 0.7 on my backup NAS (NAS2) for a while and just recently connected a monitor to the box to see if I could capture anything on the console that would give me a clue as to why the box would fall over at random times. What I found was a spinlock causing a panic. Not good. Since this version of FreeNAS was from the pre-8 days, I decided to step out of my comfort zone and completely rebuild this box with FreeNAS 8 and ZFS.

Just to give a little background on the hardware, this machine (actually two machines, NAS1 and NAS2) is built with:

• Intel BOXD945GCLF2 Atom 330 Intel 945GC Mini ITX Motherboard/CPU Combo
• Thermaltake Black SECC Japanese steel LANBOX Lite VF6000BNS Micro ATX Media Center / HTPC Case
• Thermaltake TR2 W0070RUC 430W ATX12V V2.2 Intel Core i7 Compliant Dual 80mm Fans Full Cable Sleevings Power Supply
• Kingston ValueRAM 2GB 240-Pin DDR2 SDRAM DDR2 667 (PC2 5300) Desktop Memory Model KVR667D2N5/2G
• 2x SanDisk SDCFH2-2048 2GB CF cards attached to CF->PATA adapters (OS disks)
• 1x WD 1TB spinning disk
• 1x Seagate spinning disk

Since the original construction, both Seagates have died and been replaced by a newer vintage WD drives, also 1TB in size. On each box, the drives are configured as a 1TB gmirror. The primary box, NAS1, is still running FreeNAS 0.7 (build 4292) and is dead reliable. The secondary box, NAS2, which I am documenting the rebuild here, was running FreeNAS 0.7 (build 4919) and this is the version that sporadically went into spinlock panic.

Now that you know the history, let's get into the new project!

First, these servers are running FreeNAS embedded on the ata0 (now ada0 in FreeNAS 8) CF card and the other 2GB CF card is idle. Previously I had taken the CF card out of the machine and used a PCMCIA CF adapter in my laptop to write the new embedded image. This time, I used a USB flash drive to test the new image before tearing the machine apart to get to the CF card.

On my windows laptop, using cygwin, I ran...

cat /proc/partitions

...before and after inserting the USB flash drive so that I could be sure of the target. In my case, with one fixed disk (known as /dev/sda), the USB flash drive was known as /dev/sdb. With this information, it was a piece of cake to write the embedded image for FreeNAS 8 to the USB flash drive using...

xz --decompress --stdout FreeNAS-8.0-RELEASE-amd64.Full_Install.xz | dd of=/dev/sdb

After the write, I inserted the stick into the powered-off server and flipped-on the power. It booted the image just fine, albeit slow, and I was in business. After some tinkering around I decided that I indeed wanted to push ahead and load FreeNAS 8 to the primary CF drive, but still not wanting to tear the machine down to get to the card, I decided to use `dd` to copy the image from the USB flash to the CF card. I had never done this but figured I would try and see if it would break or work. I logged in to the server and issued the following command via the CLI...

dd if=/dev/da0 of=/dev/ada0 bs=1M count=1000

It only took a few seconds to complete so I shutdown the machine, removed the USB stick, and powered it on. Lo and behold, it worked and I now have the embedded FreeNAS 8 on the primary CF card. Whoo hoo!

At this point, I am going to leave out all of the trials and tribulations that I had trying to get the machine to forget the old gmirror and reusing those 1TB disks for a new ZFS volume. If you need help sorting this out then you can ask via comments. Bottom line is that I didn't care about saving any data on those disks so was carefree in my destructive behavior.

So, now I have FreeNAS 8 embedded running from the ada0 CF card and have created my 1TB ZFS mirror. The next roadblock was the lack of rsync on FreeNAS 8. Rather, let me say the lack of browser-driven rsync, which meant that I needed to get the NAS1 -> NAS2 rsync working via the CLI. I am good with the CLI, but have never set up rsyncd like this before, so more fun!

First, I went to NAS1 and had a look at the rsyncd.conf file generated by FreeNAS 0.7 and decided I needed to replicate that on NAS2. Since I had previously used rsync to sync the entire 1TB from NAS1 to NAS2, I didn't want to put this rsyncd.conf into my 1TB storage volume, so I decided that this would be a great time to get the other 2GB CF card mounted for unique local storage.

From the browser interface of NAS2, I created a new volume based on the ada1 CF card but kept getting these "Error getting used space", "Error getting available space", and "Error getting total space" messages for the new volume. Since this wasn't very helpful information, I headed back to the CLI and kept an eye on /var/log/messages while recreating the volume. What I found in the messages log was...

Jul 19 13:08:25 nas2 freenas[1505]: Executing: gpart create -s gpt /dev/ada1 && gpart add -t freebsd-swap -l swap-ada1 -s 4194304 ada1 && gpart add -t freebsd-ufs ada1 Jul 19 20:08:25 nas2 freenas: ada1 created Jul 19 20:08:25 nas2 freenas: gpart: autofill: No space left on device Jul 19 13:08:25 nas2 freenas[1505]: Executing: newfs -U -L PERSIST /dev/ada1p2 Jul 19 20:08:25 nas2 freenas: newfs: /dev/ada1p2: could not find special device

In retrospect, the geometry of the CF card probably caused some glitch in the size calculation and therefore caused a failure in the creation of the partitions by gpart. Not knowing that at the time, I decided to see if I could try and make it work manually. I ran the following commands...

[root@nas2 ~]# [root@nas2 ~]# [root@nas2 ~]# [root@nas2 ~]# cd /dev [root@nas2 /dev]# ls ada1* crw-r----- 1 root operator 0, 85 Jul 19 20:08 ada1 [root@nas2 /dev]# [root@nas2 /dev]# [root@nas2 /dev]# [root@nas2 /dev]# gpart add -t freebsd-ufs ada1 ada1p1 added [root@nas2 /dev]# [root@nas2 /dev]# [root@nas2 /dev]# [root@nas2 /dev]# newfs -U -L PERSIST /dev/ada1p2 newfs: /dev/ada1p2: could not find special device [root@nas2 /dev]# [root@nas2 /dev]# [root@nas2 /dev]# [root@nas2 /dev]# newfs -U -L PERSIST /dev/ada1p1 /dev/ada1p1: 1954.0MB (4001692 sectors) block size 16384, fragment size 2048 using 11 cylinder groups of 183.72MB, 11758 blks, 23552 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 376416, 752672, 1128928, 1505184, 1881440, 2257696, 2633952, 3010208, 3386464, 3762720 [root@nas2 /dev]# [root@nas2 /dev]# [root@nas2 /dev]#

Again, lady luck was on my side and the results were as expected and the partition was created. Since I hadn't deleted the error-laden volume from the browser GUI, I went ahead and rebooted to see what would happen. Upon reboot, the CF card was mounted correctly and I now have my 2GB "PERSIST" space for local persistent data. Whoo hoo again!

Keep checking back for the next installment where I document the creation of the rsyncd.conf file in the persistent local storage area, the initialization of rsyncd, and the resumption of the daily job to keep NAS1 backed-up to NAS2.

Might start expanding content here soon...

Ok guys, I know that this blog has been focused on technical pursuits thus far, and with a title like "RF and IP" I guess you could have figured that out. I am thinking about expanding that content to a general log of activities in my life outside of the technical pursuits you have come to expect here. What I am not sure about is whether that's a good idea or whether I should start another blog for general interest stuff and keep this one technical (geeky) in nature. I would appreciate your comments on this since you are the ones to be affected by the decision.

Thanks,
Mike