44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] 44net problems - was: 44net cool toys
by Bryan Fields 23 Mar '14

23 Mar '14

On 3/22/14, 6:10 PM, Neil Johnson wrote: > - Be sure read up on BCP38 http://tools.ietf.org/html/bcp38 to > understand why your local ISP won't (and shouldn't) let you source > traffic from IP addresses other than theirs It's called peering. I'm not expecting the end users who don't understand with a /29 to get on with it. > - Explain how you would justify and obtain stable funding to get (and > keep) an ASN for the 44-net address space ($500 initial, $100/yr > maintenance from ARIN). An ASN is necessary for multi-homing and BGP > routing. I've stated I'd donate an ASN to AMPR. Money where my mouth is, etc. AFAIK AMPR is not 501c3 with the IRS, so this is going to hold donations back. > - Explain to me what financial incentive a commercial ISP has to > routing (or peering with) 44-net address space for a small number of > customers. It's cool, lots of groups would peer with AMPRnet. We'd have to get people to run gateways in different places around the world. Might need to start talking to a few more people at NANOG/xNOG's but it's like finding a good repeater site, you have to pound the pavement and talk to people. Law of averages we'd find a half dozen companies that would do it. The legitimacy of a 501c3 status would go a long way to help this. > > - As for using VPN's, explain how to pay for and maintain the > appropriate size server(s) to host CPU-intensive VPN (IPSec and GRE) > end-points. Don't know why we'd need IPSEC on the backbone, GRE would be fine. GRE is a hardware operation in most routers (I can only speak to ALU 7x50), but really we're not pushing 100mbit/s, so it's a moot point. A linux/bsd box can do it. > After understanding all the nuances of 44-net, I find that the mesh > of IP-IP tunnels and the rip44d daemon are actually quite an elegant > solution to the limitations and constraints we have to work with. It's a dirty hack IMO. There is no reason we can't build a virtual backbone that would provide 44net space to end users and give the users redundant (or better!) routes to the internet. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

4 3

YV Gateway on air (again)
by Gabriel Medinas 23 Mar '14

23 Mar '14

Hello fellows friends, now after an extended test period and when my office allowed me time, I could achieve put online both YV gateways " yv5kxe.ampr.org" and "yv5sat.ampr.org" These systems have access to VHF packet radio network YVNET 145.010 Mhz and are currently in the capital Caracas in different locations, the systems are under Linux Slackware (for now), to access them please send my a email with your login and password to place you in the ftpusers. The whole problem of the update via RIP2 was the ISP modem that blocks multicast RIP??? although saw the RIP packets incoming on JNOS monitor screen from UCSD amprgw. The modem with this problem is SENDTEL ADSL2 + Router MS8-8817 which I have changed to another ADSL brand (StartBridge) now working perfect the encapsulation and RIP update. Other experience to share....thanks and regards 73 de Gabriel YV5KXE. Venezuela Amprnet

2 1

Re: [44net] 44net problems - was: 44net cool toys
by Geoff Joy 22 Mar '14

22 Mar '14

