TCP/IP over audio

http://www.anfractuosity.com/projects/ultrasound-networking/

by anfractuosity • 12 years ago

137 67 12 years ago

There have been several threads on HN about ultrasonic networking in recent months. One was a simple chat client, called Quietnet [1]. The other was malware called BadBIOS, which has the ability to communicate over hi-def audio [2].

[1] https://news.ycombinator.com/item?id=7024615

[2] https://news.ycombinator.com/item?id=6654663

jff2• 12 years ago

The alleged ability to communicate over audio, since its very existence is questionable.

ParadisoShlee• 12 years ago

#BadBIOS might be vapor but #RadBIOS is coming!

https://pbs.twimg.com/media/BZpjjcyCUAI48nH.png

logicallee• 12 years ago

Does nobody here remember modems? You take an old 2400 baud modem that's supposed to work over a crackly telephone line - www.engadget.com/media/2009/05/090527-300baud-01.jpg

that's literally how TCP/IP was invented. This stuff - pure, analog audio - went all the way up to 28.8kbps, which was the limit of the line bandwidth. Why not just take those protocols and put them into a speaker and microphone. Why bother writing new protocols? Just start with modem protocols and play with the frequencies.

Home Internet connectivity was literally born out of TCP/IP over audio...

gscott• 12 years ago

Furbys have been there, done that. http://robotzsf.blogspot.com/2012/11/furby-2012-hacking.html

erjiang• 12 years ago

As an aside, the tun/tap interface in Linux is a fantastic way to muck around with lower-level networking without getting into the kernel or hardware. Essentially, it creates a virtual network interface, except instead of hardware, data goes to your userspace program. You can then just do a read() to grab packets and do whatever you want with them, using Python, Ruby, or anything other programming language.

I wrote a prototype proxy in Go that can split network traffic over two Internet connections using some hacked-together tun code[0] and everything happens in userspace.

[0] https://github.com/erjiang/tuntuntun

IbJacked• 12 years ago

Neat project, I like the way I say tuntuntun in my head. Your abbreviation of "ttt" makes me think of Technojock's Turbo Toolkit... ya, I'm old :)

noonespecial• 12 years ago

Openvpn is the king of all tun/tap applications. A gander at its code is a good way to get a serious look at implementing your own networking with tun/tap interfaces.

matiasb2• 12 years ago

Yeah, I'm trying to tunnel TCP packets over Facebook chat[0] (to get some free Internet when using "social media" mobile plans).

[0] https://github.com/matiasinsaurralde/facebook-tunnel

rahimnathwani4• 12 years ago

Interesting. Have you tried using a DNS tunnel? It would be similarly slow if it worked over your connection.

rafavega• 12 years ago

How is it that they receive and transmit ultrasonic frequencies with a computer sound card? Is there not a low-pass filter at around 22KHz on inputs and outputs of all sound cards?

deutronium2• 12 years ago

I was able to transmit at up to around 23kHz which you may be able to make out the spike on the FFT graph on the video I made for some previous work: http://www.youtube.com/watch?v=H0DKRl8XIcU

To get up to 23kHz I used a sample rate of 48kHz.

nitrogen• 12 years ago

The built-in audio on most PCs these days supports 96kHz or even 192kHz sample rates.

whoopdedo• 12 years ago

The DAC may sample at that resolution, but it's another matter if the driver will pass an ultrasonic frequency. Looking at a few datasheets from various manufacturers, I don't see any mention of bandpass filters. So either they don't have them or they don't think it's worth mentioning.

ackydoodles• 12 years ago

No.

lutusp4• 12 years ago

Is there not a low-pass filter at around 22KHz on inputs and outputs of all sound cards?

It's not a low-pass filter per se, the limit is imposed by the Nyquist–Shannon sampling theorem (http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_samplin...), which essentially limits the frequency spectrum to 1/2 the clock rate. Good-quality audio from a sound card is clocked at 44 KHz, which means the audio range extends only to 22 KHz.

But you can clock a modern sound card at a rate much faster than 44 KHz, so the above might be only the normal limit, not the extreme.

Cogito• 12 years ago

I couldn't see any information on the linked page - anyone know what the latency and throughput characteristics of this set up are?

Would be very interesting to understand how audio attenuation impacts the TCP/IP connection.

deutronium2• 12 years ago

I haven't done proper throughput tests with it yet.

I'll see if I can dig out a pcap file I took using it, which should give you an idea of the latencies involved.

[Edit] I've just updated the page with a wireshark screenshot which shows the latencies and also a link to the pcap file.

Something which I'm keen to look at doing is extending it beyond 2-FSK, to improve the throughput.

ChuckMcM3• 12 years ago

Definitely, to QQAM encoding and you should be able to get a decent baud rate out of it. I believe both QAM and QQAM are built into gnuradio as encoding options.

chrissnell• 12 years ago

Amateur radio folks have been doing this for a long time, since the early 1990s at least.

Aqwis• 12 years ago

Radio is electromagnetic waves, not sound waves.

VLM• 12 years ago

He's more correct than you think. Since the 90s there's been an explosion of sound card based digital modulation schemes. Usually you see a waterfall spectrum from 0 to "whatever" and you click where you want to operate. Essentially the attached SSB transceiver is a linear transverter from audio to some RF.

