It's that time again... WyrePak Newsletter time, that is. In this edition I am pleased to bring you the first instalment of the possible future of Packet - GlobalNet, by Paula G8PZT - don't forget, you read about it here first! We also have an article that came by Packet all the way from New Zealand from Nick, ZL3TPN. There's been plenty of activity on the Packet front recently, too, much of it to do with problems and their rectification, so it is pleasing to report that all systems seem to be back on the rails as I write.
It is with some regret that I have to return to twice-yearly publication of WyrePak Newsletter. This is due to two main factors: pressure of work on my part, and lack of contributions on yours! It is true to say that Richard and Paula regularly provide me with items for inclusion, but the rest of the content is usually made up by me, and tends to reflect my own particular - some might say peculiar - radio interests. So, to keep the content as relevant and Packet-orientated as possible, I have decided that quality has to take precedence over quantity. I will aim to produce a spring/summer newsletter and an autumn/winter edition from now on.
WyrePak meetings are still held on the third Tuesday of every alternate month. Occasionally, this pattern will change due to particular circumstances, but I will let everyone know via the List Server and/or e-mail. Meetings for the rest of 2004 are on September 28th (this is the AGM; separate notification has already been sent out by Packet) and November 16th. Again, due to pressure of work, I have ceased preparing formal minutes and report all items of interest in the pages of WyrePak Newsletter.
At the WyrePak AGM there will be the opportunity to help the Group by joining the Committee, which currently comprises just Paula G8PZT, Richard G0EWH and myself, with Brian G0MBG as acting Vice-Chairman.
I went into the shack a few weeks ago to find a short message on the screen of my Baycom packet system, from an amateur I'd never worked before. The message was from Nick, ZL3TPN who had been surfing the packet network via an Internet link, found Paula's node, looked for active stations and found mine! I dropped Nick a reply and it transpired that he has to contend with some unusual problems in order to get QRV on the mode from his remote QTH. Nick kindly agreed to write an article for the newsletter, transmitted by Packet Radio of course, and I am very grateful to him for giving us a flavour of his particular branch of the hobby -Ed.
Sent: 27-06-2004 at 10:59
From: ZL3TPN @ ZL2TZE.#73.MLB.NZL.OC
To : G4SPZ@GB7PZT.#24.GBR.EU
Subj: Re: Newsletter
Path: GB7PZT!ZL2TZE!ZL2TZE!
Hi there Phil. "Remote Packet in ZL" is a little long winded as a title, and may be no good... spelling's not a strong point, and I hate public speaking. Let me know what you think and we'll go from there! Local BBS off air and had to do trick sending... Ta - Nick
Remote Packet in New Zealand
It's never been easy for me and amateur radio... I've enjoyed the glossy pictures of new rigs etc. but the price was always a little out of reach... hence the cheapness of my station. Another challenge for me is that I live in an old house truck that rests amongst the mountains on our land near Murchison. There are no mains power or telephone lines, so early on, amateur radio was utilised to have contact with the outside world, and packet radio, with the constant debates and information, became very appealing.
A cheap 386 laptop was bought, a Baycom modem built and tested and I'm on the air. Ham friends from my city days and their occasional updates added to the interest and enjoyment, but it wasn't without problems. The laptop had to be immune to a low power supply, as I'd run the car battery down to around 10V with a wet weekend inside and often, have the computer shut down mid-QSO. Very embarrassing but at least the switch-mode PSU survived. A new 12V supply was needed, one with lots of reserves. I've now an 80W solar panel and a battery of six ex-telecom cells each rated 2V and 560Ah giving me heaps of 12V grunt, not that I need it.
The local Digi is very high on a mountain and the path, with only one hill in between, is quite serviceable on 5W, unless it's stormy. With careful attention to tuning the antenna to the 144.650MHz frequency, communication is much easier than a high powered station would ever have, using a poor aerial. I'm using a base loaded half wave and approx. 4m of coax. The half wave works well because it simulates a ground plane, when one isn't available and the angle of radiation is very close to 90 degrees. It will run even better on a ground plane, like a car roof, but I've mine on a hockey stick pole bolted to the wall outside and it seems ok. I have times when the path is slow due to ice on the Digi or when it's stormy, but that's forgivable.
Most evenings I'll work packet, since I've given up on the television and if the going's good then I'll try working overseas nodes or BBS's that are listed on my local node. Sometimes nothing much happens as the internet links are intermittent, but it's fun and sometimes a link will stay firm enough to allow me to investigate and explore. A list of the current users might show me who's around and by trying a connect, sometimes it gives results. Or I'll leave a message on their PMS to show I've been there. Most of the Northern Hemisphere is accessible during your night as the traffic is less and that may help me get around, a bit like Santa dropping down the chimney when everyone is asleep. I do have a lot of trouble getting access to Africa and South America but that's understandable. A lot of these countries rely on PACTOR HF so a converse would take a lot longer... I'm only guessing here, as I've had no experience working with PACTOR...yet.
Another interesting way to work contacts is to look at the message headers of interesting topics and try to work backwards to contact the originator, leave a message on their PMS or at their BBS if they're not "home". Having a text chat with the operator is the main objective and most will navigate me through their local systems if I'm having trouble. I always find it easier if when chatting to include the symbol > when I'm at an "over", because long distance can distort the context and cause some confusion with conversation getting to the destination in time-delayed packets. You've all been there.
Thriftiness and the location have led to my station evolving rather than a direct plan. Plus, a lot of the enjoyment and success I attribute to the help and skills from the local clubs of Greymouth, Nelson and Motueka. Without them I'd be marooned, a lonely station in the middle of snow-capped mountains, thanks guys. Yet amateur radio is forever evolving and soon satellites will become the nodes of the future. Plans are under way to make a KiwiSAT FM repeater/beacon with the possibility of a 9K6 Digi. A prototype is being tested right now by ZL3KB in Christchurch, and all the bugs are getting worked out.
The internet has transformed the packet world and I accept that the routing isn't 100% RF but I know that my station is all RF and I wouldn't have got to here without amateur radio being a part of my life. The internet has made it easier to communicate with others and that after all is what ham radio is all about. In New Zealand there are some wonderfully dedicated people helping out in all aspects of our hobby, from the small operators who take part in a passive role just watching and giving their occasional point of view, to the major helpers who run the BBS's and nodes, and fix the Digi when problems arise. We have a wonderful hobby with all sorts having some part to play and all together it's a great mix of people, personalities and lots of fun. Enjoy!
Nick - ZL3TPN @ ZL2SUN
Andy M1TIG is a fan of Real Ale, and subscribes to the ALE list at the GB7PZT BBS List Server. Having had a chat with me about Real Ale, Andy mentioned that he only uses Internet access to the BBS and that he had made a donation to Paula. Without further delay, we made him our newest member of WyrePak...! - Ed.
Sent: 12-06-2004 at 00:25
To: G4SPZ
From: M1TIG @ GB7PZT.#24.GBR.EU
Subj: Reply to Phil G4SPZ
Path: GB7PZT!
Hi Phil
Thanks for the reply. I access GB7PZT via the Internet. Paula was very helpful in setting up my account. I did send Paula a donation to help with the running costs, though I do not know if she received the cheque. [She did, but as Andy had not given his address, Paula was unable to acknowledge receipt - Ed] Please could you send me a sample newsletter? [Done - Ed]
I have read the 'LOCAL' file, thanks for that. I think the idea of WAP access to PZT is a good one and I will try it out.
Thanks, Andy M1TIG @ GB7PZT
Plenty to report on this front!
At approximately 1517 hours on Thursday 12th August, a lightning strike close to G8PZT caused failure of the KIDDER node. All node broadcasts and activity ceased, and service was not resumed until later on the 13th. The strike also caused havoc with the broadband Internet connection by damaging the broadband modem, and this also affected the co-sited Internet-linked 2-metre voice repeater GB3KD until the following Saturday when the broadband modem was replaced by Paula's service provider.
Many users have reported problems accessing KIDDER via the 2-metre RF port. This has been an intermittent problem with more than one possible cause. The old ex-Gas Board 100MHz AM Dymar transceiver, which provides the 144.850MHz service, was checked and found to have developed an intermittent fault, causing low sensitivity and increasing its susceptibility to de-sense from GB3KD on 145.7875MHz. Paula rectified this fault around 3rd August by improving the earth bonding of the rig's PCB and chassis to its case. On other occasions, periods of low sensitivity were found to coincide exactly with times when GB3KD was active, suggesting residual de-sensing, although Paula feels this is not the sole cause.
At the time of writing, KIDDER is back on air and up to normal sensitivity. Richard G0EWH has modified a Bosch ex-PMR transceiver, which will eventually replace the Dymar and improve sensitivity and stability, but audio level incompatibility problems are still to be ironed out, by the construction of a suitable audio pre-amplifier when time and resources permit.
The original Internet access IP address of http://g8pzt.ath.cx ceased to work for a time. The alternative IP addresses which take the user to Paula's menu pages, http://www.pzt.org.uk and http://www.g8pzt.pwp.blueyonder.co.uk still operated, but clicking on the GB7PZT button, and selecting either the "Web" or "Telnet" routes to the node, also failed. The "Web" route was giving a "web page not found" error message, and the "Telnet" option prompted the user to log on with their password, as usual, but then gave the "Bad password!" error message, despite the password being correct. There were two factors at work here. First, "ath.cx" is a free domain server, which relies on knowing Paula's own IP address. This usually remains constant, but Paula's ISP changed her IP address, and the free domain server took some time to catch up with the change! As of the 18th August it is working again. Secondly, the problems with the broadband modem caused some very long error log files to be generated, and these completely filled the hard disk. With zero (yes, 0) bytes free on a computer's hard drive, odd things happen and the system became unable to read from the file of current passwords, thus creating the "bad password!" message. Paula cleared the log files and normal operation was restored.
As always with intermittent faults in a complex set of systems and sub-systems such as the node and GB7PZT BBS, it is very difficult for the SysOp to analyse the problem and effect remedies unless users provide very specific reports. Reports are always welcome, indeed essential, preferably by packet or e-mail (not telephone, please) with as much detail as possible. For instance, please include the time and date the problem was encountered, the nature of the problem, when "normal service" was previously received, and also report (if possible) what other RF activity was present at the time, particularly on GB3KD.
To try to assist Paula in resolving problems, I have decided to collate all fault reports myself. The following message went out over the LSTSRV list server:
Date: Tue, 17 Aug 2004 22:42:17 +0000
From: g4spz@gb7pzt.#24.gbr.eu (Phil)
To: WYRPAK
Subject: System fixes
Good evening to all WyrePak members. I am pleased to report that a number of 'problems' that members may have been experiencing with the node and BBS have now been resolved.
The web access URL http://g8pzt.ath.cx is now fully operational.
Passwords are now being recognised by the web access Telnet and Java links.
De-sensing of the node by GB3KD has been virtually eliminated.
Broadband Internet service has been fixed and the Internet links restored.
Many of these problems were caused by a lightning strike close to G8PZT, which damaged several key pieces of kit. The node was put out of action by one damaged TNC which 'locked up' the whole system for 24 hours. The only outstanding problem is the telephone dial-up access to the BBS, which is non-functional due to a faulty PC modem caused by lightning damage.
Contrary to common belief, Paula does not continually monitor the node or the BBS, and is often unaware of problems unless users ring her up to complain! Many users recognise that Paula has many demands on her time and energy, and quite understandably are reluctant to bother her. For this reason, in future would all members please report any problems with the node, BBS or links direct to me? I check my e-mails and Packet mail every day and will do my best to collate any reports and forward them to Paula in such a way as to hopefully speed the diagnostic and repair process. My contact details are:
Packet: G4SPZ @ GB7PZT
E-mail: g4spz@aol.com
I would appreciate it if members would avoid telephoning.
A full report on the work that has been done to keep the node and BBS in service will appear in the Autumn edition of WyrePak Newsletter. Thank you for your patience and continuing support for WyrePak and GB7PZT.
Kind regards and 73,
Phil G4SPZ
WyrePak Chairman and Secretary
The following day, Paula put out these additional comments:
Date: Wed, 18 Aug 2004 09:22:38 +0000
From: g8pzt@gb7pzt.#24.gbr.eu (Paula)
To: WYRPAK
Subject: More problems
Thank you to Phil for his situation report.
The RF link to Wolverhampton is still off, pending repair of the TNC.
All RF ports were off from around 16:15 BST on Tuesday until 09:25 BST Wednesday due to yet another lightning related failure... As part of the diagnostic process after last Thursday's strike, I had moved all the radios onto COM2 of the computer. This didn't resolve the situation, so I began unplugging TNC's until I found the faulty one. The node was working for a few days on COM2, but during routine maintenance yesterday I decided that, since the fault had been found, the original COM1 configuration could be restored....
What I hadn't realised was that, not only was the TNC killed, but the COM1 port was too! After changing back to COM1, I checked that the TNC lights were flashing, and assumed that it was OK. I have now changed back to COM2, and all seems to be working again.
Contrary to popular belief, I have not lost interest in Packet, nor am I putting all my energies into GB3KD. The truth is I have been especially unwell this year, and I don't have much spare energy to devote to hobbies of any sort. Complicated stuff (like Packet) has to wait until I am sufficiently rested to deal with it. I don't check the node and BBS every day, so I rely on other people to let me know when things aren't working. Even so, well over 90 percent of my hobby time is devoted to Packet Radio. It's all the backroom stuff that no-one sees.
There are still co-existence issues to be sorted out between KIDDER and GB3KD. KIDDER's 144.850MHz port still de-senses the repeater a little, and vice versa. This can all be solved, given time, energy and expenditure. I have done my best with the cavity filters available to me, but I still need at least one more, plus some double-screened coax, and some time to get the better rig modified and installed. Cavities are expensive and hard to obtain, large to transport and manhandle etc. These problems can't be solved by a quick trip to the local B&Q, or flashing the plastic at a ham radio emporium. They need lots of time, energy and patience. But they will get done...
73, Paula
This is the first part of the presentation Paula gave at the 2004 Packet Conference in Worcester. It is about a possible global networking scheme for Packet Radio. Although intended for an audience of SysOps, the presentation has been edited slightly but should hopefully give interested readers a taster of what it's all about - Ed.
Introduction
A few years ago, whilst sitting on a beach watching people texting on their mobile phones, it occurred to me that here was a relatively slow wireless message delivery system, which for all its limitations had become a so-called Killer Application. So why couldn't we do something similar with Packet radio? Could text messaging become the Killer app to keep Packet alive? After all, we now had rigs with built-in TNC's, and we had a network which had been moving text around for 15 years or so. All we needed was software and protocols.
I had played with APRS messaging, but it was quite unimpressive. It relied too heavily on part time digipeaters on a single congested frequency, and it had a limited "horizon" of 2 or 3 hops. What we needed was something which could deliver messages reliably over long distances. Something which used the existing network.
Nearly 20 years in the Packet game has taught me that it's no good just talking about new ideas, because nothing will ever get finalised. The only way to get new things accepted is to do them, and show that they work. So I set to work on a scrap of paper there in the sun, and have been quietly beavering away at it ever since.
There were several things to work out, but underlying them all was the need to route packets from a source node to destination node anywhere in the world without any knowledge of the intervening networks. Until that could be done, the rest was academic.
GlobalNet Project Overview
The main focus of my work over the last few years has been to develop the infrastructure software and protocols with which to build a global packet radio network.
The primary goal of such a network was to support packet text messaging, but also to allow any station to connect to any other station without need to know the routing. It will provide new services, and be extensible to support future transport protocols. Hopefully this will encourage and facilitate the development of new applications, as yet undreamed of.
We already have a global network - it's called the Internet. But whilst I am happy to use the Internet where necessary as part of the infrastructure, I firmly believe we should use radio where possible, and of course the "local loop" between the end user and the network access point will be radio. That's the whole point of packet radio.
If we simply connected all the access points points to the Internet, and used TCP/IP over the local loop, we'd have our global network, but it would be totally dependent on the Internet, and we'd simply be consumers of other people's software and protocols. Where's the challenge in that? Let's be different; let's develop our own protocols; experiment, make mistakes, try again. In short, be radio hams!
Limitations of Existing Network
Let's examine some of the limitations of the existing Packet network, so we can see what we'd like from a new network:-
Imagine you're on holiday in Spain, and you have a portable packet station. There's a local node so you'd like to connect back home to Birmingham and tell your mate what a nice time you're having. Or you'd like to check if you've got any packet mail.
Trouble is, the Birmingham node isn't in the nodes table, it's full of EA callsigns instead! If you'd done your planning before you left home, by mapping the network, you would probably be able to node-hop your way back to Birmingham. But if you had no prior knowledge of the network, you could spend a very long time trying to find suitable stepping stones.
Another problem is that each stepping stone has an inactivity timeout, so if the round trip time gets long and you don't keep the data flowing, the link will drop. (This can also be a darned nuisance if you're working a chat server via a node hop).
Ordinary users aren't part of the network; you can't connect directly to them. You have to connect to their local node and connect out on the correct port, assuming you *know* which one they are on at the time.
Finally, NetRom has no formal "datagram" mode. You can't send a single self contained packet from one end user to another, and this stifles the development of new applications.
The Requirements
So now we know what's wrong, let's look at what would be desirable:
Firstly, we need a global addressing and routing scheme which would allow any station to contact any other station in effect "directly", without any intermediate connections and without having to know the routing. For example switch on your packet system, type "CONNECT ZL2VAL" and get connected.
The routing system must be able to support any layer 4 transport protocol, and must include a datagram mode, so we can send single packets. It should include a control message protocol, to allow the software to make decisions and help us diagnose problems.
Finally, any new system must remain compatible with existing hardware, software and protocols. We can't simply sweep everything away and start again. There will always be those who can't or won't change, and other people will have their own ideas of how it should be done.
We can achieve change in an evolutionary manner, little by little. If the changes are good, they will be widely adopted, if not they simply die and the system carries on as before.
Existing Routing Protocols
Can we realistically achieve our aims using any of the existing protocols?
NetRom is very widely used, works well on radio, is easy to understand, and the routing is fairly self-configuring. But with only a finite space for the nodes table, it has a limited horizon. It's not scalable, for instance it couldn't cope with a nodes table of 100,000 nodes. It also has no datagram mode, and doesn't lend itself to direct user to user circuits.
IP on the other hand is globally routable, it allows direct peer to peer circuits, and it supports a datagram protocol. But it was designed for wired networks, so it needs near-perfect radio links. The protocol is also verbose, which makes it inefficient on radio. It's not easy to understand, and in the amateur world has suffered from unreliable and difficult software. Despite my attempts to get an IP router into every node, there isn't a realistic possibility of getting everyone to run IP.
I don't know much about ROSE, other than the fact that it uses addresses which are like telephone numbers. The protocol seems to be secret, but it would appear to have the potential for global routing. However, there's no chance of getting a significant number of sysops to run it.
Flexnet is another secret protocol, but would seem to have similar horizon problems to NetRom, unless the sender specifies the route, which is not acceptable. Once again, if it was going to catch on, it would have done so already.
In my view, secret protocols, however good, are a non-starter, because they don't facilitate expansion, and they don't allow alternative software to be used. It is unrealistic to expect everyone in the world to use the same software.
How To Achieve Our Aims?
Ok, so up to now I seem to have been very negative. Given that we will never get the whole network to use the same software, yet the existing protocols are not suitable, how on earth do we achieve our aims?
The answer I feel is to compromise. In an ideal world we could sweep the whole lot away and start again, but that is not possible. What we *can* do is use the existing NetRom network, by making an extension to NetRom itself. We can then build a new network without breaking the existing one.
Some of the nodes in the NetRom network would also be GlobalNet routers. These nodes would form a network of their own, exchanging GlobalNet traffic through the NetRom network. They could also tunnel GlobalNet through TCP/IP networks.
By making the protocol open and extensible we allow any software author to implement it, experiment with it, and develop it further, thus ensuring maximum penetration.
I want this to be a virtual private network. One of the nice things about Packet Radio is that it's free from all the spamming and jamming and hacking that goes on in the Internet world. Bear that in mind if you think we don't need our own protocols.
The second and final part of Paula's article will appear in the next issue of WyrePak Newsletter - Ed
That's all folks...
I hope you've found something of interest in this edition. Please let me have any comments, and particularly please contact me if you experience any problems with the node or BBS, or links, whether RF or Internet, and I will try to help check and collate them before passing the details to Paula.
Thank you for your continuing interest and support for the Group, and we will try to ensure that the systems remain available for all to enjoy. Kind regards and 73,
Phil G4SPZ
WyrePak Chairman and Secretary
WyrePak Newsletter is compiled, edited and published by Phil Harris CEng MIEE G4SPZ. This issue (c) 24th August 2004