On 6/27/13 2:26 PM, K7VE - John wrote:
Great idea - wrong platform. Cisco specific solutions aren't reachable for many.
Look at Linux (Raspberry Pi) solutions or powerful, affordable routers like MIkroTik and common tunneling protocols like OpenVPN, L2TP, GRE, etc.
I take issue with that. MikroTik is just as much of a closed platform as Cisco/JNPR/ALU/Fond-cade/etc.
Cisco is ubiquitous, to a lesser extent Juniper (though I have to favor ALU for MPLS/core!).
I'd say what we need is an open standards based solution that works across linux/cisco/jnpr (maybe an o-series? :)
Something custom protocol wise to tie the 44net together is not ideal either as we cannot expect the big router vendors to support amprnet protocols. I know I'm able to slap a 1ru router (ie c2[6-9]00) in lots of places with good connectivity I could never put a server. I belive there is a way to do this via NHRP with BGP. I know I have a customer doing something like this. Since we don't need crypto for 44net I suspect it would work for us.
just my .02
73's
I followed this topic with interest, but I see it in a different perspective.
It seems that many of the people involved in this topic see the picture from a glass tower. Cisco and Juniper may be widespread at infrastructure/provider level, but we should also take in account the fact that not all the ampr routing will be implementable at provider level.
For example in Romania we have 3 major providers, covering more than 95% of the end user market. This competition resulted in extreme low prices for high speed internet access (about 10 EUR/month for a 50Mbps fiber optics acces or a 20Mbps ADSL link) but at home user level, some together with free mobile networking and free nation wide hotspot access. On the other hand more advanced features seen as "commercial" and "corporate" features come at extremly high prices. Just a fixed IP will pull another 2-3 EUR from ones pocket (if even available to home users for a specific ISP), not speaking of BGP, which jumps up at the levels of hundreds EUR/month. Also, the ISPs totally reluctant in implementing features for our "obscure" hobbies lke amateur radio which doesn't bring them major profits or a large number of new customers.
In this light, is not necessary a matter of equipment, which is a one time investment, but an issue of service availability. Any protocol for interlinking ampr islands would need to be encapsulated, routable and able to run over tunnels, otherwise the only option for us (I speak for YO) will be to remain stucked with the IPIP tunnels forever. On the other hand, universities, which usually are the front runners in such endeavors efectly lost their interest for ham radio so advanced endpoints of access which would be possible here are actually not available.. So today we are in a sad situation. Ampr net in YO is dying: 3 gateways oficially left, with one of them hanging on a dynamic IP with no actual services, one without a working gateway, and only my home system having a working GW, with virtual no users.
Packet radio found APRS and survives, but unless we find a clear advantage over existing internet services, the 44 network will disappear.
Marius, YO2LOJ
Recently I too, followed this topic with really great concern...
Very similar but of course not identical situation like in YO we have here, in Poland - 44net is almost dead!
More and more spreading availability of high speed Internet access, even via mobile provider like in my instance (150Mbips Up / 50Mbips Down), is simply killing sense of 44net existence. One may ask: "Are we still radioamateurs, as we were let say, 10 years ago?"
Well, I'm playing with rip44d, AMPRNet via VPN, FBB, FPAC, DXSpider, convers server, all running on Raspberry Pi behind own router. I've static IP, 44net addresses and all stuff needed. But that's all... To be candid I do not see very much of use, except keeping myself a bit busy. Which I like very much, from the other hand... What else? Good question.
My own one cent to the basket...
Best regards from Gdynia, Poland Tom - sp2lob
Right. Now that I am here, what can I do?
I would like to see something that can link ATV repeaters together. I am thinking hdmi to IP, using Linux and other off the shelf hardware, and with some TX/RX logic. If you think Cisco is pricy, just look at some commercial IP encoders. Passing video streams in a time of emergency without expensive video conferencing hardware would be nice.
Is there a common list of services currently available on the 44net?
Greetings list members;
I concur with what Marius writes below;
On Sun, 2013-06-30 at 10:38 +0300, Marius Petrescu wrote:
Packet radio found APRS and survives, but unless we find a clear advantage over existing internet services, the 44 network will disappear.
We have always had two issues at hand: 1) network administration/engineering 2) application/sysadmin
While this thread appears to discuss some very valid solutions for #1, we often concentrate too much of our thinking in this and ignore solutions for #2, and it's somewhat (from what I've seen) cut off our toes.
Our knowledge base and resources for network engineering is top-notch as proven by the various suggestions in this thread but none appear to address the fact that "hey, we built this superb network infrastructure for you (the end user) but we haven't given you any new services to use it with". The end user, many who aren't as computer literate as we are, will see this as possibly having to make further investments into an already dying system to which most who used to use it have become SKs or simply have no desire to reinvest into something they've already decided to leave packet as a mode of operation.
We need something positive in which we can not only provide the easiest solution for network connectivity with the lowest investment costs (none if possible!) to the end user with some sort of enhanced services for them that's cross-platform compatable. We also need to look at what's already in place and somehow enhance them so that the typical end user can use their "natural resources" from their OS and/or web browser on packet to do all that they do now in a dumb terminal screen. Without this, we can build the most robust network in the galaxy, but what good would it do without end points making use of it? An ISP for example would have no users if the users couldn't do anything on it or have been forced to use the same limited resources for years.
I have been testing the PPTP offering Jesse's been experimenting with and it's worked very well and at 100% performance every time I've rebooted my machine. Configuration for the end user requires only 4 simple steps (gateway, username, password, no forced data compression) it comes right up. This on high speed such as 802.11 would be very attractive I would think to an end user with possibly little investment cost in gear (as previously noted).
IP under FlexNet is very slick as well and with it's dynamic auto-routing of ax25 destinations helps keep the virtual circuit required alive to pass IP through the best possible RF path available... similar to how BGP/OSPF/etc perform on the internet backhauls... and even at slower speeds such as 1k2 baud, you can still transmit SMTP based mail at a somewhat reasonable amount of time even while FBB systems are autoforwarding. While this scenario may not be ideal for our discussions... it works and it works well for what it does. I've even done web browsing with limited graphics over 1k2 baud/Flex without issue (obviously higher speeds is nicer and 802.11 would resolve that!) but again, the services is what the end-user driving force is as APRS has proven and since the IP stack with standard application based protocols appears to be cross-platform compatable, that makes it very attractive.
Long story short; let's look at the "whole" picture not just the "big" picture of building a network infrastructure while we're at it.
I think adding PPTP to the mix would really lower the bar of entry in connecting HSMM/Packet islands (as that is clearly the future). It could then be packaged up and written so that people can setup their Mesh Router to other islands via VPN to get over the "Chicken and the Egg" effect of creating a whole new network which clearly is where we stand today.
But I would like to point out that PPTP does not allow true network bridging (Layer 2). Thusly, maybe something using L2TP or OpenVPN in Bridge mode along with NHRP/DMVPN on those who host remote connectivity to these smaller islands. This would allow for a full stack of applications (IPv4/IPv6) along with enabling Multicast across these islands which fits into the nature of radio which is broadcast based.
On Sun, Jun 30, 2013 at 5:09 AM, Brian Rogers n1uro@gmx.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Greetings list members;
I concur with what Marius writes below;
On Sun, 2013-06-30 at 10:38 +0300, Marius Petrescu wrote:
Packet radio found APRS and survives, but unless we find a clear advantage over existing internet services, the 44 network will disappear.
We have always had two issues at hand:
- network administration/engineering
- application/sysadmin
While this thread appears to discuss some very valid solutions for #1, we often concentrate too much of our thinking in this and ignore solutions for #2, and it's somewhat (from what I've seen) cut off our toes.
Our knowledge base and resources for network engineering is top-notch as proven by the various suggestions in this thread but none appear to address the fact that "hey, we built this superb network infrastructure for you (the end user) but we haven't given you any new services to use it with". The end user, many who aren't as computer literate as we are, will see this as possibly having to make further investments into an already dying system to which most who used to use it have become SKs or simply have no desire to reinvest into something they've already decided to leave packet as a mode of operation.
We need something positive in which we can not only provide the easiest solution for network connectivity with the lowest investment costs (none if possible!) to the end user with some sort of enhanced services for them that's cross-platform compatable. We also need to look at what's already in place and somehow enhance them so that the typical end user can use their "natural resources" from their OS and/or web browser on packet to do all that they do now in a dumb terminal screen. Without this, we can build the most robust network in the galaxy, but what good would it do without end points making use of it? An ISP for example would have no users if the users couldn't do anything on it or have been forced to use the same limited resources for years.
I have been testing the PPTP offering Jesse's been experimenting with and it's worked very well and at 100% performance every time I've rebooted my machine. Configuration for the end user requires only 4 simple steps (gateway, username, password, no forced data compression) it comes right up. This on high speed such as 802.11 would be very attractive I would think to an end user with possibly little investment cost in gear (as previously noted).
IP under FlexNet is very slick as well and with it's dynamic auto-routing of ax25 destinations helps keep the virtual circuit required alive to pass IP through the best possible RF path available... similar to how BGP/OSPF/etc perform on the internet backhauls... and even at slower speeds such as 1k2 baud, you can still transmit SMTP based mail at a somewhat reasonable amount of time even while FBB systems are autoforwarding. While this scenario may not be ideal for our discussions... it works and it works well for what it does. I've even done web browsing with limited graphics over 1k2 baud/Flex without issue (obviously higher speeds is nicer and 802.11 would resolve that!) but again, the services is what the end-user driving force is as APRS has proven and since the IP stack with standard application based protocols appears to be cross-platform compatable, that makes it very attractive.
Long story short; let's look at the "whole" picture not just the "big" picture of building a network infrastructure while we're at it.
-- 73 de Brian Rogers - N1URO email: n1uro@n1uro.ampr.org Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Deleware, all New England, and New Jersey.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Now talking about services available... What could we possible offer to stimulate fellow hams to support the 44 network despite commercial available internet being widely available?
A modern idea comes into mind: free cloud storage/computing - available only on 44 addresses. Could this be a possible life raft?
Marius, YO2LOJ
IP Broadcasting. We've lived too long in a world where it's all been Unicast traffic that we're totally alien to idea of multicast. Opening the door to one-to-many sorts of chatting, file/data distribution, video/webcam streaming, etc...
On Sun, Jun 30, 2013 at 1:02 PM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Now talking about services available... What could we possible offer to stimulate fellow hams to support the 44 network despite commercial available internet being widely available?
A modern idea comes into mind: free cloud storage/computing - available only on 44 addresses. Could this be a possible life raft?
Marius, YO2LOJ
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Hello Marius;
On Sun, 2013-06-30 at 23:02 +0300, Marius Petrescu wrote:
Now talking about services available... What could we possible offer to stimulate fellow hams to support the 44 network despite commercial available internet being widely available?
My guess would be to poll those who you would intend on serving connectivity to and see what it would be you could host/provide that *would* make them want to become active again. Unless mindreading is possible... ask the potential end-points :)
Hello Don;
On Sun, 2013-06-30 at 12:43 -0700, Don Fanning wrote:
I think adding PPTP to the mix would really lower the bar of entry in connecting HSMM/Packet islands (as that is clearly the future). It could then be packaged up and written so that people can setup their Mesh Router to other islands via VPN to get over the "Chicken and the Egg" effect of creating a whole new network which clearly is where we stand today.
While that may not be the best solution (and certainly not the only) we need to keep in mind, a good amount of those we would serve 44/8 connectivity to are probably retired, already done what they want to do, and don't want to fuss with networking protocols. Does that mean we need to shun out our fellow hams? A 70 yr old who's looking to "enjoy" the hobby and has the time to do such could care less about IPv4 vs 6, OpenVPN vs L2TP, and so on. They're probably on a fixed income, purchased just about all they want to purchase and really don't desire to learn any more than they already have. Does that mean we have to close our services down to these fellow hams, many who have already spent time elmering others into the hobby?
Some comments I've heard when polling possible end users is "if it's not in my windows install I don't want to be bothered". That's what makes PPTP attractive. There's web apps (since most of us run a web site) available for end points to telnet into your system, and so on. The security part of it is on us.
The younger hams and especially those with more of a 'geek' side to them would want to dive into the more complicated solutions... and that's fine. From a network point of view our challenge is to try and provide all we can to the entire amateur community while not harming the public services we provide to the entire community. That challenge does not reside only at the lower layers, we have to consider all layers, methods, etc. That's what I was trying to relay in my earlier note.
Hello Don;
Hi Brian.
While that may not be the best solution (and certainly not the only) we need to keep in mind, a good amount of those we would serve 44/8 connectivity to are probably retired, already done what they want to do, and don't want to fuss with networking protocols.
Completely agree. But even AX.25 has a learning curve. However, I'm all for reducing the curve whenever possible.
Does that mean we need to shun out our fellow hams? A 70 yr old who's looking to "enjoy" the hobby and has the time to do such could care less about IPv4 vs 6, OpenVPN vs L2TP, and so on.
Nope. OpenVPN is free and L2TP is the second protocol that comes standard with every Windows Machine dating back to Win98/NT.
They're probably on a fixed income, purchased just about all they want to purchase and really don't desire to learn any more than they already have. Does that mean we have to close our services down to these fellow hams, many who have already spent time elmering others into the hobby?
That's what great about what I mentioned. Both of these are free and shouldn't cost a single nickel more because they already have it or can obtain it for free. Both can be setup very simply and the documentation would only consist of maybe 2 pages of information including screen shots.
Some comments I've heard when polling possible end users is "if it's not in my windows install I don't want to be bothered". That's what makes PPTP attractive. There's web apps (since most of us run a web site) available for end points to telnet into your system, and so on. The security part of it is on us.
I'd agree that PPTP has a place. And if you envision your network segment only using IP based TCP/UDP applications, then it's not an issue. But Multicast will not work over PPTP unless additional pieces like a IGMP proxy or other services are added which would increase complexity to the gateway nodes. And as you say, some people in the hobby may not want to muck with it. Heck, I'm still having difficulty getting NET/ROM working over 44net but that's another subject. :)
Ultimately at the end of the day, what I am proposing is fairly simple to setup even for the blinking 12:00 crowd but would allow for the network to be agnostic in protocol or application. Again, PPTP may be the right choice for a particular situation but for anyone setting up a PPTP gateway, it's not that much more of a reach to include other protocols such as L2TP or OpenVPN. On Windows RRAS machines it's turned on by default.
The younger hams and especially those with more of a 'geek' side to them would want to dive into the more complicated solutions... and that's fine. From a network point of view our challenge is to try and provide all we can to the entire amateur community while not harming the public services we provide to the entire community. That challenge does not reside only at the lower layers, we have to consider all layers, methods, etc. That's what I was trying to relay in my earlier note.
As a not so young ham (has it really been 20 years since I got my ticket?) I relish simplicity. Having been the computer elmer to my ham elmers it's taught me that the less moving parts, the easier it is to maintain. Certainly as one who barely remembers a time before home computers, I definitely have seen the complex curve associated with computing technology and tho I am a Cisco person in my day job (CCNP), I wouldn't want to wish that upon everyone as that is the reason I get paid the big bucks (Insert billing joke here). I don't want to add unnecessary complexity unless it's beneficial in some way.
I agree that we need to keep the bar of entry as low as possible. I would love to see a world where I can plug in a USB stick and be connected to 44net even if i'm out in the woods or wherever we are because we have the capability to make it happen through our technology and licensing. As it sits now, I am in a island because of exactly the reasons others have mentioned in regards to network density - there is no one within range to peer with. And most all of us agree that 1200/9600 bps should be left in the past where possible. But building a new or reimagined network should also mean that we are willing to accept new technology using what we've learned from our experiences. As this distribution list is mainly focused on the network itself, this has been what I have been discussing. The applications used on the network are completely up to the user's imagination or desire. But we should build a network that allows the user to utilize the full capabilities of their imagination. Not just Unicast TCP/UDP.
de Don (KL7EET)
-
Brian Rogers -
Bryan Fields -
Don Fanning -
Jesse Hindmarsh -
Marius Petrescu -
sp2lob＠tlen.pl