So instead of tuning your radio to 7.070 MHz and clicking on the computer waterfall at 1200 Hz (aka operating at 7.0712 MHz) you just unplug the radio from the computer, use speaker and mic instead of something plugged into speaker and mic jacks and click on 18 KHz or whatever.

In the early days of PSK-31 and other modes you did demos at radio club meetings and whatever by just letting it rip over the speakers. Loud and annoying but works pretty well across a room or further.

The main limitation is most SSB communications radios cut out around 3400 Hz at the high end so the software that is written for sound card digital modes cuts out somewhere above that, but sometimes not as high as 25 KHz or whatever, because 99% of the users and devs will never fool around with ultrasound.

Because I like to use a HF modulation mode called Olivia I mostly use an old version of DM780 software (from when it was free) and multipsk (free) although I could use FLDIGI (which is also free). In my infinite spare time I'll see what unnatural limits have been built into the software. This topic of ultrasound networking comes up on HN like clockwork every week or so, so I'll report back next time.

(Edited to add, one thing I like about multipsk is the, um, innovative UI. Go to images.google.com and take a look.)

flibertgibit• 12 years ago

This to me is incredibly awesome. The question is, could you use radio frequencies meant for speech/music for it? I think so, since morse code is sent on these same frequencies. What about streaming video over short wave radio?

lutusp4• 12 years ago

What about streaming video over short wave radio?

That's what TV broadcasting does. But it's radio (electromagnetic) waves, not sound waves.

yeukhon• 12 years ago

Side question: UDP seems to be the preferred protocol for VoIP-type of services. While the size of a UDP message is generally much larger than that of TCP, and some missed UDP messages are acceptable (analogous to cellular communication some signal weakness/loss is acceptable), any other strong reasons people prefer UDP over TCP in VoIP?

delluminatus• 12 years ago

UDP is used in a lot of environments where a few dropped packets aren't an issue, because the package guarantees in TCP slow things down, and TCP is generally a heavier protocol so it's slower... because... ?

I think that I actually don't know any more than you about it.

IvyMike• 12 years ago

What happens when packets are dropped in UDP? A bit of audio corruption.

What happens when packets are dropped in TCP? A hard-to-predict amount of delay. And retransmission of audio data that you might just throw out anyway. (There are alternatives to discarding the data that should have already been heard, like temporal compression, but that's hard to do right, too.)

MichaelGG• 12 years ago

With TCP, when you drop a packet, you wait for it to requeue, and the application gets no data. You can see the effects in some poorly implemented video conferencing systems. You'll see someone speaking, then it'll pause for a few seconds, then the system will play the recovered video really fast to catch up. It's quite annoying.

Instead, for realtime applications, you make sure each packet is usable by itself, and make your system gracefully degrade in face of packet loss.

(Or, if you're from the insane world that designed Fax-over-IP, you transmit 2 or 3 packets for each packet, and hope that staves off packet loss.)

awalton• 12 years ago

TCP gives you two guarantees over UDP:

* All packets arrive. (Reliable transport). * All packets that arrive are in order. (Sequential transport).

Unfortunately, both of these aren't so necessary for real time audio (and somewhat less so, video). In fact, they get in the way.

Missing packets can often be replaced in VoIP settings with various kinds of interpolation. And out of order data can be buffered and used to build the interpolated data before playback. Interestingly enough, even packets that have been damaged still often are usable to VoIP applications, since they still contain some payload that can be used to improve the signal.

jijji• 12 years ago

In the old days, they used to call this a "modem". Long live the Hayes 1200 baud modem of the early 1980's.

rahimnathwani4• 12 years ago

Remember the BBC micro and other computers of that era, which used audio tapes to save programs? I recall a BBC TV programme about technology from when I was a kid. In at least one episode, they played such a tape on the air, so that we could record it (by holding the cassette recorder near the TV speaker), and then load the program ourselves.

Is this a false memory or can someone else confirm seeing this?

bane2• 12 years ago

It's probably true. The rate of data on the tapes was probably slow enough that even over a lossy TV broadcast signal it would still survive.

I think the Commodore Cassette drive was 50 bytes/sec?

antimagic• 12 years ago

I was able to copy Commodore cassettes using my father's high end audio setup. A friend with a standard two-tape deck ended up with corrupted tapes though, so the bit rate must have been close to the limit of the medium.

pgeorgi• 12 years ago

Something similar was provided via radio (not TV): https://en.wikipedia.org/wiki/BASICODE

It's possible that the BBC broadcasted data in the same way (conceptually, even if not in format) on their TV programme.

easytiger• 12 years ago

Yea that is correct. I'm pretty Sure Micro Live did this.

lucb1e• 12 years ago

Is there any step-by-step setup guide for dummies? I'm entirely new to gnuradio and have no idea how this is supposed to work. It seems very interesting though!

By the way, I'm using Linux Mint 15 and fairly experienced with Debian-based Linux systems.

mistercow3• 12 years ago

This is neat, but for a teenager, 18kHz is more "instant headache" than "ultrasonic".

TCP/IP over audio

Related Stories