Sending and Receiving SMS on Linux | Hacker News Reader

Sending and Receiving SMS on Linux

20papercups.net

151 pointsp4bl057 comments

I remember doing this a few companies ago. Except we didn't have a modem, we just found a phone we could send commands to. It had some user interface that would pop up after every sent message, so we rigged up a terrible little hack to press the acknowledge button every few seconds to dismiss it. It worked surprisingly well :)

Photo of this amazing disruptive device: https://i.imgur.com/6MNb19R.jpg

Haha, that's a nice solution. I recently did something like this and the process really makes you dislike the AT command set. If you don't want to take an old GSM phone apart to find its serial pins, a simple USB GSM modem, pretty much any USB GSM modem should be able to expose a /dev/ttyUSB* interface.

Older modems are /dev/ttyUSBx or /dev/ttyACM but newer modems might be using the MBIM [1] standard and don't really expose AT interfaces to the user.

1: https://www.kernel.org/doc/Documentation/networking/cdc_mbim...

MBIM does however expose an SMS and voice interface - if the device supports it. Though I can't see an obvious way to access it with the kernel API.

Side note to your post, the w800 in your picture was my all time favorite phone. I'm a full time Android developer now and I consider the Java programs I first worked on with the w800 to be the reason behind my interests :)

Very geohot of you

My SIP provider (Voip.ms (I am unaffiliated to them beside being a customer)) just send them by email, for free. It's included in my ~0.70$ USD per monthly plan (pre-paid almost forever on a 25$ payment). So, these day, I find it ridiculous to pay for a carrier voice/sms plan. It's pointless.

The worst thing that can happen is having a use a VPN on top of the SIP stream for carriers that void net neutrality. Tablet data plan + SIP = win

* You get your calls on your computer and devices, all of them, for the same price. * You can script your softphone to pause your music and answer in your music headset * You can add a SIP server in from of the link to add new features. * You can inter-operate media stream from Skype/(name your IM app) and "real" phones for "free"[1] using pulse audio / core audio. * Usually, multiple line, transfer and conferences are included, you don't have to pay extra. If they are not, you can implement them using your own SIP server or some scripts. * Most softphone have multiple account support, so you can have your business phone and home phone on the same devices, but with different Ringtones.

The possibilities are near limitless _and_ it is beyond cheap. The main downside is that you almost have to be an IT person to be able to make it all work :P

You don't have to pay for Skype _and_ a phone plan, only your phone plan.

/shameless plug If your using Ring.cx (I am one of the dev), you can also seamlessly make end-to-end encryptet and decentralized/P2P calls if your peer also use Ring.cx (or anything SIPS compatible, minus the decentralized part, so technically risking a MiM).

It's been a long time since I've tried to do serious SIP usage on Linux, but way back when, I could never get a client that worked consistently. One or the other would work fine for a while, until either the client, a library elsewhere on the system, or the SIP server would update, and then it'd misbehave terribly and I'd have to go through the roulette and try to find another client that worked well (not always possible). Is the situation better now? What do you use?

When I looked for a Windows and a Linux SIP client, I found that most things were based on PJSIP so all suffered the same problems. SIP (and RTP/RTMP) are complex to implement, so I don't think many people try.

I recently installed asterisk and I have SIP built in into my mobile. Works very well, and was easy to setup.

Give Linphone a try. UI is old school on Desktop, but it works fine. We have mobile clients too.

Disclaimer: I'm a linphone developer.

Linphone was the last client I had working before I gave up totally. Though it would often hang when trying to make a call, it worked well enough for 3 months or so. I started having to compile the builds from git and eventually it got to the point where the app was hanging every time I made a call and I'd have to kill -9 it. It's probably been 3 years or so since I tried it. Similar experiences were had with twinkle and a couple of other clients before I found Linphone.

Pity they don't have any servers <150ms away from me: http://wiki.voip.ms/article/Choosing_Server. I'm in Australia, so the SIP server really has to be in Sydney or Melbourne for it to work for me (~70ms RTT on ADSL). Someone from Perth can yell at me for being so Eastern-centric.

If you just use them for SMS, latency won't be an issue.

