2 Jan
2020
2 Jan
'20
2:35 p.m.
Hello,
yesterday we (myself and Guido Flandero/KHS9NE) have released "A Voip
Wardialer for the phreaking of 2020
"https://github.com/x25today/voipwardialer .
<https://github.com/x25today/voipwardialer>
The main goal of the project is to have a fully working software-only
VoIP-Modem that can be used for wardialing, dialing a favorite BBS
running on Landline number and more.
The design is a bit "creative" but it's done a way to make the
"Software
DSP" issue pluggable and remote (now Asterisk-Softmodem connected to a
local asterisk).
It's a Python PJSIP application that call the target phone number via a
VoIP provider, then call the local asterisk with Asterisk-Softmodem is
running, then provide a Terminal.
All this flow is working as MVP, would you enjoy playing with it with
the many improvements needed
https://github.com/x25today/voipwardialer/issues :)
-naif
2 Jan
2 Jan
10:56 p.m.
Hi Fabio,
On Thu, Jan 02, 2020 at 02:35:34PM +0100, Fabio Pietrosanti (naif) wrote:
yesterday we (myself and Guido Flandero/KHS9NE) have
released "A Voip
Wardialer for the phreaking of 2020
"https://github.com/x25today/voipwardialer .
<https://github.com/x25today/voipwardialer>
congratulations.
The main goal of the project is to have a fully
working software-only
VoIP-Modem that can be used for wardialing, dialing a favorite BBS running
on Landline number and more.
This is pretty much what I had in mind, too - although not specifically for
wardialing, but simply for any use case.
The design is a bit "creative" but it's
done a way to make the "Software
DSP" issue pluggable and remote (now Asterisk-Softmodem connected to a local
asterisk).
As you can see at http://osmocom.org/projects/linmodem/issues I had the plan
to do this based on the linmodem code from Fabrice Bellard (who needs no
introduction). The code implements more different modems/standards than
the asterisk code, and it's not really tied to the winmodem hardware - it simply
consumes and produces 16bit samples, so all that's needed to attach it to RTP
is to do the aLaw/uLaw table lookup.
But hey, my approach is still vapourware and yours is implemented, so who
am I to make suggestions.
Happy hacking,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3 Jan
3 Jan
9:06 a.m.
On 02/01/2020 22:56, Harald Welte wrote:
I think that yours is "the right approach" from a technical standpoint
of view.
What we tried to achieve is "something working" by gluing together all
of the pieces, leaving for another pizza-hackaton improvements and
stabilization.
It's *likely* that Asterisk-Softmodem doesn't provide the performance
and stability we want (sometime is connect, sometime it does not
connect, sometime it gives your garbage, anyhow still missing CONNECT
and reporting of negotiated carrier speed).
So the world still miss the missing piece of a features voip-modem that
also provide a pty.
I added osmcom linmodem to the "Software Modem" section
https://github.com/x25today/voipwardialer#software-modem .
This is pretty much what I had in mind, too - although
not specifically for
wardialing, but simply for any use case.
Yes, we also realized that focusing our current and past effort on
trying to get a working "voip-modem" is much helpful than making a "voip
wardialer" (because, for example, beave's iWas could work fine exposing
a pty with basic AT emulation).
The design is
a bit "creative" but it's done a way to make the "Software
DSP" issue pluggable and remote (now Asterisk-Softmodem connected to a local
asterisk).
As you can see at http://osmocom.org/projects/linmodem/issues I had the
plan
to do this based on the linmodem code from Fabrice Bellard (who needs no
introduction). The code implements more different modems/standards than
the asterisk code, and it's not really tied to the winmodem hardware - it simply
consumes and produces 16bit samples, so all that's needed to attach it to RTP
is to do the aLaw/uLaw table lookup.
But hey, my approach is still vapourware and yours is implemented, so who
am I to make suggestions.
We're working to try to make this working with a commandline and
extendit piece by piace, but really without the real
telecommunication-grade effort-and-skills to fix the DSP problem
properly, assuming that someone with that knowledge will help in hooking
one of the cool and complete softmodem.
Linmodem is surely a way to go, we also spotted this nice soft-modem
that by reading the specs seems very very interesting for it's
integration opportunity (connecting pty and audio i/o) and the careful
timing consideration https://github.com/randyrossi/fisher-modem .
Did you ever saw / considered this?
-naif
11:08 a.m.
Hi Fabio,
On Fri, Jan 03, 2020 at 09:06:58AM +0100, Fabio Pietrosanti (naif) wrote:
I added osmcom linmodem to the "Software
Modem" section
https://github.com/x25today/voipwardialer#software-modem .
thanks.
Linmodem is surely a way to go, we also spotted this
nice soft-modem that by
reading the specs seems very very interesting for it's integration
opportunity (connecting pty and audio i/o) and the careful timing
consideration https://github.com/randyrossi/fisher-modem .
Did you ever saw / considered this?
Thanks. I didn't know it, but it also seems to only implement slower
speeds and not [what I find more interesting] V.34 and/or V.90. Also,
the fact that it's already multi-threading seems a bit odd to me. In
the end, the modem is nothing but a process that consumes samples and
produces characters in the Rx side, and the inverse for the transmit
side. Having a kind of library of C functions for this (like linmodem)
seems most natural to me. But hey, that's a matter of personal
taste.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6 Jan
6 Jan
10:57 a.m.
Hi Harald,
while there are many testing that must yet be done, surely Linmodem
and/or Fisher-Modem are much more complete DSP than Asterisk-Softmodem.
So, reaching the stage where one of the two get integrate directly, make
much more sense.
I built both C softmodem and saw their command line, requiring as input
a "dsp" .
Now i've opened this ticket:
Test integration of Linmodem & Fisher-Modem into the VoIP Wardialer
trough PJSUA and Alsa hacking
https://github.com/x25today/voipwardialer/issues/16
The idea is that we may try to use those Softmodem by playing with the
Alsa Loopback interface having:
- 1 Audio virtual audio device for a normal VoIP Modem (being our pjsua
or other stack or even a graphical client)
- 1 Audio virtual audio device for the Softmodem command line (for
easier testing)
Those crossed trough Alsa Loopback interface, but formally each having
it's own audio device.
Did you considered for testing something like this? As it could be a
quick and dirty hacking approach, yet to be tested
-naif
On 03/01/2020 11:08, Harald Welte wrote:
Thanks. I didn't know it, but it also seems to
only implement slower
speeds and not [what I find more interesting] V.34 and/or V.90. Also,
the fact that it's already multi-threading seems a bit odd to me. In
the end, the modem is nothing but a process that consumes samples and
produces characters in the Rx side, and the inverse for the transmit
side. Having a kind of library of C functions for this (like linmodem)
seems most natural to me. But hey, that's a matter of personal
taste.
Regards,
Harald
1573
days inactive
1577
days old
4 comments
2 participants
participants (2)
-
Fabio Pietrosanti (naif) -
Harald Welte