On Sat, 22 Mar 2014 19:33:14 +0100, YT9TP Pedja <yt9tp(a)uzice.net> wrote: >On 22.3.2014 16:14, Geoff Joy wrote: > >> Wiki's are a collective effort, what have you done to fix the flaws >> you see there? Have you signed on as a Wiki editor? Have you written >> articles for inclusion on that Wiki? Links go stale, there has to be >> an "ugly bag of mostly water" behind the keyboard to keep a document >> tree fresh and healthy, otherwise off-site links go bad when someone >> drops dead or an organization folds. What are you doing in YOUR spare >> time. >> >> I see a whole lot of room for improvement and a whole lot of >> networking experts who can "advance the state of the art" but who >> don't seem to be inclined to actually publish what they know. >> >> What I see above from both of you is "this is a mess, someone needs to >> clean it up, but that someone isn't going to be me". I must boldly >> state that if you have the time to discern a problem and criticize a >> state of affairs, you have the time to take ownership of that problem >> and fix it. > > >I think you are on wrong track. > You might be right. >Don't you see the pattern. People who consider themselves knowledgeable >about networking want to get involved in 44net but they cannot >understand it because there is lack of proper documentation. > Those who understand networking would be most likely to be able to write proper documentation for 44net since the protocols involved are no different than any other internet. AX.25 is nothing more than a modified X.25. The only thing that changes is the medium of transmission and the latencies. >If they cannot understand and ask for better documentation, so they >cannot learn, they are the last persons that should be advised to write >that documentation. I perceived hams criticizing other hams for not being "friendly" to newcomers, I have been a victim of unfriendly hams myself in the past and went out of my way to create a new environment in response to that. My Elmer was the father of a high school friend who took time out at the end of his workday to mentor us in Morse code. I didn't go on to get my license until college, however. > >Documentation should be written by people who do have very good >knowledge and experience with 44net. > I agree. And that experience best comes with experimentation. But is 44net so different that it's a completely different environment than hardwired networking? I learned what I know about the protocols by installing JNOS on a PC and poking and sniffing packets on air when Windows didn't have a TCP/IP stack. Why is the reverse so difficult? Current Wifi technology follows directly from the original wireless development hams pioneered. Even SSID comes from us. The original development follows directly from the University of Hawaii's experiments with RF networking, which was well documented. Most of this isn't "webified", it's all plain text on the FTP site. But yes, my generation has let the new generation down, we left a plain text legacy where everyone wants it all on a searchable Wiki and color pictures. >73 >Pedja YT9TP > >p.s. I am posting this directly to you, besides sending it on the list >as my message cannot go through the list - almost all my messages return >back marked as blacklisted. > I'm posting my reply directly and also to the list so perhaps someone can review the list logs and fix the rejection. Thanks for your input. -- Geoff Joy - ke6qh - AmprNet IP Address Coordinator for San Bernardino & Riverside Counties. geoff(a)windomeister.com

2 2

44net problems
by Steve Wright 22 Mar '14

22 Mar '14

> #authors identity deliberately removed >Wiki's are a collective effort, what have you done to fix the flaws >you see there? Have you signed on as a Wiki editor? Have you written >articles for inclusion on that Wiki? Links go stale, there has to be >an "ugly bag of mostly water" behind the keyboard to keep a document >tree fresh and healthy, otherwise off-site links go bad when someone >drops dead or an organization folds. What are you doing in YOUR spare >time. Well, I just spent two days researching at typing this review document. Perhaps you think I idly blew it out of my armpit? I'm good, but not that good. [annoyed rant deleted] I'm a 44net newbie as well, but I'm not a newbie at accurately documenting "the problem", or "the global solution". Ask me to stop at any time. As such, I will document what I use but I am not in a position to do the rest. Steve

1 0

Re: [44net] 44net problems - was: 44net cool toys
by Steve Wright 22 Mar '14

22 Mar '14