I haven't had a landline in about 4 years (known as "naked" ADSL - there's no dialtone on my copper line). I played with VOIP for quite a while but could never really get the quality I wanted. Then the mobile costs came down enough so I haven't looked since. Hangouts and Skype solved my international phone call problems, although I'm not entirely sure how they solved the echo/delay problems so well.

Edit: oh, right, this was an SMS specific article.

This is cool. I am only going to suggest that there is also this : https://github.com/haxpax/gosms

Written in Golang, simple api to push messages to queue, takes care of AT protocol for you. Also supports load balancing if you have multiple modems :)

Disclaimer: I am a co-author of that project. HN thread when we published it : https://news.ycombinator.com/item?id=9029341

It is only for sending messages though

There is (was?) also Gnokii [1] for old Nokia phones, which I've used successfully. I even managed to port a small part of it to Arduino to send a message automatically (code [2] and write-up [3]), but these days there are shields with much better interfaces than the Nokia FBus (e.g. using the SIM900 chip [4]).

1: http://www.gnokii.org/ 2: https://github.com/giech/arduino_nokia_6310i 3: https://ilias.giechaskiel.com/posts/arduino_sms/index.html 4: http://www.simcom.ee/modules/gsm-gprs/sim900/

I recently used gammu[1] to receive SMS messages on OSX using a Huawei modem, then forward them into iMessage[2]. Gammu's written in python and works great on Linux.

Goal was to have my old foreign number still able to receive SMS (receiving messages while roaming is free in most countries), and have them appear in iMessage on my current phone.

1: https://github.com/gammu/gammu 2: https://gist.github.com/rcoup/93460ea39b05e957e884

Edit: gammu is cross-platform

I also use Gammu, smstools was new to me.

We've been using Gammu for over 5 years now for on-call alerts or other small services. It has worked very well with an ordinary 3G dongle you can buy to get mobile internet on your laptop. The SIM card is provided by the company since we're a large telco we get pretty much free unlimited SMS from them.

This has been used in two different data centres without any reception issues, even though they're properly shileded data centres and we have no external antennae.

Only issues have been forced re-seats of the USB dongle a few times a year, most likely due to oxidation on the connector.

The only thing I've had trouble with is suspend/resume/etc on OSX which seems to hang gammu occasionally. I used the cheapest E170 I got from Ebay, the hardest part was messing with all the unlock tools to get it to play with the SIM in the first place :)

I used to do this back in 2005. Forgive me if something has changed in the intervening years.

There was a rate limit for receiving and sending SMSes via the hardware approach. My experiments yielded 1 per 20 seconds iirc

In the end my implementation purely received via hardware and exited via a bulk SMS provider like clickatell

clickatell at that stage allowed big users to set the 'sender caller id'. This was loved by spammers unfortunately so the providers became much more cagey about allowing that feature.

Michael here (author of the post). We didn't find any rate limits when receiving SMS, but found sending to be quite slow. Fine for our needs, but if you need to send a lot you may be better off paying for access to a gateway.

I have a ready to use bootable sdcard image for raspberry Pi(built with buildroot). This solution allows you to deploy your raspi and huawei-E173 behind your home router, and access the sms send/receive functionality via google-hangout.

In this setup, you need two google accounts, one for you and second one for your raspi-xmpp-chat-bot. You can have the whole setup up and running within 5minutes. This project is a opensource hosted on github. here are the details: http://albert-david.blogspot.de/2016/01/rbox-remotely-deploy...

There are apps on Android that lets you run your (old) phone as a SMS gateway. Just plug it into a usb port and select usb tethering. Then on the server/pc:

  ethtool usb0
  sudo ifconfig usb0 192.168.100.100
  ip addr show usb0

This is really stupid, but it works. https://github.com/WilliamFCipriano/FreeSMS

gateways.list is quite useful.

Are there lists that include more carriers (non-US)?

The other question is do any non-US providers have these gateways? Optus and Telstra in Australia don't support this kind of Email-to-SMS (at least, not for free).

I have found this list helpful http://ram.kossboss.com/list-of-sms-mms-gateways-for-phone-c...

