XRPi Changelog
XRPi Downloads
Documentation Index
XRPi Blog
{ Also XRLin }
New XRouter Group
1st June 2019
The XRouter Yahoo Group served us well for many years, but has become difficult to use. For some while, people have been complaining about the adverts, although if you operate the group via plain text email instead of via the web, you don't see any.
But it has now started refusing perfectly innocent messages, claiming they contain malicious content. The disputed content appears to be Yahoo's own logos and links within the "---Original message---" part of a reply.
It usually accepts the message if all quoted text and links etc are removed, but doing so is tedious, especially on a phone or tablet. And it destroys the context of the reply.
It's good that Yahoo are trying to protect us from malicious content, and this is probably only a temporary glitch, but as most Yahoo groups now seem to be moving over to groups.io, it has prompted a member to create a new group on there.
The web interface for the new group is https://groups.io/g/xrouter.
If you prefer to operate it like a good old fashioned mailing list, you can do that too. Join the group either via the web interface, or by sending a message to xrouter-subscribe@ groups.io, then simply send your messages to xrouter@groups.io.
Like the old one, the new group is for all versions of XRouter, including XR16, XR32, XRPi and XRLin. See you there?
Choice vs Simplicity
22nd May 2019
There has been a slight change of policy regarding IP configuration.
Up till now, the philosophy has been to let sysops decide which IP stack they use for which operations, and how they want to route their IP traffic. If they don't set it up correctly, it doesn't work, which forces them to find out why, and fix it. All in the spirit of "self-training", which used to be a core principle of the Amateur Radio licence.
However, it has become painfully clear that many sysops haven't a clue about IP, and it is always the IP configuration that trips them up. It's no good saying "RTFM", (a) because there is no manual for XRPi yet, and (b) it's too steep a learning curve for some sysops.
Thus the policy on IP configuration and routing is being changed, to make it more "idiot proof". The intention is for XRPi to work "straight out of the box".
For example, it used to be the case that if you didn't set up at least one IP address and a default route, all TCP/IP functionality was disabled. That was a security feature, and a desirable state in some cases. But it caused much confusion and consternation in those who didn't understand.
From now on, XRPi will do its best to make sense of all the weird and wacky configs that are thrown at it, instead of being overly pedantic. For example, even without an IP address or routing table, it will still manage to telnet out, via the Linux stack, instead of sulking.
XRPi vs XRLin
12th April 2019
There appears to be some confusion between the names "XRPi" and "XRLin". They are fundamentally the same thing.
The project began as "XRPi" - XRouter for the Raspbery Pi. The IDE requires the use of a project name, and that was the first one to come to mind.
It was developed on a Pi, to be used on a Pi. From comments received about XR32, it was judged that no-one wanted to run a full-size PC for packet these days, so a general-purpose "XRLin" might never happen.
Soon after XRPi limped into life on the Pi it was successfully recompiled on Porteus (a very lightweight distro), proving the code could run on a PC. That version was named XRLin, simply because it wasn't running on a Raspberry Pi.
Nothing more was done with XRLin, and development of XRPi continued for another 2 years. Then someone recently asked if there was a PC version of XRPi? So XRPi v501b was copied to a machine running MX-Linux and recompiled as XRLin v501b. Nothing was changed apart from the program name. They are both the same program, compiled for different processors.
This may not always be the case. PC's and Pi's are physically very different. XR16's "CTRL" feature, which used pins on a parallel printer port to control external hardware, couldn't work on a Pi, because it has no LPT port. Likewise the Pi has GPIO pins but a PC does not. Future versions of XRPi may use the GPIO, meaning XRPi and XRLin may have to diverge slightly.
Sound Modem Support
15th March 2019
This has been on the XRouter to-do list long before XRPi. It is finally a reality.
Back in the day, the intention had been to build soundmodem support into XR16. Suitable code was written and tested, but there was never enough memory space to incorporate it.
With XR32, there seemed no point incorporating soundmodem code, because AGW Packet Engine already did the job, and XR32 could interface to it.
And finally to Linux, where AGWPE is not available, but other soundcard packet solutions already exist. No point re-inventing the wheel.
Information was sketchy, but it seemed that KISS-over-TCP would be needed, for XRPi to communicate with the soundmodem software. The answer was much simpler than that.
The program "soundmodem" by Thomas Sailer can be configured to act like a KISS TNC. All that is required is to set up a matching KISS port in XRPi and that's it, job done.
Security Monitor
19th August 2019
Over the last few days a new "Security Monitor" window has been added, and the Intrusion Detection System (IDS) has been beefed up, using code from the firewall version of XR16.
The extra window provides more space for the security warnings, which were previously sent to the small "notifications pane" of the Status Window mixed in with general notifications. It also provides a quick overview of a few IDS stats.
This window could possibly be a waste of space in case where there is no likelihood of attack, so it may in future be made optional. Yet a security monitor with no threat warnings is quite reassuring in any case.
In cases where XRPi has to be placed in a router's "DMZ", the security monitor will be of much more use. Fore-warned is fore-armed as they say.
Non-Sysop FTP Accounts
22nd July 2018
It should be stressed that XRPi's FTP server is intended purely for system maintenance, NOT for general use.
Rightly or wrongly, XRouter (in all its forms) has focussed on routing packets, while its companion XServ was specifically designed for serving files and messages, and handling user accounts.
The reasons go back to the early 1990's, when "cast-off" computers were relatively low powered. Time for a history digression...
Early versions of XRouter, like BPQ, were often run from 5.25 inch floppy disk on 4.77MHz XT machines. There was not enough memory or processor speed to do both routing and serving effectively on the same machine.
It was possible to run a packet BBS and node on the same PC, using BPQCODE plus W0RLI BBS, and possibly DesqView etc. But XRouter was much larger than BPQCODE, because it had integral chat, IP routing and PMS etc. If it had been a TSR, it would have left no space for a BBS.
Similarly, XServ was more comprehensive than W0RLI, so it used more memory.
XRouter and XServ could have been combined into a NOS-style all-in-one package, but that would ultimately have led to compromises due to lack of memory and small, slow hard drives.
Keeping XRouter and XServ apart also allowed sysops to choose whether they wanted to run either or both, or to mix and match with BPQ, FBB, NNA etc. Not every BBS sysop wanted to run a multi-port node, and most nodeops didn't want to run a BBS either.
For those who wanted to run both, it meant running two PC's, but back then no-one seemed to care about the cost of electricity.
XRouter and XServ remained separate when they moved to Windows, as XR32 and XS32. Now at last they could run on the same machine. But it still seemed logical to keep them as separate projects.
So what's the point of all this?
Because there is no Linux equivalent of XServ yet, it has been requested that XRPi's FTP server should have "user accounts", each with their own directory tree, as in XServ. This seems to be contrary to the whole ethos of XRouter and XServ, but has been implemented, in limited form.
In XServ, not only did users have their own directory trees, but all directories had configurable read and write privileges for sysop, user and guests. This was like Unix, but running on DOS!
Theoretically it would be much simpler to achieve that sort of security now XRouter is running on Linux. But for now the quick and dirty fix is to let the sysop set the permissions. The new behaviour is as follows:
When someone connects to the FTP server and enters their username, XRPi checks both PASSWORD.SYS and USERPASS.SYS. If the username is found in PASSWORD.SYS, the user is a sysop. Upon successful completion of the password challenge he gets full access to the directory tree that XRPi has permissions for. e.g. if XRPi is running as root, the sysop can access the whole system.
If the username is found in USERPASS.SYS but NOT in PASSWORD.SYS, the user is NOT a sysop. He gets access only to a personal sub-directory within the FTP directory. The sub-directory name matches the username. The user is free to create directories within his own directory, but cannot climb out of it, or see anything outside it.
It is a workable compromise, if anyone needs it.
Development Slow-down
10th September 2017
Although not much is reported here (because it would be boring to detail everything), there has been plenty going on.
2016 was mostly taken up by the sheer drudgery of converting hundreds of source files between incompatible compilers and platforms, then making it all work.
Apart from slowdowns in January and June, much of this year has seen daily development of XRPi, both in "snagging" and new developments. At first, the work was concerned mainly with bringing XRPi to the same stage as XR32. It is well past that stage, and is now better than XR32 in many respects.
Apart from today's slight mod to the HTTP server, there has now been no work on the project for 10 days. There is plenty still to do, but other things sometimes have to take priority.
Security Monitor
16th August 2017
Up till now, selected intrusion detection system (IDS) warnings have been sent to the "warning pane" of the status window, which is only 40 columns by a few lines. Those warnings soon scroll off the pane, and there is no overview of the security status.
Therefore a new "Security Monitor" window has been introduced, located between the "Status Monitor" and the first console. This is window 7 in the carousel.
The Security Monitor displays the warnings in a less cryptic format, whilst also displaying status information such as the number of unique IP adressses heard, the number of banned IP's, the number of UDP frames and TCP connections blocked, the number of failed login atempts, and the number of malicious attempts.
The display is just a proof of concept at present, and will be added to when time allows. There are many more stats to be added, e.g. for port scans, TCP attacks, IP fragmentation attacks, honeypot hits and so on.
The IDS is a legacy from XR16, a copy of which was in 24/7 service for 14 years as an Internet router / firewall, gaining valuable experience and successfully resisting all attacks.
Nowadays, domestic routers are supplied by ISPs, so it is not envisaged that there would ever be a need to use XRPi as an Internet router.
But in order to use IPENCAP and other protocols that may not be handled by some domestic routers, some sysops may need to put their XRPi in the DMZ. That exposes it to everything the Internet can throw at it. So XRPi needs to be able to detect, resist and report attacks, which are unfortunately commonplace nowadays.
XRPi Gets a Display
7th August 2017
Over the past few weeks some new window code has been created to allow multiple remote windows, one per XRPi window if required. This code has now been adapted to re-create the familiar XR32 display within a Linux terminal window.
The original intention had been for XRPi to run as a daemon, with all interaction performed via HTML pages. But having seen the display, it is good to have it back.
XRPiMon
27th July 2017
Notification sessions are useful, but if XRPi is restarted, the notification session breaks and has to be restarted too.
A new "concept" program, called XRPiMon (XRPi Monitor), uses UDP instead of TCP to display the notifications, so it isn't affected if XRPi is rebooted.
"Notifications" Session
25th July 2017
With only a rudimentary display at present, XRPi lacks the useful warning and notifications panes that XR32 had.
So a new facility has been added - a session that can receive the notificatons and updates that used to go to the status and notification panes in XR32.
A "notification session" is created by logging into TCP port 513 then issuing the "notify on" command. The session will now receive notifications, and won't time out. It will still however function as a normal session, apart from the notificatons apearing on screen.
The idea is for this session to be left open on the r-pi desktop, or on another machine.
A notification session can also be used as a trace session, and everything can be captured as usual.
If the session is disconnected, notifications cease.
Only one session may receive notifications. Attempting to start a second session reslts in "Error! - only one session may receive notifications". But sending "notify off" will stop notifications on the original session, allowing them to be turned on on the new session.
Development Moves to Jessie
16th July 2017
XRPi source was today cloned to a new Pi, this time running Debian Jessie. It compiled and ran no problem. What's more, the Jessie version worked on Wheezy, but not vice-versa.
The reasons for this to be investigated at a later date.
Development slowed almost to a halt towards the end of May, and only a few bugfixes were done in June. But July has so far seen a fair bit of work on the project.
XRPi Won't Run on Jessie?
3rd April 2017
The Pi used for developing XRPi runs Raspian "Wheezy". Today the executable was tested on Debian "Jessie", and segfaulted straight away. It seems that, to run on Jessie it needs to be compiled on Jessie. Very odd.
There were no such problems with XR32 on Windows. It worked on all of them, from Windows 2000 onwards. Before that, XR16 ran on all flavours of DOS, plus win95/98.
Serial Device Issues
12th March 2017
The serial interface code has now been completely rewritten for Linux. But there were some issues with a Chinese USB to Serial adaptor during the testing phase.
During the tests, XRPi was running the USB-to-serial adaptor with an RS232 "loopback" connector plugged into the RS232 side. No matter what was sent by XRPi, the received characters all had ASCII values below 32. It was as though the device was running 5-bit data.
The device, a CH-340 type, was tried on a Windows machine, and worked OK once the correct driver was installed. But it didn't work on the Pi.
Swapping it to a Prolific PL-203 device effected an instant cure. It appears that Raspbian Wheezy might not support the CH340 properly?
Another problem with the cheaper Chinese adaptors is they are TTL levels, not RS232. They don't generate the negative "mark" voltage, and won't work properly with hardware that expects to see both positive and negative signals with a 6v "no-mans-land" in between.
XRPi Up and Running
27th November 2016
All the source files have now been either fully converted or temporarily hobbled to make them compile. Time to see if it makes...
Yes it does! XRPi burst into life, albeit with some of the functionality disabled. There is no display for instance, just a command line. Nicely minimal.
The HTTP server works, but the telnet server hangs after the user enters a callsign, and the FTP server is acting odd too.
Serial port support is yet to be sorted out. It is much simpler on Linux, so all the UART register #defines of DOS, and ovelapped I/O rubbish of Windows can be pruned out. That will be a rainy day job.
XR16 used version numbers in the 0-199 range. XR32 used 200+. To avoid confusion, XRPi starts at version 500.
Converting Win32 C Source for GCC
1st June 2016
After a few days of conversion, some of the common themes...
- Firstly, filenames are case sensitive on Linux.
The following header files don't exist in GCC, so they have to be stripped out of the source.
- <dos.h>
- <dir.h>
- <alloc.h>
- <winbase.h>
- <windows.h>
- <conio.h>
- <bios.h>
- <mem.h>
Some of the prototypes normally contained therein are located in different header files in Linux. e.g. memory allocation functions are located in <string.h> instead of <alloc.h>. Logical, NOT. Expect a lot of grepping to unearth them from their hidey-holes.
"#pragma hdrstop" is not recognised, and has to be removed.
The use of NULL as a character value is not allowed, e.g.
callsign[7] = NULL; if (str[7] == NULL)
Thousands of instances have to be checked and replaced.
The alternative, "callsign[7]=0;" is correct, but doesn't really convey the intention so well. Using "#define NULLCHAR 0" allows the code to look more normal, like this:
callsign[7] = NULLCHAR;
Several well-known functions don't exist, and have to be written from scratch, for example:
- strupr() / strlwr()
- max() / min()
- itoa()
- findfirst() / findnext()
- OutputDebugString()
#ifdef's can't be OR'd, so:
#ifdef _X_ || #ifdef _Y_
has to be replaced with:#if (defined(_X_) || defined(_Y_))
Clock ticks run at a different speed to DOS/Windows.
When the return value of a function is not used, the compiler complains.
Some of the other differences found so far. Some are easily fixed with a #define, but others have syntax that is too different.
Borland Linux CRITICAL_SECTION MAXPATH CLK_TCK _timezone timezone _daylight daylight closesocket() close() WSAERROR ERROR WSA_getErrNum() errno ioctlsocket() ioctl() strnicmp() strncasecmp()
XRPi Project Resurrected
28th May 2016
The project had originally been started over a year ago, around March 2015. The idea back then had been to start from scratch, gradually building new code upon a working kernal, rather than trying to adapt existing code for a radically different platform.
But it soon became clear that to re-type over 20 years worth of source code into the Raspberry Pi over a TightVNC link was too huge an undertaking. There were millions of characters in hundreds of thousands of lines of code. The XRPi kernal ran, but project was then shelved.
The only realistic way to manage a project of this size was to adapt the existing source code, file by file.
The most recent XR32 source code dated 28th Nov 2014 was copied to Raspberry Pi. Of course it wouldn't compile, being full of Win32 API calls and pre-processor directives that GCC didn't understand.
The long and tedious process of converting each of the 217 source files for Linux began. At one or two files per day, this will be a long job.
The Search For a Linux C/C++ IDE
January 2015
Only Borland products (Turbo-C and C++Builder) have so far been used in the XRouter project. Their IDE's (Integrated Development Environment) are very convenient to use.
For example, pressing <F1> while the cursor is within a known C function name, brings up a help window showing the description, syntax, arguments, return values etc. for that function. This is all built-in, and doesn't need an Internet connection.
It is really easy to compile, build, test, debug etc. using these IDE's. No complicated makefiles or command line hieroglyphics.
Months of searches like "Turbo-C for Linux" and "Linux C/C++ IDE" turned up nothing, except other people asking the same thing. Most things have been cloned onto Linux, why not Turbo-C?
Maybe that's a future project.
Eclipse seems too big, and too steep a learning curve.
Geany is ok, but it's just a clever text editor which can be tweaked to act a bit like an IDE for many languages.
It does have some nice touches, such as displaying code and comments in different colours, and basic syntax suggestions. The colour is a breath of fresh air after the monochrome IDE's of Turbo-C and C++Builder.
Building a big project using Geany is going to require fiddling with obtuse makefiles. Borland did all that automatically.
But Geany seems the best of a bad job, and at least "Hello World" was produced with relatively little effort, so it looks like the one to use. And hey, it's already there on the Raspberry Pi. Job done.