Ok here's my opinion. Technically, it's difficult for prospective members to connect a 44 subnet of any type, using any method. It is not clear at all how this is ACTUALLY done or what options are available. The wiki should be the authoritative document, but ; 1.) The main page is all about how to edit the wiki and a logo competition, and ONE LINE on how to set up a gateway - which the whole reason people went to the wiki. 2.) The "Setting_up_a_gateway_on_Linux" wiki page has a broken link leading to "common instructions for setting up a gateway", inviting newcomers to consider that there ARE NO such instructions, at which point they'll probably completely give up. 3.) The three main options, munge script, rip44d.pl and rip44.c are not stated clearly, nor are there links to any such subsection, nor are these options grouped from the users' perspective - namely their chosen platform, be it JNOS, x86 Linux, OpenWRT, or METARouter. 4.) There's no real index to what people are actually DOING over the 44net, and people ARE DOING some cool stuff. If there were some page in the wiki where people shared what they were making, then others might duplicate their efforts. Sysadmins on the portal are reluctant to issue /24s, when there's lots and lots available. The portals' "Law and Jurisdiction" section in the terms and conditions insults the user. Most of the rest of that section is pretty unsavoury too. WISPs and others who want to peer don't have access to any toolkit or support. Some stuff in the portal doesn't (or didn't) work, and it's not clear which. There's not really an apparent reason WHY newcomers might even WANT to number a network with 44. It's simpler to just throw a DHCP server at an interface and add some routing - easy peasy, why number the network with 44, and if they did - HOW to do that? It's not really clear to network builders, that they can actually number up with 44 right now, and worry about connecting to other 44/xx Networks later when they're ready. If they want to expose several 44/24's to the wild internet, then that doesn't really affect anyone else but themselves. All this tunnelling really is an unstable mess. Apart from allowing the wild internet to connect inbound, why not just route the whole thing? HTH, Steve -- Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers +64 21 040 5067

8 8

Re: [44net] 44net cool toys
by Steve Wright 20 Mar '14

20 Mar '14

Lets keep this discussion going - we can change things. Quoting as required; > Ubiquiti & Mikrotik are great for building highspeed wireless ip networks Yup I have three APs on 2.4 and another three on 5.8 on a mountain top site. No 44 on it, because the routing daemon doesn't work on Mikrotik. And the gear costs almost nothing - compare a "new transceiver" for these bands compared to a "new transceiver" for any other band. > If we could change the demographics of the hobby that would help. I take your point, but you get on PSK31 and have a look at the age demographic there - be prepared to be shocked to see many of these operators over 60y. > You have to have something first to entice them. Agreed. We need cool toys! And there ARE PLENTY.. As in the next paragraph - engage with these groups and offer them our product. > How many people even know about the 44net > space? Maybe we need to reach out to; > >-The broadband-hamnet developers - presently >they use 10.X.X.X address space > > -VOIP developers, like IRLP, Echolink, and Allstar. > > -Hams who run internet servers, like qsl.net, etc > I think your suggestion is paramount. I submit this is a way forward, if not THE way forward. > Then there is the issue of how to integrate 44net into your home network. Agree completely. Do we need a dial-in PPP server for those who "just want a 44/32" ? >The second problem is regulatory. Data bandwidth issues, content issues.. all deturants. I agree, but the problem is not what quite you suggest here. I think we need to ditch this attitude of heavily self-regulating ourselves. Hams have traditionally held this concept dear - one of overtly interpreting the rules heavily in our own disfavor. I don't think we do ourselves any positive service at all with this, particularly so when the result is we now stop and do nothing at all because of our own attitude. If some user does something inappropriate, it is normal to warn once then revoke access for some time - a normal and acceptable approach anywhere. I think we should free our attitude up a little. There have been issues of bandwidth as well, but these days a VDSL or fibre connection isn't expensive, and neither is 100G of data to go with it. Steve -- Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers +64 21 040 5067

7 6

OT: FCC Invites Public Comment on Petition Affecting 10-10.5 GHz Band
by Bryan Fields 19 Mar '14

19 Mar '14

