<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>LaForge's home page (Posts about bbs)</title><link>https://laforge.gnumonks.org/</link><description></description><atom:link href="https://laforge.gnumonks.org/blog/tags/bbs.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><lastBuildDate>Thu, 24 Oct 2024 20:08:48 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>Retronetworking / BBS-Revival setup at #36C3</title><link>https://laforge.gnumonks.org/blog/20200105-36c3-retronetworking/</link><dc:creator>Harald Welte</dc:creator><description>&lt;p&gt;After many years of being involved in various projects at the annual
Chaos Communication Congress (starting from the audio/vidoe recording
team at 15C3), I've finally also departed the GSM team, i.e. the people
who operate (Osmocom based) cellular networks at CCC events.&lt;/p&gt;
&lt;p&gt;The &lt;a class="reference external" href="https://events.ccc.de/camp/2019"&gt;CCC Camp&lt;/a&gt; in August 2019 was
slightly different: Instead of helping an Osmocom based 2G/3G network, I
decided to put up a nextepc-based LTE network and make that use the
2G/3G HLR (osmo-hlr) via a newly-written &lt;a class="reference external" href="http://git.osmocom.org/erlang/osmo_dia2gsup/"&gt;DIAMETER-to-GSUP proxy&lt;/a&gt;.  After lots of hacking
on that proxy and fixing various bugs in nextepc (see my
&lt;a class="reference external" href="https://github.com/laf0rge/nextepc/tree/laforge/cccamp19"&gt;laforge/cccamp2019 branch here&lt;/a&gt;)
this was working rather fine.&lt;/p&gt;
&lt;p&gt;For &lt;a class="reference external" href="https://events.ccc.de/congress/2019"&gt;36C3&lt;/a&gt; in December 2019 I had
something different in mind:  It was supposed to be the first actual
demo of the retronetworking / bbs-revival setup I've been working on
during past months.  This setup in turn is sort-of a continuation of my
talk at 34C3 two years ago: &lt;a class="reference external" href="https://media.ccc.de/v/34c3-9034-bbss_and_early_internet_access_in_the_1990ies"&gt;BBSs and early Intenet access in the 1990ies&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Rather than just talking about it, I wanted to be able to show people
the real thing:  Actual client PCs running (mainly) DOS, dialling over
analog modems and phone lines as well as ISDN-TAs and ISDN lines into
BBSs, together with early Interent access using SLIP and PPP over the
same dial-up lines.&lt;/p&gt;
&lt;p&gt;The actual setup can be seen at the
&lt;a class="reference external" href="http://osmocom.org/projects/retro-bbs/wiki/Dialup_Network_In_A_Box"&gt;Dialup Network In A Box&lt;/a&gt;
wiki page, together with the
&lt;a class="reference external" href="http://osmocom.org/projects/retro-bbs/wiki/36C3"&gt;36C3 specific&lt;/a&gt; wiki
page.&lt;/p&gt;
&lt;p&gt;What took most of the time was - interestingly - mainly two topics:&lt;/p&gt;
&lt;ol class="arabic simple"&gt;
&lt;li&gt;&lt;p&gt;A 1U rack-mount system with four E1 ports.  I had lots of old Sangoma
Quad-E1 cards in PCI form-factor available, but wanted to use a PC
with a more modern/faster CPU than those old first-generation Atom
boxes that still had actual PCI slots.  Those new mainboards don't
have PCI but PCIe.  There are plenty of PCIe to PCI bridges and
associated products on the market, which worked fine with virtually
any PCI card I could find, but not with the  Sangoma AFT PCI cards I
wanted to use.  Seconds to minutes after boot, the PCI-PCIe bridges
would always forget their secondary bus number.  I suspected
excessive power consumption or glitches, but couldn't find anything
wrong when looking at the power rails with a scope.  Adding
additional capacitors on every rail also didn't change it.  The
!RESET line is also clean.  It remains a mystery.  I then finally
decided to but a new (expensive) DAHDI 4-port E1 PCIe card to move
ahead.  What a waste of money if you have tons of other E1 cards
around.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Various trouble with FreeSWITCH.  All I wanted/needed was some simple
emulation of a PSTN/ISDN switch, operating in NT mode towards both
the Livingston Portmaster 3 RAS and the Auerswald PBX.  I would have
used &lt;a class="reference external" href="http://linux-call-router.de/"&gt;lcr&lt;/a&gt;, but it supports neither
DAHDI nor Sangoma, but only mISDN - and there are no mISDN cards with
four E1 ports :(  So I decided to go for FreeSWITCH, knowing it has
had a long history of ISDN/PRI/E1 support.  However, it was a big
disappointment.  First, there were some segfaults due to a &lt;a class="reference external" href="https://github.com/osmocom/freeswitch/commit/a341d58fbdf6b8bd7d1dd9509dc5319bee206168"&gt;classic pointer deref before NULL-check&lt;/a&gt;.
Next,  libpri and FreeSWITCH have a &lt;a class="reference external" href="https://github.com/osmocom/freeswitch/commit/5621e2a5edbbeec910988eca9446186f19790ab8"&gt;different idea how channel (timeslot) numbers are structured&lt;/a&gt;,
rendering any call attempt to fail.  Finally, FreeSWITCH decided to
&lt;a class="reference external" href="https://github.com/osmocom/freeswitch/commit/83f6bf5276cf70bb11b84615116b0e5cfc590b9d"&gt;blindly overwrite any bearer capabilities IE with 'speech'&lt;/a&gt;,
even if an ISDN dialup call (unrestricted digital information) was
being handled.  The FreeSWITCH documentation contains tons of
references on channel input/output variables related to that - but it
turns out their &lt;a class="reference external" href="https://github.com/osmocom/freeswitch/commit/2cd558502671b9902e0ed05e52d6b5ff10ecbb59"&gt;libpri integration doesn't set any of those&lt;/a&gt;,
nor use any of them on the outbound side.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Anyway, after a lot more time than expected the setup was operational,
and we could establish modem calls as well as ISDN dialup calls between
the clients and the Portmaster3.  The PM3 in turn then was configured to
forward the dialup sessions via telnet to a variety of BBSs around the
internet.  Some exist still (or again) on the public internet.
Some others were explicitly (re)created by 36C3 participants for this
very BBS-Revival setup.&lt;/p&gt;
&lt;p&gt;My personal favorite was finding &lt;a class="reference external" href="http://blackflag.acid.org/acid-underworld-on-searchlight.html"&gt;ACiD Underworld 2.0&lt;/a&gt;, one
of the few BBSs out there today who support RIPscrip, a protocol used to
render vector graphics, text and even mouse-clickable UI via modem
connection to a DOS/EGA client program called RIPterm.  So we had one
RIPterm installation on Novell DOS7 that was just used for dialling into
ACiD Underworld 2.0.&lt;/p&gt;
&lt;p&gt;Among other things we also tested interoperability between the 1980ies
CCC DIY accoustic coupler "Datenklo" and the Portmaster, and confirmed
that Windows 2000 could establish multilink-PPP not only over two
B-channels (128 kbps) but also over 3 B-Channels (192).&lt;/p&gt;
&lt;p&gt;Running this setup for four days meant 36C3 was a quite different
experience than many previous CCC congresses:&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;&lt;p&gt;I was less stressed as I wasn't involved in operating a service that
many people would want to use (GSM).&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;I got engaged with many more people with whom I would normally not
have entered a conversation, as they were watching the exhibits/demos
and we got to chat about the technology involved and the 'good old
days'.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;So all in all, despite the &lt;a class="reference external" href="https://twitter.com/LaF0rge/status/1210463996282884096"&gt;last minute FreeSWITCH-patching&lt;/a&gt;,
it was a much more relaxing and rewarding experience for me.&lt;/p&gt;
&lt;p&gt;Special thanks to&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;&lt;p&gt;Sylvain "tnt" Munaut for spending a lot of time with me at the
retronetworking assembly.  The fact that I had an E1 interface around
was a good way for him to continue development on his ICE40 based
bi-directional E1 wiretap.  He also helped with setup and teardown.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;miaoski and evanslify for reviving two of their old BBSs from Taiwan
so we could use them at this event&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The retronetworking setup is intended to operate at many other future
events, whether CCC related, Vintage Computing or otherwise.  It's
relatively small and portable.&lt;/p&gt;
&lt;p&gt;I'm very much looking forward to the next incarnations.  Until then, I
will hopefully have more software configured and operational, including
a variety of local BBSs (running in VMs/containers), together with the
respective networking (FTN, ZConnect, ...) and point software like
CrossPoint.&lt;/p&gt;
&lt;p&gt;If you are interested in helping out with this project: I'm very much
looking for help.  It doesn't matter if you're old and have had BBS
experience back in the day, or if you're a younger person who wants to
learn about communications history.  Any help is appreciated.  Please
reach out to the &lt;a class="reference external" href="mailto:bbs-revival@lists.osmocom.org"&gt;bbs-revival@lists.osmocom.org&lt;/a&gt; mailing list, or directly
to me via e-mail.&lt;/p&gt;</description><category>bbs</category><category>ccc</category><category>osmocom</category><category>retro</category><guid>https://laforge.gnumonks.org/blog/20200105-36c3-retronetworking/</guid><pubDate>Sat, 04 Jan 2020 16:00:00 GMT</pubDate></item></channel></rss>