Re: [BPQ32] SGARN
- PE1RDW:Good to hear from you, Andre. You have made an excellent point here about running different classes of data on HF as opposed to VHF/UHF.SHF links. I kind of dimly thought of this some years ago, but never thought of it or expressed it as clearly as you have.How would you feel about the idea of eliminating personal messaging from HF links altogether, and limiting the bulletin traffic there to organizations, not individuals, along with a size limit that would lend itself well to multicast distribution?Perhaps a system where as the frequency goes up, the classes of data and message sizes allowed become more broad along with the available bandwidth, so that by the time you get to SHF, hams would be exchanging live video, etc?Just throwing pasta at the wall here, not knowing if it might stick.73 DE Charles, N5PVL----- Original Message -----From: PE1RDWSent: Sunday, July 07, 2013 12:15 PMSubject: Re: [BPQ32] SGARNYour asumption here has one flaw Charles, namely thinking that everyone wants to communicate globaly, there is no reason not to keep highspeed UHF and SHF highspeed backbones for those that want to talk to people that are in range of those backbones.
like the packet network any nextgeneration network needs to serve 2 needs, one short range realtime and one long range store and forward.
two things that have broken the current bbs network are target rewriting and target ignoring both caused by the more is better mentalety that is common within the ham communitie, everyone thinks that messages need to go as far as posible, you see this with hams that want to use HF for everything but also with node and repeater opperators that put their hardware as high as posible with as much power as posible.
a meganism to prevent this kind of breaking should be included in any future network it saved the APRS network so the need has been proven.
73 Andre PE1RDW
Op 07-07-13 18:10, Charles Brabham schreef:G0OZS:It is gratifying to receive such a well-considered and knowledgeable response, Iain. You made a number of good points there - but I have to say that emulating the internet led the Packet network directly down the path to destruction and I would like to avoid that, this time around.What happened was:* Emulating the internet led directly to comparisons with the internet, creating a "competition with the internet" that the Packet network had no hope in. This in turn led to widespread dissatisfaction with the Packet network that undermined its popularity among hams.* Emulating any wired network presents amateur radio with an impossible task, as wired network models depend heavily upon transparency in its backbone links which can only be accomplished if the backbones are much faster and of much higher capacity than the user access links. - The direct opposite of the case with amateur radio.* Pressure to follow a wired network model then leads to the abandonment of amateur radio, where internet links are depended upon instead of amateur radio - in order to make the model work. In each case where an "internet gateway" is established, amateur radio resources are quickly edged out and discouraged from performing that particular task. ( Long distance links, etc. )In short, a second-generation amateur radio net will need to be structured very differently from wired networks, where a different set of rules apply. ( No high-speed backbone links, for example... No need for expensive infrastructure - and truly global coverage for another. )The problem here is that we simply must innovate instead of emulating. - And even if IP protocol could be made to fit this procrustean bed, there would, in very short order, be attempts by the lazy or the clueless to "route around" those pesky amateur radio links with internet gateways. For this reason alone, I would think that utilization of any established IP protocol would be to invite disaster when after all, the idea is to establish an independent amateur radio network that has nothing whatsoever to do with already established wired networks.Since the reality of our physical capability while utilizing amateur radio is well-known. ( backbone links significantly slower than access links ) then we must consider a new network model, differing classes of data and new expectations that fit our capability. The differing classes of data being perhaps the most important single consideration, here.If possible, a protocol which actively discourages direct links to IP would return the best opportunity for success, for the reasons clearly outlined above.As difficult as it sounds, I have made some progress here and would like to find others, more clever than I who are interested in this project. When hams innovate instead of simply emulating, this is when they stand their best chance to make a unique contribution and thus bring forward the radio art - as amateur radio operators.I guess it does not need to be said that the same limitations that are inherent to global radio communications among hams will, in the near future, affect people who are wanting to communicate among planets, moons and space habitats scattered around the solar system... They too will be working with backbone links that will be significantly slower and less reliable than local and user access links. Working on this problem now is a wonderful opportunity for amateurs to make a worthwhile contribution that will be remembered for many generations hence.So, what I am looking at is the need to develop and establish a new networking model that takes advantage of radio's strength, and does not attempt to tilt at the windmill of its weak points. - A totally new networking model is required, and I saw several places in your reply where you put your finger exactly upon what must be addressed.73 DE Charles, N5PVL----- Original Message -----From: Iain MoffatSent: Sunday, July 07, 2013 9:53 AMSubject: RE: [BPQ32] SGARN
I probably look at this with a RAYNET (UK equivalent of ARES) background so for me the key difference between an amateur radio network and the public internet is autonomy we can establish communication nationwide or worldwide between our own stations with nothing more than power, radio and an antenna whereas the public telephone (and cellphone) networks and the Internet are dependent on large amounts of fixed infrastructure that tends not to stay working in the case of large scale floods (the main concern where I live in the East of England), snowstorms or earthquakes.
As another post has pointed out the USA FCC is unusually liberal in what is allowed in the way of 3rd party traffic or interconnection with commercial communication networks. So for me the key requirements for a network are:
<!--[if !supportLists]-->1. <!--[endif]-->Autonomy it should be possible to establish ad hoc networks with no central infrastructure
<!--[if !supportLists]-->2. <!--[endif]-->Robust It should support reliable message delivery on a hop by hop basis
<!--[if !supportLists]-->3. <!--[endif]-->Open the protocols used should be entirely in the public domain and no proprietary components (e.g. the audio codec in D-Star radios) must be mandated
<!--[if !supportLists]-->4. <!--[endif]-->Adaptable able to use all kinds of physical layers over radio be they point to point VHF/UHF wideband links or narrowband HF
I think much can be learned from TCP/IP in the way that a common layer 3 can be mapped to many different physical layers TCP/IP itself (and indeed anything connection oriented) does not lent itself very well to the long delays inherent in half-duplex communication on a shared medium at low bit rates) and most of my recent work has been to develop emergency communications applications on top of AX 25 UI formerly UIView more recently APRSIS and Xastir. So I think the protocol requirements for an amateur counterpart of the transition from IP V4 to IP V6 are
<!--[if !supportLists]-->1. <!--[endif]-->Clean separation of layer 2 and layer 3 (assuming that the initial layer 2 of choice may be AX 25 UI)
<!--[if !supportLists]-->2. <!--[endif]-->Inherent support for things radio does well like multicasting (why chat through a server if all stations are in simplex range?)
<!--[if !supportLists]-->3. <!--[endif]-->To address the reality of todays world as much security over identity (as apart from message content) as amateur licensing will allow I guess header authentication is OK but payload encryption is not
<!--[if !supportLists]-->4. <!--[endif]-->Distributed network based support for worldwide routing which should not be dependent on single gatekeepers or root servers (so the network wont fragment if a few critical node operators lose interest, become silent keys, or are affected by an emergency at their QTH). Routing needs to be dynamic and hop by hop so end users only need to know their next hop fundamentally that is what IP got right more than its contemporaries IMHO. This is as I see it what needs to be added to the APRS/UI View model to make something more generally useful.
In terms of applications that people still want (and which have a reasonable chance of working as well as the Internet or APRS and being wanted) I think the ones I would be interested in are:
<!--[if !supportLists]-->1. <!--[endif]-->Short message service with acknowledgement (this addresses most record-oriented emergency communications needs where data is entered directly by the Amateur operator)
<!--[if !supportLists]-->2. <!--[endif]-->Unicast reliable file transmission (this addresses emergency communications needs where the user service provides data to be transmitted)
<!--[if !supportLists]-->3. <!--[endif]-->Multicast file distribution with unicast selective retransmission this addresses the equivalent of bulletin distribution in a bandwidth efficient way and is something radio should be inherently good at. In my day job (broadband IPTV networks) I think it is now generally accepted that retransmission is superior to FEC on all but the most error free networks and I see no reason why that wont be even more true for HF radio.
I cant see large numbers of programmers joining the project (which I would like to support within the time constraints imposed by work and family) so it will be necessary to assemble a network using components already available practically I would look at AX25 UI as the layer 2 for VHF and one of the PSK modes as the layer 2 for HF.
I think using callsigns as L2 addresses works well in all existing applications (and avoids the need for the amateur community to invent an addressing scheme and appoint address coordinators as the licensing authority does it for us!). At layer 3 there is a choice between the convenience of using callsigns and the access to ready made software and APIs that comes with IP.
If the avoidance of address coordinators is the priority callsigns should be used for the L3 addresses but the entire protocol stack needs to be developed as custom software (or we just reinvent BPQ or NET-ROM).
If the desire for ready-made externally maintained software wins out over optimisation then the appropriate layer 3 is probably UDP/IP but it will be necessary either to revive interest in network 44 and provide an effective, accessible and dependable way for end users to get addresses, or to just use an RFC 1918 10.x.x.x address range and accept that it isnt routable with the real internet (probably more in line with your goals?) I was at one time an address coordinator for my county until a change of job got in the way (or rather took me 1000 miles away!) so I understand how hard static manual callsign to IP allocation is to keep going and DHCP or an algorithm to generate address based on QTH needs to be part of the network design.
In either case the new network should be developed with an option (and preference) for some kind of header and payload authentication (i.e. IPSEC AH or whole packet checksum concatenated with a shared secret and hashed). UDP/IP also brings with it ready-made routing protocols probably RIP V2 or BGP are the easiest to apply over wide area wireless networks, there being a choice between simplicity on the one hand and power and security on the other.
Application development will only happen if the new network has easy to use and ideally ready-made APIs otherwise there will be no traffic however good the network. I think the availability of standard APIs for UDP/IP and existing hardware and software support for IP over X.25 decides the issue of the addressing scheme and VHF layer 2. At least on Linux a PSK layer 2 can probably be modelled as a serial (SLIP or PPP) interface beneath an IP stack. Simplicity points to SLIP which is rather like KISS anyway.
For me the critical weakness of Amateur TCP on Network 44 when I was involved about 15 years ago was that the addresses were allocated and sub allocated on a geographic basis to countries, states and counties (or equivalents) so end users depended on having an active local address administrator to be able to get on air. I think any new network needs to be allocated blocks of RFC1918 addresses based on communities of interest (likely to be distinguished by different frequencies anyway) I would suggest using 10.0.0.0/8 for global allocations and leaving 22.214.171.124/12 for national use and 192.168.0.0/16 for ad hoc local networks with no wider connectivity. There is the potential to learn from 20 years of IP V4 evolution and use network/port address translation between the local (VHF) and global (HF) networks to make local IP addresses reusable, which was never done when I was involved in network 44.
There is no unique allocation of class D multicast addresses in the real world so I see no harm in (re)using them on air although (at least on HF) they need to be globally coordinated.
In terms of routing RIP V2 is fairly easy (and has become more secure if hashes are used as per RFC 4822) and being based on multicast to a well known IP V4 address is potentially radio friendly. This is one area where custom radio specific development might be of benefit however
73 de G0OZS
Hi Dave, glad I could help.
I found your package in the mail when I got home today and I just installed it.
Powered up and it worked. I didn't even have to reset the BBS or node.
Thank you very much
On 7/6/2013 2:04 PM, Mike Nettles wrote:
Hi Ron, yes that is it, JKISS. I bought a TNC-MB96 (A Tiny2 with 9600baud) off Ebay a few years ago just because it had a 9600 baud modem. It had a push button switch on the back to switch between DED and Paccomm firmware. I ended up putting JKISS and the Paccomm software on the same eprom and using it that way. The Paccomm firmware had GPS support and I thought I might need that one day.
----- Original Message -----
From: Ron Stordahl
Sent: Saturday, July 06, 2013 10:31 AM
Subject: Re: [BPQ32] Re: TNC Reset
Mike / Dave
I assume you meant 'JKISS' eprom. I have been using these in MFJ1720C's forever. No resetting needed. My 'coin' (lithium) batteries are likely dead, but it doesn't matter. Just replace the TNC2 eprom with JKISS and never have any reset issues.
Dave, I can burn you a KISS Eprom if you want. I use one in one of my MFJ's and it works fine with BPQ32. Let me know and I'll get it in the mail on Monday.
----- Original Message -----
From: Dave Webb
Sent: Saturday, July 06, 2013 9:34 AM
Subject: Re: [BPQ32] Re: TNC Reset
Thanks for all the replies.
I have found that sometimes when I unplug or turn off the TNC which happens to be an MFJ 1270C, it drops out of kiss mode but retains all the other parms, so it appears the BU Batt is still good.
I have started by getting an extension cord and hooking the TNC power up to the UPS that I use for the computer. If that doesn't work, I'll start going through each of all your suggestions until I get this fixed.
I use Hyperterm in XP to bring it into KISS mode using KISS ON then RESTART.
I have Outpost and use it's tools for working with BPQ over my LAN using my Laptop which has Win8.
The HTML access it a wonderful tool when I am traveling. It's almost like being at the console. The only thing missing is the ability to restart everything in the event the BBS locks up. This has happened twice to me in the past where the node continued to work and the BBS locked up. I haven't seen it happen since the latest upgrade though, which is good.
On 7/6/2013 7:38 AM, KU4GW Cliff wrote:
When my MFJ 1270B TNC 2 drops out of KISS mode like it has a couple times, just the other day when I called my daughter and had her to unhook coaxes on my HF station because of a approaching thunderstorm, she also unplugged the TNC power cord from the wall and when I restarted everything when I got home it was out of KISS mode and wouldn't connect to anything on my RF port 1. KF4LLF Seth showed me this a while back. You can download Outpost Packet Message Manager and go to the start menu in Windows under All Programs and click on Outpost, Ipserial, and then just type KISS ON in the window and hit the enter key and it puts the TNC back in KISS mode. You don't actually see what your typing when you type KISS ON, but after you do and hit enter it displays KISS mode on in the Outpost Ipserial window. Then just close Outpost and restart the BPQ software. Works like a charm!
--- In BPQ32@yahoogroups.com, Dave Webb <druliefw@...> wrote:
> My TNC 2 which is on the VHF port, keeps dropping out of KISS mode.
> Is there any way to reset the TNC without taking down the whole BBS?