Sorry for the OT, but this does effect us all in the US. The FCC has invited public comment on a Petition for Rule Making (RM-11715) that would make a significant portion of the 10.0 to 10.5 GHz band available for wireless broadband services. The Petition by Mimosa Networks Inc proposes a band plan for 10.0 to 10.5 GHz that, it says, would protect frequencies most often used by radio amateurs. The petition hinges on FCC adoption of rule changes that would put the 10 GHz band under Subpart Z of the Commission’s Part 90 rules. Subpart Z currently sets out regulations governing wireless licensing, technical standards, and operational standards in the 3650 to 3700 MHz band. I've made my comments on this, and would invite other hams to do so. I feel I'm uniquely qualified to see this from both side as I owned a WISP before. http://mimosa.co/support-our-petition.html is the link mimosa networks has on how to comment. I'd encourage you to comment on this, as it will negatively affect the amateur radio allocation on the most popular microwave band. Feel free to steal from my comments below: Comments on RM-11715 Petition for Rulemaking from Mimosa Networks regarding the 10.0 to 10.5 GHz band. I am uniquely qualified to comment on this petition as both a licensed Amateur Radio operator (callsign KB9MCI), and former owner of a Wireless Internet Service Provider, Illiana Internet LLC from 2000-2006. Currently I work as Consulting Engineer in the Cellular and Service Provider space. I have built and operated many amateur radio microwave stations in the 3CM (10 GHz) band. Wireless Internet Service Providers (WISPs) present themselves as a group providing Internet to the rural and underserved communities of the USA. To an extent this is true, however their services are not a substitute for fiber and wire line carriers. WISP’s are typically a small business, lacking the capital and skilled engineers needed for day-to-day operation of a multi-site wireless network. There is little incentive to design with good RF engineering practices, as most WISP’s lack the ability to hire competent RF engineers, and supply them with the tools they would need (Spectrum analyzer, test equipment, etc.). This lack of RF engineering knowledge leads to inevitable interference between competing operators, and other users of the ISM and UNI bands. As interference goes up, power and antenna size invariable increases (even exceeding the EIRP FCC rules) to maintain service to their customers. This cannot be allowed to happen in a band shared with weak signal users such as the Amateur Radio Service. I am in favor of more spectrum for WISP’s and ideally this would be sub 7 GHz, however if it must be shared spectrum, it needs to be shared with users that can tolerate a higher noise floor. Weak signal services such as amateur radio or GPS satellite should not share with such use. Spectrum should be aligned with international users as well in my opinion; a 10GHz band use under the Mimosa proposal would be incompatible with this. The requirements in the 10.0 to 10.5 GHz band as proposed allow a non-restricted contention based protocol. This should not be permitted in any case. The amateur radio use of this band is based on such contention-based protocols (i.e. listening before transmitting). This will encourage WISP users of this band to run hotter systems to “talk” over competing systems not unlike what has happened in the ISM and UNI bands. This need for a restricted contention-based protocol must be retained in any case. DFS is proposed to avoid co-channel operation with only radar systems. This excludes the amateur use of these bands. Further threshold is -64 dBm, which is well above level amateur systems operate at. Amateur use of the 10 GHz band is not “strong signal” fixed operations as point-to-point microwave use is. Rather, Amateur use is characterized by weak signals and “pushing the envelope” of RF path link budget. Amateurs may employ CW (A1A), SSB (J3E), FM (F3E) and other emissions at these frequencies. DFS needs to be a requirement for not only radar systems, but amateur systems as well. Even with DFS as a requirement the proliferation of cheap non-carrier grade WISP equipment from foreign vendors has the potential to be “unlocked” with DFS and even the proposed protected bands at 10.350-10.370 and 10.450-10.500 GHz being illegally used by untrained operators. Further, most equipment can be “hacked” to use such restricted channels. This last point is not to be dismissed, as there have been numerous actions by the FCC of 5.4 GHz interference from WISP’s to TDWR RADAR. (http://www.fcc.gov/encyclopedia/weather-radar-interference-enforcement) Others commenting in favor of this NPRM have been the recipient of Notices of Liability and Fines for repeated violations of the requirements to operate legally in the 5.4 GHz band (ex. EB-09-SJ-0014 – Aeronet Wireless Broadband, San Juan, PR). What assurance can these operators give the commission and the amateur radio community that they will not do this again? If this NPRM is implemented and such interference effects amateur stations it would be almost impossible for the commission to enforce, as amateur stations are not fixed or as critical as TDWR RADAR stations are. This would be an incompatible use. In 10 GHz amateur operation using narrow bandwidth useful signals may be below the -174 dBm/hz common minimum discernible signal noise floor, especially in amateur satellite service, or in Earth Moon Earth (EME) where signals are reflected off the moon. Further for DFS to work, these narrow band signals would need to be detected by a receiver with a 20 MHz receive bandwidth. In these wide band commodity receivers an amateur radio signal at -130 dBm would not be detected even in the absence of signal. As DFS is not required to act on a signal less than -64 dBm most amateur radio communication use would not trigger it. Even more so in the amateur satellite service from 10.450-10.500 GHz, severe interference would be caused by normal operations by the WISP radios raising the effective noise floor. An amateur satellite receiver has a wide band pre-amplifier, such strong signals even 20 MHz removed from the intended signal would require expensive and high signal loss pre-selective filters. Would Mimosa networks intend to pay for these filters for every amateur radio receiver? What of current satellite receivers in orbit that cannot be retrofitted? The proposed strong signal use adjacent to the Amateur Satellite service at 10.450-10.500 GHz by channel 21 is without technical precedent. A receiver on a satellite would hear every strong broadband transmitter in its footprint as it passes over the US. This interference would cause amateur radio operators far removed from the transmitter to be unable to communicate through satellites they had previously been able to communicate through. I would refer to the LightSquared Petition to the FCC for use of ancillary terrestrial component equipment in its spectrum and the impact on GPS receivers. Based on these facts I would ask the Commission to deny the Mimosa petition. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] 44net cool toys - not
by kb9mwr＠gmail.com 19 Mar '14

