[Qemu-devel] Qemu phone modem emulation

[Qemu-devel] Qemu phone modem emulation

[Eric Koldeweij]

Hello all,

I am currently working on a serial telephone modem emulation 
implementation for Qemu. My question is if it would be a good idea to 
offer it for inclusion in the qemu main trunk when it's ready. These are 
the requirements I am working with:

- The modem device is accessible through a new option for a serial 
device. A new -serial option has been added (so far, might change in the 
future):
     -serial modem:[<listenIP>]:<listenPort>

- The modem device will emulate a generic serial modem using a 
Rockwell/Conexant RC144xxx chipset. The reasons I have chosen this 
chipset are:
     - It was extremely common in its time and you could argue it was 
the de facto modem standard.
     - It is supported by most if not all serial communications programs.
     - It was the chipset of the first cheap and easily available modems 
with Facsimile/Fax support.
     - I have quite some documentation on this chipset as well as the 
working hardware to compare it against.
     - Since speed is not an issue (there is no bandwidth limiter) there 
is no need to support higher speeds and standards, it's just more 
programming work.

- The modem will be able to receive "calls" on a telnet or telnet-like 
interface. The modem will generate the appropriate "RING" messages to 
the serial port. Serial data and Fax transmission/reception are going to 
be supported.

- The modem will be able to "dial out" to a telnet-like interface 
service. This includes of course a qemu modem device.
     - This is the biggest problem I am encountering so far: it is 
extremely difficult to embed an IP adress and port number into a legal 
"telephone number". Suggestions on how to solve this are more than welcome.
For instance: "ATDT127.0.0.1:14400" works fine now but the dot and colon 
are not allowed in the dial string. Also there is a line limit of 39 
characters for each modem command which makes IPv6 addresses a bit 
difficult to encode. Of course I can make it any way I like but a lot of 
software won't allow it entered as a telephone number either.

- If two qemu instances are "dialing" each other, a speed negotiation 
will take place using unused telnet IAC options in which speed 
capabilities, error-correcting and compression abilities are exchanged. 
This is purely cosmetic however and it is going to be disable-able :) If 
no options are exchanged the emulation will assume a 
can-do-anything-modem at the other side and connect with the highest 
speed as allowed by the settings.

- The emulated modem will not be able to talk to a real modem. Just in 
case it wasn't obvious.

- I am open for feature requests.

I am looking forward to comments. Thanks for your time.

Regards,
Eric Koldeweij.

Re: [Qemu-devel] Qemu phone modem emulation

[Blue Swirl]

On Fri, Aug 17, 2012 at 7:26 PM, Eric Koldeweij <eric@no-sense.net> wrote:
> Hello all,
>
> I am currently working on a serial telephone modem emulation implementation
> for Qemu. My question is if it would be a good idea to offer it for
> inclusion in the qemu main trunk when it's ready. These are the requirements
> I am working with:
>
> - The modem device is accessible through a new option for a serial device. A
> new -serial option has been added (so far, might change in the future):
>     -serial modem:[<listenIP>]:<listenPort>
>
> - The modem device will emulate a generic serial modem using a
> Rockwell/Conexant RC144xxx chipset. The reasons I have chosen this chipset
> are:
>     - It was extremely common in its time and you could argue it was the de
> facto modem standard.
>     - It is supported by most if not all serial communications programs.
>     - It was the chipset of the first cheap and easily available modems with
> Facsimile/Fax support.
>     - I have quite some documentation on this chipset as well as the working
> hardware to compare it against.
>     - Since speed is not an issue (there is no bandwidth limiter) there is
> no need to support higher speeds and standards, it's just more programming
> work.
>
> - The modem will be able to receive "calls" on a telnet or telnet-like
> interface. The modem will generate the appropriate "RING" messages to the
> serial port. Serial data and Fax transmission/reception are going to be
> supported.
>
> - The modem will be able to "dial out" to a telnet-like interface service.
> This includes of course a qemu modem device.
>     - This is the biggest problem I am encountering so far: it is extremely
> difficult to embed an IP adress and port number into a legal "telephone
> number". Suggestions on how to solve this are more than welcome.
> For instance: "ATDT127.0.0.1:14400" works fine now but the dot and colon are
> not allowed in the dial string. Also there is a line limit of 39 characters
> for each modem command which makes IPv6 addresses a bit difficult to encode.
> Of course I can make it any way I like but a lot of software won't allow it
> entered as a telephone number either.

There could be a telephone directory with entries to match IPv4/v6
addresses, something like
[in]
127.0.0.1:*: 555-7368
[::1/128].*: 555-7368
*: reject

[out]
555-7368: telnet://127.0.0.1:14400
*: reject

> - If two qemu instances are "dialing" each other, a speed negotiation will
> take place using unused telnet IAC options in which speed capabilities,
> error-correcting and compression abilities are exchanged. This is purely
> cosmetic however and it is going to be disable-able :) If no options are
> exchanged the emulation will assume a can-do-anything-modem at the other
> side and connect with the highest speed as allowed by the settings.
>
> - The emulated modem will not be able to talk to a real modem. Just in case
> it wasn't obvious.
>
> - I am open for feature requests.
>
> I am looking forward to comments. Thanks for your time.

I think it would be better to support piping serial (or generally any
character devices) to any command via stdin and stdout.

But I'm not opposed to including modem emulation to QEMU, a similar
case can be found with smart card emulation.

>
> Regards,
> Eric Koldeweij.
>
>