If you ever want more phone lines than that, you can pick up an old Cisco VG-224 from Ebay for less than half the price of that line simulator, and you get 24 lines. There is a configuration that will let you use it as a standalone unit where all the lines can call each other with custom phone numbers (here's some notes [1]).
The main catch is that they have a 50-pin Centronics style connector on them which you will have to break out somehow to your RJ11s. Also, they are big (1U rack) and have fans.
I've got a few of these and have been meaning to set them up with a bunch of modems and a bunch of computers, but haven't gotten to it yet. Modems do seem to work in the limited testing I've done. They do (as expected) work great with telephones, including pulse dialing.
> The main catch is that they have a 50-pin Centronics style connector on them which you will have to break out somehow to your RJ11s.
This is just another lost art (traditional phones are either dead or are instead IP) that I once learned a fair bit about:
The name varies regionally (I've heard them called Centronics, cinch, and CHAMP; though around here, we call them Amphenols). The Easy Method is the same regardless of name: It centers around a split (aka "50 pair") 66 punch block[1] that is mounted to a wall, or to a wall-like object.
Buy a pre-terminated 25-pair cable with the right connector on at least one end, and punch that down in order[2] on one side of the 66 block. That connects the system to the punch block. Importantly, those wires never get touched again.
Phones (or more precisely, wires for jacks for phones) connect to the other side of the 66 block. Those wires also never get touched again.
The two things (phones, systems) are connected/disconnected with bridge clips that combine the two halves of the block (which only allows 1:1 ordering, but that's often just fine).
Alternatively, a "we fancy!" variation uses single-pair cross-connect wire so that arbitrary phones can quickly be connected to arbitrary system ports -- maybe on completely separate blocks.
After that, plug in the Amphenol. Plug in the phones. Have fun talking to yourself.
(Or, at least: That's an easy way for small stuff. Bigger stuff (hundreds or thousands of pairs) eventually really wants better organization, but punch blocks are still normally the order of the day there, too.)
I've wondered for a while if it would be possible to do that with a USB FXS adapter[1], and something like a Pi, but you'd basically need a soft modem of some kind to make it work and the only module for Asterisk isn't up to the challenge (last I checked five years ago).
However, to be frank, it'd make more sense to do PPP over null modem with a straight serial connection.
I'd be curious if anyone has actually used a setup like this as a fallback for when their fiber goes down. The latency would be brutal, but a few kbps beats no bps
I pulled out a WRT54G the other day and set it to a 56K limit. A netbook running ubuntu(ish) took several days to complete an apt-get update. But when I connected my laptop with 50 browser tabs, the tabs themselves consumed 100% of the bandwidth with background traffic (despite my ad blocker) and no other network services worked at all.
Unless you've tuned your system for it, dial-up modem speeds are functionally equivalent to "no connection at all".
Timeouts are killer too... many modern apps assume slow or no response for more than 10 or 20 seconds is "Internet is down" and will stop trying.
It's brutal, even with modern Internet, when people develop apps with the assumption of the Internet connection always having decent latency and bandwidth.
Jeff mentioned in his video that just loading the front page of CNN would take something like an hour and a half (20+ MB).
33.6Kbps is not practical for much on the modern Internet in 2026. As mentioned in a sibling comment, Starlink (even in standby mode) would be much better. lite.cnn.com would load in about 10 seconds which is pretty good, but there's not much else like it left anymore.
What's amazing is how great the Internet in the 1990s managed to be despite these limitations. Just like with RAM and disk space, developers back then had to be very mindful of bandwidth - today's devs (and agents) have the luxury of paying much less attention to that.
I feel like it would have been more fun to build your own line simulator with a 9 volt battery and some old phone line and just skip the dialtone altogether for a little magic... the $120 black-box telco simulator takes a lot of the fun out.
But then again, based on Pi pricing today, the $120 telco simulator goes nicely with a $300 Pi 5.
Line simulators are fun. The ports can call each other and there's no need to set any custom init strings on the modem like you need with the 9 volt trick. For some old devices that's a necessity.
You can also use an old VoIP ATA from Linksys/Cisco as a cheap line simulator. Like a fully analog TLS the ports can call each other. They can be a PITA to configure right but they're cheap and work well enough.
I've used all three methods, the TLS is the easiest. An ATA can be useful if you've got more than one and your dial-in server is in a different room from the client you're playing with. An ATA can also be set to "call" another device. So your office ATA can call the basement ATA (with your Linux server) as an example.
If you ever want more phone lines than that, you can pick up an old Cisco VG-224 from Ebay for less than half the price of that line simulator, and you get 24 lines. There is a configuration that will let you use it as a standalone unit where all the lines can call each other with custom phone numbers (here's some notes [1]).
The main catch is that they have a 50-pin Centronics style connector on them which you will have to break out somehow to your RJ11s. Also, they are big (1U rack) and have fans.
I've got a few of these and have been meaning to set them up with a bunch of modems and a bunch of computers, but haven't gotten to it yet. Modems do seem to work in the limited testing I've done. They do (as expected) work great with telephones, including pulse dialing.
[1] https://alnwlsn.com/z/pots/cisco-vg224.html
> The main catch is that they have a 50-pin Centronics style connector on them which you will have to break out somehow to your RJ11s.
This is just another lost art (traditional phones are either dead or are instead IP) that I once learned a fair bit about:
The name varies regionally (I've heard them called Centronics, cinch, and CHAMP; though around here, we call them Amphenols). The Easy Method is the same regardless of name: It centers around a split (aka "50 pair") 66 punch block[1] that is mounted to a wall, or to a wall-like object.
Buy a pre-terminated 25-pair cable with the right connector on at least one end, and punch that down in order[2] on one side of the 66 block. That connects the system to the punch block. Importantly, those wires never get touched again.
Phones (or more precisely, wires for jacks for phones) connect to the other side of the 66 block. Those wires also never get touched again.
The two things (phones, systems) are connected/disconnected with bridge clips that combine the two halves of the block (which only allows 1:1 ordering, but that's often just fine).
Alternatively, a "we fancy!" variation uses single-pair cross-connect wire so that arbitrary phones can quickly be connected to arbitrary system ports -- maybe on completely separate blocks.
After that, plug in the Amphenol. Plug in the phones. Have fun talking to yourself.
(Or, at least: That's an easy way for small stuff. Bigger stuff (hundreds or thousands of pairs) eventually really wants better organization, but punch blocks are still normally the order of the day there, too.)
[1]: https://en.wikipedia.org/wiki/66_block
[2]: https://news.ycombinator.com/item?id=41428998
What I would love to have is a few compact dialup-to-wifi bridges so I could wifi-ize 30 year old hardware.
Would be neat to read email with an old POP client, or chat over the original AIM software (perhaps patched to use a server on the LAN)
I've wondered for a while if it would be possible to do that with a USB FXS adapter[1], and something like a Pi, but you'd basically need a soft modem of some kind to make it work and the only module for Asterisk isn't up to the challenge (last I checked five years ago).
However, to be frank, it'd make more sense to do PPP over null modem with a straight serial connection.
[1]: https://www.amfeltec.com/usb-fxs-adapter/
I'd be curious if anyone has actually used a setup like this as a fallback for when their fiber goes down. The latency would be brutal, but a few kbps beats no bps
I pulled out a WRT54G the other day and set it to a 56K limit. A netbook running ubuntu(ish) took several days to complete an apt-get update. But when I connected my laptop with 50 browser tabs, the tabs themselves consumed 100% of the bandwidth with background traffic (despite my ad blocker) and no other network services worked at all.
Unless you've tuned your system for it, dial-up modem speeds are functionally equivalent to "no connection at all".
Timeouts are killer too... many modern apps assume slow or no response for more than 10 or 20 seconds is "Internet is down" and will stop trying.
It's brutal, even with modern Internet, when people develop apps with the assumption of the Internet connection always having decent latency and bandwidth.
Jeff mentioned in his video that just loading the front page of CNN would take something like an hour and a half (20+ MB).
33.6Kbps is not practical for much on the modern Internet in 2026. As mentioned in a sibling comment, Starlink (even in standby mode) would be much better. lite.cnn.com would load in about 10 seconds which is pretty good, but there's not much else like it left anymore.
What's amazing is how great the Internet in the 1990s managed to be despite these limitations. Just like with RAM and disk space, developers back then had to be very mindful of bandwidth - today's devs (and agents) have the luxury of paying much less attention to that.
There are services which will remove all but the text when browsing and make it greatly lighter.
20+ mb is the weight of all the javascript javascripting, ultimately to arrange and display an html page.
The way this is set up is using your normal fiber internet as the backbone, so if the fiber goes down, the dialup does, too.
It would be funny as a project but there's better low speed backup options like a starlink dish on standby mode (500kbps)
Don't need to do that. I use a USR Total Control chassis as a white noise generator.
Nice, but slip and plip is more tun
I feel like it would have been more fun to build your own line simulator with a 9 volt battery and some old phone line and just skip the dialtone altogether for a little magic... the $120 black-box telco simulator takes a lot of the fun out.
But then again, based on Pi pricing today, the $120 telco simulator goes nicely with a $300 Pi 5.
Line simulators are fun. The ports can call each other and there's no need to set any custom init strings on the modem like you need with the 9 volt trick. For some old devices that's a necessity.
You can also use an old VoIP ATA from Linksys/Cisco as a cheap line simulator. Like a fully analog TLS the ports can call each other. They can be a PITA to configure right but they're cheap and work well enough.
I've used all three methods, the TLS is the easiest. An ATA can be useful if you've got more than one and your dial-in server is in a different room from the client you're playing with. An ATA can also be set to "call" another device. So your office ATA can call the basement ATA (with your Linux server) as an example.