19 Mar '14

>What needs to change? Why isn't there Ubiquiti all over them mountain >ranges? If we could change the demographics of the hobby that would help. But to attract some younger tech minded folks is a chicken and egg type of thing. You have to have something first to entice them. The second problem is regulatory. Data bandwidth issues, content issues.. all deturants. How many people even know about the 44net space? Maybe we need to reach out to; -The broadband-hamnet developers - presently they use 10.X.X.X address space -VOIP developers, like IRLP, Echolink, and Allstar. -Hams who run internet servers, like qsl.net, etc It would probably help to have our own custom firmware or recommended hardware. I have to admit, I have been doing everything on a raspberry pi with a usb ethernet dongle for the second port. I haven't tried to install the custom rip daemon on something like a WRT54G or ?? Then there is the issue of how to integrate 44net into your home network.

3 3

Re: [44net] 44net cool toys - not
by Steve Wright 19 Mar '14

19 Mar '14

Well, we suck don't we. I got issued my first 44net IP nearly 30 years ago, and now back after a "break", I find we don't have much. What needs to change? Why isn't there Ubiquiti all over them mountain ranges? There must be more interesting things to do than fix the portal, track down one stray packet per hour, or checkthat we don't dDOS the internet..gasp... I'm sorry, but we suck. Steve ZL1BHD

4 3

NTP 'monlist' DDOS attacks
by Brian Kantor 17 Mar '14

17 Mar '14

Folks, if you're running NTPD (Network Time Protocol daemon) on your AMPRNet hosts or routers, please be sure that the MONLIST command is disabled. If it is not, your device can be used to attack other systems on the Internet. You can test whether your NTP is thus misconfigured with the command /usr/sbin/ntpdc -n -c monlist If MONLIST is enabled, you will see a response including any IP addresses that have made use of your NTP services. Recommended Action: NTPD versions prior to 4.2.7 are vulnerable by default; the simplest recommended course of action is to upgrade all versions of ntpd that are publically accessible to 4.2.7 or greater. In cases where upgrading is not possible, disabling the monitor functionality can be accomplished via the instructions below. Add the “noquery” directive to the “restrict default” line in the system’s ntp.conf, as shown below: restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery The links below describe the activity in more detail as well as possible solutions. US CERT Notifiacation: https://www.us-cert.gov/ncas/alerts/TA14-013A CERT.ORG Message: http://www.kb.cert.org/vuls/id/348126 Thank you - Brian

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net