This one is nicely organized:

https://github.com/cubiclesoft/email_sms_mms_gateways/blob/m...

I've tried using the gateway published there to send an SMS message to my phone, but my wireless service provider won't accept messages from my email server.

What carrier? Have you attempted it with a gmail account?

AT&T. Doing it with gmail wouldn't solve the problem I have that causes me to want to send SMS messages in the first place, so that's out.

i thought the only way you could do this was with Twilio or something

If you've got a VPS like most of us do, you're right.

Unless you can convince your VPS provider to stick the GSM modem in your server rack....

Oh the stories I could tell you of some old Nokia phone that was actually in a datacenter for an app I worked on. There was no cell reception in the new datacenter location, so that method was decommissioned.

I have code to 'curl' Twilio to notify me of certain things that need attention. It works and it's really cheap.

Serious question: How can you think that if you can buy wireless computers that can send and reveive SMS via their wireless connection ... that the only way to do so would be via some internet service?!?

edit: hello idiots! you might not believe it, but downvoting doesn't actually answer my question.

This is a technique for a cheap DIY Twilio.

Whether or not it's cheaper varies by country. US Mobile claims $9/month (plus undisclosed fees) for "unlimited" SMS, which isn't bad.

Advantage of Twillio (besides an actual API) is ability to get a short number.

Unfortunately they do not serve every single market.

It's arguably a lot easier to use Twilio for something like this because there's no hardware needed and you can be up and running in about 5 minutes for a simple setup. That said, the real difference here is probably that Twilio allows you to buy a bunch of numbers cheap so you can scale SMS. Carriers sometimes filter out messages if they are sent too often by one number, so it helps to spread the load across several if you are talking to a lot of users (and services like Twilio handle rate-limiting for you).

This is really cool though, the second SMS hardware hack I've seen on here this week. Glad to see people playing more in this space (especially in theatre, my other passion).

Disclaimer: I work for Twilio

Hi Carlo.

Yep, a nice service that gives you an API is a real winner, and you can send messages much faster. We didn't go that route because we were projecting out of a van. in rural South Australia, and had no data connection.

This was actually put together for an interactive, mixed media theatre project, If There Was A Colour Darker Than Black I'd Wear It. I've posted the followup on my website:

http://www.20papercups.net/software-projects/an-interactive-...

Cheers

This is a great write up. At first I was thinking "just use an api..." But the engineer quickly showed how easy it was with just a tiny bit of elbow grease.

Yep. We couldn't use an API anyway because we were projecting out of the back of a van, in rural South Australia. We were lucky to have any phone reception at all!

I have successfully used an Android device as a cheep SMS gateway. An app installed on the device acted as the gateway and messages are triggered from the server via GCM push messages to the device.

Incoming messages to the device are intercepted by a receiver on the device and posted back to the server.

Is it really too hard to send some AT commands to a serial port nowadays? Talk about reinventing the wheel.

Blast from the past!

I remember using SMS server tools and a cyclone(?) 8 port RS-232-hub to drive a bunch of GSM modems to act as an SMS gateway for a company back in '99. Funny to see that the software is still around.

Hangouts does all my SMS texting. Though having a modem to send text messages reminds me of setting up pager systems in the early 1990s.

Very cool. Is there any way to do this with more modern technology than GSM?

So why is no one implementing a ssh two factor authentication around this?

You're mistaken, this problem has already been solved as 10 seconds of Google-Fu have revealed.

Could you share the insights of your research? I only found solution involving the Google API (as it was also discussed here some days ago).

You could use privacyIDEA, which is a two factor auth server and is also capable of sending SMS via HTTP gateways.

BUT: You would rather want to use 2nd factors like HOTP or TOTP token or a yubikey.

https://startpage.com/do/search?query=ssh+two+factor+sms turns up Authy as the first hit.

SMS isn't particularly secure. It's a little disturbing that some people use it for authentication.

Please tell my bank :)

If you have an iphone it will even sync it back to your Mac for you :D

TOTP is superior, no chance of social engineering your phone company to redirect the messages.

Reply on news.ycombinator.com