- 44net - mailman.ardc.net

routable or private?
by Steve Wright 23 Apr '14

23 Apr '14

> If this is, " a hack to backbone a semi-private network on top of the > public internet" then why do we need 44/8? Please explain why 10/8 would > not work just as well? > >[....] if it's not going to be routable then why do we need 44/8? use > RFC1918 space and give 44/8 back. [...] We could attract many > into this hobby if we'd simply offer to be the teachers of the IP > networking craft using standards based methods used by everyone else across > the internet. > PRECISELY. Can we please make a decision on this and move ahead? I'd like to know, one way or the other, because I sure aint interested in all this private 44net stuff.. Is 44net routable or private? Steve

14 19

Re: [44net] 44Net Digest, Vol 3, Issue 80
by Steve Wright 22 Apr '14

22 Apr '14

> http://www.ampr.org/pubs.html > > http://www.ampr.org/faq.html > > I don't see what's missing. Build a Ham RF IP network. Hook if up > to the 44net community if desired. A very select few would need to > go the next step and get their own BGP ISP setup. If anything, that's > mentioned too much on the website and should be de-emphasized. > What's missing is, it's not in the wiki so people can find it. Edit, annotate, and add it to the wiki please. Thank you. Steve

3 3

Re: [44net] New Wiki Page - Services
by sp2lob＠tlen 22 Apr '14

22 Apr '14

Neil et al, Yes, it is active. I use it very often. Best regards. Tom - sp2lob

1 0

Directly connect 44nets
by Steve Wright 21 Apr '14

21 Apr '14

Wow a big flow of good information, and instant updates to the wiki! Well this is the problem isn't - noobs causing problems broadcasting the wrong information on the Internet and getting blocked by their ISP. We seriously need a properly written checklist, so that ordinary ham radio 'engineers' can actually build this stuff themselves. Approaching my ISP with some half-baked idea would be a quick way to get permanently ignored. -- Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers +64 21 040 5067

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 78
by Steve Wright 21 Apr '14

21 Apr '14

> my thought is we need > more people working on finishing the portal first. What exactly is that going to DO? Here I am sitting on my hands trying to figure out how to get my (already allocated MONTHS AGO) /24 connected to the flamin internet. No one seems focussed on making a wiki entry about THAT. Rather, they'd be happier tunneling their little private network to someone elses'. It seems that many other groups have been waiting YEARS for this assistance or documentation, and MANY other groups who have just given up in disgust. Would the people who ACTUALLY HAVE a properly connected (live to the internet) 44 subnet that they openly brag about, kindly document the bloody thing in the wiki so I can do it as well? This isn't a dick measuring group, its a networking group. You know what you're doing, so write it up so mere mortals can achieve a positive result as well. There needs to be a sample equipment list with DIY workarounds for those with time but not money, and there needs to be a VERY well written document-set to hand to my ISP so I don't scare them into just plain refusing my request, or unduly taxing their tech team. Thank you.

5 5

Re: [44net] how to announce directly (Was 44Net Digest, Vol 3, Issue 78)
by Bryan Fields 21 Apr '14

21 Apr '14

On 4/20/14, 7:27 PM, Neil Johnson wrote: > I've summarized Eric's explanation and added an entry to the wiki. > > http://wiki.ampr.org/index.php/Announcing_your_allocation_directly +1. I think the point is if you have to ask how to connect (announce) your /24 to the internet you probably shouldn't be doing it on your own, your ISP needs to do it for you. Perhaps a overview of internet routing process is needed, as I want the 44/net to be a place to learn, but we need to ensure people understand what they are doing before messing with the global table. This is quite simple, but the LoA (letter of authority) and required information can be daunting to those who've never done it before. Also, if you're on the digest version, can you change the subject of your reply? I've been ignoring this thread since I didn't feel like reading it all at once. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 3

Re: [44net] how to announce directly (Was 44Net Digest, Vol 3, Issue 78)
by Bryan Fields 21 Apr '14

21 Apr '14

On 4/20/14, 9:24 PM, Neil Johnson wrote: > and do my part > for keeping the global BGP routing table from expanding faster I disagree, I work for a company that sells routers. :D -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 78
by Tim Osburn 20 Apr '14

20 Apr '14

Steve, Part of the request for 44-IP space from Brian for the intent to advertise it on the Internet is a ISP who is already willing and offered to do this. If this hasn't already been done the IP space you have may not have Brian's approval for that type of use. (But rather used for just IP-in-IP tunnel service) So before you go down that path you may want to check with him first. Once that is completed and you have a LoA (Letter of Authority) from Brian stating you have his approval to advertise this space on the Internet you should be able to do the following. (Some ISP's ask for a LoA, and most should ask). Also note the other requirements that one agrees too: http://www.ampr.org/tos.txt 1) Once you've already discussed this with yoru ISP and they are willing to do this, let the ISP know the IP space and send them the LoA. They will need this so that they can setup the required configs, notify their upstreams, and setup routing of that block to your router. This could take a couple of days, and unless they are HAM friendly (this really helps) or you also purchase a lot of services form them, I would have to guess they may charge for this service. 2) Have your ISP advertise the 44 space assigned to you using their existing BGP ASN and then have them route you your 44 block to your router. 3) This is probably why no one has written this because each person setup will be different depending on how you will use the space. But for yours (with not having any details at all) I will assume you have a router that connects to your ISP with three interfaces. One interface will connect to your ISP and that interface will have a external public routable IP, one interface will point to your internal network with perhaps a 192.168.0.1/24 IP running NAT on that interface. The 3rd interface will be a DMZ network where the 44-net addresses will live. Perhaps a switch plugs into this interface and a different switch plugs into your Internet NAT interface. (don't mix the two within the same logical network/switch/vlan). NOTE: This is only one very simplified example. https://www.osburn.com/ampr_network-140420-1.0.0-example_network.jpg Tim Osburn www.osburn.com W7RSZ On Mon, 21 Apr 2014, Steve Wright wrote: > Date: Mon, 21 Apr 2014 09:22:02 +1200 > From: Steve Wright <stevewrightnz(a)gmail.com> > Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > To: 44net(a)hamradio.ucsd.edu > Subject: Re: [44net] 44Net Digest, Vol 3, Issue 78 > > (Please trim inclusions from previous messages) > _______________________________________________ >> my thought is we need >> more people working on finishing the portal first. > > What exactly is that going to DO? > > Here I am sitting on my hands trying to figure out how to get my (already > allocated MONTHS AGO) /24 connected to the flamin internet. No one seems > focussed on making a wiki entry about THAT. Rather, they'd be happier > tunneling their little private network to someone elses'. It seems that > many other groups have been waiting YEARS for this assistance or > documentation, and MANY other groups who have just given up in disgust. > > Would the people who ACTUALLY HAVE a properly connected (live to the > internet) 44 subnet that they openly brag about, kindly document the bloody > thing in the wiki so I can do it as well? This isn't a dick measuring > group, its a networking group. You know what you're doing, so write it up > so mere mortals can achieve a positive result as well. > > There needs to be a sample equipment list with DIY workarounds for those > with time but not money, and there needs to be a VERY well written > document-set to hand to my ISP so I don't scare them into just plain > refusing my request, or unduly taxing their tech team. > > Thank you. >

1 0

Re: [44net] Test New Tool - APRS Code Recovery
by kb9mwr＠gmail.com 20 Apr '14

20 Apr '14

It appears to work. You mentioned you weren't intending to provide access to the code, but how about the code that looks at the source IP / password requirement part? I'm one of those guys who still hasn't fully wrapped their head around PHP yet, so I'd like to see how you did that part. On that topic, maybe we should have a place/repository on the amprnet to put ham specific software. A while back I posted a link to a web based rig control application I was running. It uses hamlib for backend and php for a front end. Here is more info: http://kb9mwr.blogspot.com/2013/04/raspberry-pi-web-based-rig-control.html As for the ARDC director position discussions, my thought is we need more people working on finishing the portal first. I am sure Chris would appreciate that.

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 77
by Steve Wright 19 Apr '14

19 Apr '14

> > The IP space is owned by > > > > Amateur Radio Digital Communications > > > > per the whois. > > > > ARIN requires a legal entity to exist in order to receive the IP space. > Actually it doesn't sound like it's "owned" by ardc at all. Why do you state this to be so? Your mention of your lawyers smacks of stand over tactics. > 1. Minor: That everyone include his/her callsign as part of the > message, either in the "From" line (my preference) or in the signature. > 2. Major: That messages with a subject line that includes the name of a > digest, be blocked/rejected. This is not to be cruel or mean, but > to insure that others (like me) actually read the message. I doubt > that I'm the only one that refuses to read messages with a subject > line that is a digest name. No. No one is interested in your extra rules. Think up something actually useful and interesting, and contribute that.

1 0

44/8 allocation
by lleachii.aol.com 19 Apr '14

19 Apr '14

Regarding the 44/8 and IANA: Please don't "shake the hornets' nest," by asking IANA or ARIN. While IANA issued the /8 when it ran "Internet Registry," it is actually referenced in RFCs. It is a technical fixture of the "DARPA Internet" that the 44/8 addresses are AMPRNET. The legal question of: "is an IP address property, and if so, do legacy IP holders have different property rights than those allocated from RIRs" is a DANGEROUS question to venture into having solved before IPv4 "goes the way" of thrift store dialup modems. Why? Because of all those who still hold legacy allocations: AMPRNet is the only one that is: - non-commercial - nonprofit - not part of military-industrial complex - not part of the big-pharmaceutical industry - not governmental - not part of big-telecom - not part of the financial industry - not part one the major corporations, nations or firms that help rebuild/establish/maintain the infrastructure of the globe during/after World War II What /8 do you think they'll try to take first when the world's number resources approach 0.01 /8's remaining to allocate??? -KB3VWG

3 2

Running for ARDC director position
by Bart Kus 18 Apr '14

18 Apr '14

Hello, I'd like to join the board of ARDC. Having studied the situation a bit, it looks to me like ARDC is in a bad situation right now. Should Brian get hit by a bus, the corporation will no longer have any directors or officers. Its assets would then be disseminated by a court during the dismantling of the corporation. This means the address space would be given away to whoever the court decides, which could include ARIN for re-purposing as commercial space. I'm not 100% on this, since there is scant documentation on the heritage of 44/8 and its present legal ownership status. I believe it's "legacy space", but ARIN doesn't seem to agree: the netblock suffix does not end with -Z. As "legacy space" there should be some chain of ownership documented somewhere, and I'm just not finding it. Having read the bylaws, I also haven't managed to find how I might go about becoming elected. The processes for replacement and removal of directors are defined (majority vote of board members), but I don't see how elections to vacant positions are supposed to take place. I'd also like to say that a board electing itself is not the best model of governance for a non-profit corporation. Non-profits are supposed to serve some need: in this case the needs of amateurs who wish to make use of 44/8 space. I'd like to see a governance model where the users elect the directors who best represent their needs. This is one crucial governance change that I think absolutely needs to happen. Aside from governance, there are several technical issues that I'd like to see brought up to speed with modern standards, and published as part of official interface specifications for AMPRnet. I don't want to get too detailed in this email, but a top-level list of technical things I'd push for as director includes: 1) Support for BGP 2) Support for IPsec(AH) 3) Support for anycasting 4) An improved gateway registration process with IP ownership verification 5) Support for DNS delegation 6) Support for DNSSEC signing 7) Deployment of multiple regional Internet gateways to remove the UCSD single point of failure 8) Adoption of the Extensible Provisioning Protocol 9) Publication of official multi-platform software which simplifies the AMPRnet user experience I've experienced opposition on implementing points 3 and 5 so far, and I'm reluctant to attempt any more of these agenda items without some changes to how the organization makes decisions. There are no technical blockers here, as all of these technologies I mentioned are widely used on the Internet today. However, it's nearly impossible to achieve technical leadership when decisions require universal consensus, and/or the decision making process is undefined. AMPR needs more board members who can push such technologies forward, and participate in the official decision making process while relying on their deep technical expertise to ensure their votes are sound. In terms of my qualifications for board duty, I founded the HamWAN organization in Washington which has deployed a regional microwave network, uses AMPRnet IP space, and has based its standard designs on the latest & greatest hardware and software has to offer. Professionally, I'd been running Internet services since 1996. Presently I work on routing for a major cloud provider. I'd like to bring the same kind of innovation to AMPRnet as I did with HamWAN. On the governance standpoint, I drafted the HamWAN bylaws in very intentional ways. Ways that empower the volunteers who are doing the active work that contributes to progress. Governance overhead is minimal so everyone can just mostly focus on the problems at hand. So, what are the next steps here? --Bart

8 9

Mailing list suggestions
by Dean Gibson AE7Q 18 Apr '14

18 Apr '14

1. Minor: That everyone include his/her callsign as part of the message, either in the "From" line (my preference) or in the signature. 2. Major: That messages with a subject line that includes the name of a digest, be blocked/rejected. This is not to be cruel or mean, but to insure that others (like me) actually read the message. I doubt that I'm the only one that refuses to read messages with a subject line that is a digest name.

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 75
by Rob Janssen 18 Apr '14

18 Apr '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Running for ARDC director position > From: > "." <lleachii(a)aol.com> > Date: > 04/18/2014 04:59 PM > > To: > 44net(a)hamradio.ucsd.edu > > > I keep a little copy/paste history and info athttp://kb3vwg-010.ampr.org but I'm definitely not the AMPR historian, by experience. I checked there and I read: There are two negative aspects I can think of: - Speed: Even an IP frame from one host in Germany to another has to go via ucsd.edu . That way it has to cross the Atlantic two times. That is not correct. The tunnel mesh does not work like that. Traffic between 44net hosts flows directly from gateway to gateway in an IPIP tunnel between them. amprgw is not involved in that at all. Only traffic from outside to inside 44net is via amprgw, and there are now other gateways as well that serve smaller subnets (e.g. in Belgium and Germany). All gateways have IPIP tunnels to all other gateways, and the traffic flows according to the shortest route via internet between the gateways. Rob

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 75
by Rob Janssen 18 Apr '14

18 Apr '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Running for ARDC director position > From: > YT9TP Pedja <yt9tp(a)uzice.net> > Date: > 04/18/2014 12:38 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > This is very strange approach that I, frankly met nowhere else in ham world but here. > > I participated in number of noncommercial and hobby projects and the one of the main goals I always had was to document things to make it easier for people to learn, get involved and contribute. IMHO there is more than enough documentation around for people to learn, get involved and contribute. It is only for the types that want to know the reason for each and every bit that there may be a lack of documentation. It is my opinion that when they really need the detailed specification they claim is not available, they should write that themselves asking for input here on the mailinglist. But they rather prefer slashing everything that is there and claiming that it is all inferior. There really is not much to it, it is simply a meshed IPIP tunnel network with a gateway to the outside internet, and everyone with basic understanding of routing should be able to comprehend how it works. The software it is running on has changed over time so directions on how to get it working have to evolve as well. I have posted simple scripts for Linux on this list and I don't see what is wrong with them. Of course they are not "specification and documentation" but hey, there are only some 10 shell commands to it. Rob

1 0

Ampr
by lleachii.aol.com 18 Apr '14

18 Apr '14

No respect for the youth! We'll talk about peering! -Lynwood KB3VWG 31 yrs young

2 1

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by lleachii＠aol.com 18 Apr '14

18 Apr '14

Tom, If I understand you correctly, even if the portal allowed you to enter a 44 address as an IPIP endpoint, my 44GW (and many others) would be able to send traffic to it. Since I wrote a script that quite a few people with Ubuntu Linux Gateways use (which was designed to closely mimic AMPRGW's behavior), here is what would occur (I cannot confirm this for other gateways using different OSes or scripts): see: http://kb3vwg-013.ampr.org/startampr - the gateways using the KB3VWG Linux script are set to use a custom routing table if the SRC or DST address is 44.0.0.0/8 - the rip44 then adds all 44 routes to the 44 routing table - so, as you wish a.) rip44 would add your tunneled subnet (44.24.240.0/20) to routing table 44 with an endpoint address as 44.24.221.1 b.) a host in my subnet sends your subnet a packet and is received by my router c.) it looks up the endpoint destination on table 44 and finds that it's 44.24.221.1 d.) my router will look in the routing table for 44.24.221.1 finds **44.24.221.1 via 169.228.66.251 dev tunl0** *****which would be **INVALID***** e.) **INVALID***My GW sends an encapsulated packet to AMPRGW, and it's received on it's WAN interface. ***AMPRGW should not receive encapsulated packets from 44 hosts destined to 44 hosts*** Routing loops can occur. - there have been IPIP tunnels in the past with 44 addresses, they were considered invalid configurations. To the Internet, 44 net is a flat /8 network and all subnets must be reachable at a non-44 address; which leads me to my last point - I'm not sure why you keep insisting that AMPR routing is "broken" or has "funky 44net issues," you are requesting something that was not intended in the design, as was mentioned before tunnels msut be reachable with non-44 address, BGP routed subnets must still maintain a IPIP GW. - This same topic was presented in April 2012, check the archive " ***"This will also means that any Operator that wishes to BGP should also consider also running the AMPR standard rip44d on the same device, if the intention is to make all 44/8 addresses equally reachable from any PoP, eventually, as is the intend purpose of BGP."*** - it was my intention update the script to include a block of IPENCAP from 44.0.0.0/8 SRC addresses...until I read your posts today 73, Lynwood KB3VWG Tom wrote: >Forget AMPRGW. I understand there is a routing issue at UCSD that >breaks 44net routing for AMPRGW. But I'm not asking about AMPRGW! I'm >asking about routing from all the IPIP gateways, none of which have >44net endpoints at the moment. > >Since none of the current IPIP gateways have 44net endpoints, you >cannot say with certainty that it won't work until the portal lets us >try it. > >Tom KD7LXL

14 41

Re: [44net] Running for ARDC director position
by lleachii.aol.com 18 Apr '14

18 Apr '14

Charles There's a deeper issue than just signing the RSA. At this point, it's a big legal conundrum if the RIRs have control over those who've never signed an RSA. For all intents...some legacy IP networks "OWN" their allocation. No court has ever decided (or been asked to decide) that question. AMPR obtained their allocation from IANA before ARIN or the other RIRs even existed. The allocation was issued in an RFC named Assigned Numbers in 1991. -KB3VWG "." <lleachii(a)aol.com> wrote: >Should be: > >http://wiki.ampr.org

1 0

Re: [44net] Running for ARDC director position
by ktolliver 18 Apr '14

18 Apr '14

The website names 3 people that are Boardmembers of ARDC. They are also the only 3 officers. According to the Bylaws these 3 control everything. No one else has any say in the control of the ARDC. There are no members. Just them. They can allow 2 more people on the Board, however, since they could remove the new Board members anytime they didn't like a vote or discussion, it's all illusory anyway. Until the Bylaws are modified to allow the voice of the users to be heard(via a right to vote) ARDC is just a closed 3 person entity. I too would like to see Bart on the Board. I lean towards his view of things. Id rather have 4 or 5 dictators than 3(sorry I think I meant 'Directors'). The current Bylaws give 100% of the control of the ARDC to the 3 Directors. I don't know the history behind it. It is a good way to get things done in a timely manner, but to have the wishes of the users heard----changes would be needed. The current Bylaws were written to concentrate power. Also, Bart, as a Board Member if you wanted to vote at a Regular Board Meeting they would have to make a Bylaw change so you could attend and vote via electronic communications. Right now to have your vote counted at a Regular Board Meeting you have to actually be there or proxy it; but not for Annual or Special Meetings. An income and expense statement, and a list of transactions would help with transparency. An Asset Statement only shows so much. My guess is that the existing Board has been carrying the group financially. The loan on the books suggests that. I thank them for doing so. Without clear information it's hard to know the needs of the organization. Publishing the Board minutes and a Budget might open our eyes to the workings of the group and make more people inclined to donate. We are a large diverse group. There are many views and ideas amongst us. I'm sure there are some people with deep pockets amongst us too, if needed. Hopefully, with more openness, more people will feel inclined to help financially and with their ideas. I thank the existing Board members for your dedicated service. You have done a lot. I hope I haven't offended you. It's just that I have created many nonprofits in my legal career;but not once have I made one with such a tight concentration of power. Maybe that's needed with an asset as valuable as the 44 Net, I don't know. It just seems odd in Amateur Radio. Anyway, I encourage you to put Bart and another interested person on the Board ASAP. Sharing the load should make things easier. And you can do it without even having to have an election;just appoint him/them. And then just before or at the next Annual Meeting change the Bylaws to allow users to have a vote in matters via proxy, electronic, or other methods. Heck, a new set of Bylaws would be good too. 73 Ken K7ICY ps I am new to the 44 Net. I don't know your past history. And you might have full minutes and financials posted somewhere. It's just real late and I'm too lazy to search them out. Sorry if I'm all wet. Feel free to Flame. All attorneys have thick skin and the Heat might help get me ready for the Hereafter. Sent from Samsung tablet

4 4

Re: [44net] Running for ARDC director position
by . 18 Apr '14

18 Apr '14

Should be: http://wiki.ampr.org

2 1

Re: [44net] Test New Tool - APRS Code Recovery
by Marius Petrescu 18 Apr '14

18 Apr '14

Time and again there appear suggestions for using that LOTW certificate for other things then LOTW. I don't know if you are aware, but not everyone is an ARRL member or uses LOTW. So, as long as things like APRS have absolutely nothing to do with ARRL, please keep them apart. Marius, YO2LOJ

8 12

Re: [44net] Running for ARDC director position
by . 18 Apr '14

18 Apr '14

I agree with N6MEF. When I first requested an allocation and how to stand up a 44GW, I was simply told I had the /24. I was stuck building a GW with only the mailing list, knowledge of networking and the Linux manual as my guide. I had to learn about the AMPR DNS zone, *NOS, how the network works, etc. Brian was a huge help. And he told me to document how I got my 44GW working...alot of that has been incorporated into the rip44d page and setting up a Linux machine in the Wiki, not just directly by me, but through others and from this email thread, etc. We all have been doing a good job recently by way of creating documentation by posting to to the Wiki; but it would be easier if those who have the particular experience (e.g. setting up a TNOS/JNOS node or compiling the new C++ based rip44) take time to record their steps. Perhaps even write a history of 44net...I keep a little copy/paste history and info at http://kb3vwg-010.ampr.org but I'm definitely not the AMPR historian, by experience. I'm willing to take time to draft some things (such as the AMPR DNS and start a page listing all services I'm aware of on AMPRNet, since I maintain some services such as a non-authorative DNS slave at 44.60.44.3)...but it would be better if those with direct knowledge (e.g. the DNS admin or an owner of one of the authorative slaves) draft it (i.e. I have no clue who to talk to about considering making my server authorative). -KB3VWG

1 0

Re: [44net] Running for ARDC director position
by Bryan Fields 18 Apr '14

18 Apr '14

On 4/17/14, 5:20 PM, Neil Johnson wrote: > As for not being official "Legacy" address space, signing an LRSA with > ARIN is problematic for many legacy address holders because it is not > clear wether the rights one gets and gives up is worth it. Plus it > can incur paying enormous annual fees (in the tens of thousands of > dollars range) to ARIN. Actually, ARIN has no jurisdiction over the legacy space. The NSF has ruled that this (Postel) space is property of the legacy holders. *ARDC owns 44/8. * ARIN is required to manage the minimum of the database entries needed to make this space work at no cost to. Signing a legacy RSA would be a bad idea as ARDC would give up ownership of 44/8 which is worth in excess of $100M USD! We need to stay away from ARIN as much as we can, ie do everything via rwhois and DNS via AMPRnet servers, not ARIN. I'd even go so far to say that ARDC is basically it's own RIR not bound by *ANY *ARIN policy. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

4 3

Wiki
by Chris 17 Apr '14

17 Apr '14

The wiki is back up and running with the latest software version. Regards, Chris

2 2

ampr.org subdomains
by Dean Gibson AE7Q 17 Apr '14

17 Apr '14

An open question on ampr.org hostnames (see my response below): On 2014-04-08 15:32, Brian Kantor wrote: > Dean, I feel it would be a bad idea to delegate the forward lookup to your nameserver without also delegating the reverse lookup, which would be difficult and we do not do. You can continue to have as many names in the ampr.org dns like ns1.ae7q as you like by having John set them up for you, which will automatically set up the appropriate PTR record as well. I'd much rather you did it this way. > > Best wishes. - Brian > > On 2014-04-04 17:47, Dean Gibson wrote (to<bkantor(a)ucsd.ude>): >>> I have IP address 44.24.240.173 in Bart Kus’s 44.24.240.0/20 block. I sent a request to John Hays, the admin for the 44.24.0.0/16 block to add the following records to the ampr.org domain: >>> ns1.ae7q IN A 44.24.240.173 >>> ae7q IN NS ns1.ae7q >>> This would allow me to create additional hostnames in the ae7q.ampr.org sub-domain, in my own DNS server. I’ve run BIND for 15 years, and this is a nice way to delegate a sub-domain; the ampr.org domain remains protected. >>> John was able to add the first line to the domain, but not the second line, and he suggested that I contact you. I see other NS records in the ampr.org domain; is this something that you can do? >>> Sincerely, Dean AE7Q >>> I understand the difficulty with delegating the reverse lookup in general, which I was not requesting and don't need. It's often not done on the Internet anyway for small (eg, hobby) servers, except for mail servers, where it is a means of spam server detection. I've run multiple sites with various functions (DNS, mail, web) on one box on the Internet for 15+ years, and the only reverse DNS I've ever needed was for mail servers. Usually, a hobby machine serves several functions within the same box, and multiple hostnames are mapped to the same IP address. In fact, for ae7q.com (and my other domains), due to DNS requirements, I can't use CNAMEs for the domain hostname (for those that leave off www.), the nameserver hostname, or the mail server hostname (NS and MX records can't reference a CNAME -- RFC 2181 <https://tools.ietf.org/html/rfc2181> section 10.3). These all use an "A" record to assign the *same IP address* as the mail server (which also can't use a CNAME, due to spam detection). That's three "A" records to one IP address (and that's just in one domain), and it is a very common practice. I do use CNAMEs other places. I understand that you would like a PTR record for every hostname, but that has the following negative consequences that I can see: 1. It encourages people to request a larger IP address block than they need, and then create a multi-homed machine for the various functions. I think it's a really bad idea to consume unnecessary IP addresses, and I think it's already happening in the 44.x.x.x network. 2. For frequent changes, it unfairly and unduly burdens those volunteers who have to respond to requests. I make *very* frequent changes to my Internet and LAN domain records. I have over 50 network devices on my LAN at home on five subdomains, and I use DDNS (both manually and via DHCP) for most of them (it's just easier than changing a zone file and restarting BIND). Granted, most of those won't be on the 44.x.x.x network, but the present scheme discourages experimenting with configurations by amateurs who don't want to burden the volunteers who make the ampr.org changes. I would suggest that you reconsider your position of requiring a PTR record for each hostname. Much better to have a policy of encouraging *user-managed* subdomains, in my opinion; that would help lead to a consistency in hostnames in ampr.org (eg, all of the form <whatever>.<callsign>.ampr.org). A much poorer alternative (also my opinion) is the present practice of having end users to *submit to coordinators* CNAME records for subdomains of any "A" records that are allocated to them. Frankly, the former suggestion (user-managed subdomains where an ampr.org coordinator adds the "NS" record *once*), is a lot less work, in my opinion. Or is there a risk I'm not aware of? Remember, the subdomains are served off of the user's DNS server(s), not the ampr.org DNS servers. Sincerely, Dean Gibson AE7Q

2 1

Re: [44net] AMPRNet BGP vs non-BGP routing
by Bryan Fields 16 Apr '14

16 Apr '14

On 4/11/14, 12:04 PM, Bart Kus wrote: > Well, IPIP itself is not the problem. It avoids the costs of Internet > BGP peering. What is a problem is the lack of dead-peer-detection > between IPIP gateways. If intra-AMPR BGP peering was actually deployed > as part of the general recommendations then we wouldn't need to anycast > to achieve redundancy. But as it stands, the deployed technologies are > very light, and anycasting our IPIP endpoint is the easiest way to > achieve the desired redundancy. We do plan to make special BGP+IPSec > arrangements with select AMPRnet peers to further improve our > availability and security, but there's no need to do any of that work on > the mailing list. I'd say we should keep it on the mailing list. I'm very interested in what others are doing with BGP announced AMPRnet space! I'd be interested in interconnecting if you need a gateway or something. I've got a good relationship with my upstream in Tampa. Granted the latency to WA is a bit much :) FWIW I'll be in Belview for NANOG 61 in June. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 2

NOS "versions"
by Eric Fort 13 Apr '14

13 Apr '14

Does such exist.... Has anyone created..... can said code be easily separated / compiled separately..... What I'm looking for is a "version" of nos that is devoid of any of it's networking functionality or well at least the bottom 3 layers of the OSI stack. The issue being that NOS has long been a standard and familiar interface for networked amateur radio BBS systems. I'm good with that. over the last 20+ years though we have moved to computers and operating systems that are much more capable, especially when it comes to processing speed, memory, and a decent built in network stack. I now no longer need my application (BBS) to handle the network layer stuff but simply need what amounts to a good BBS interface. can/has this functionality be/been gutted/separated out from the NOS code base such that I can end up with an application that simply is setup to listen on the proper port via init.d and present *ONLY* the familiar bbs interface while the OS handles all the networking stuff and the application not even being capable of such. Eric

5 9

some answers I hope to latest NOS questions ...
by Maiko Langelaar 13 Apr '14

13 Apr '14

Good day to all, Unfortunately my subscription options were set to nomail, so I have not been following posts very reliably this past few months. Anyways, just thought I would dig through the digest and comment on stuff. > Doing the routing on the NOS side of things seems a bit backwards > these days (cough encap.txt) You don't have to use encap.txt anymore, depending on your configuration. Brian introduced AMPRnet RIP broadcasts a few years ago. Some of us use those now to update our NOS routes. > Of course you cannot do that if you are still running NOS > on an old DOS box. Technically speaking you could always do encap.txt on a NOS system running in DOS - I did it that way over 12 years ago. > Does such exist.... Has anyone created..... can said code > be easily separated / compiled separately..... The irony is (and there was a lot of criticism towards the authors at the time, this was before I took it over in 2004), the original NOS was actually 'hacked' to give it BBS functionality, as well as a few other features. Anythings possible, but removing the NOS from NOS (think about it, that's what it would come down to) would be a big waste of time and all you would have left is a BBS 'hack'. Sound to me perhaps FBB is more what you're looking for. It's a BBS first and foremost. Actually, how about BCM (Baybox) or OpenBCM out of Europe. It's pretty slick stuff actually, check it out. > don't say whether you're interested in a Windows or a Linux based Believe it or not I have a text (console) based Windows (yeah, true native windows not a DOS compile) version of JNOS, experimental like all of the NOS stuff is, even got WINMOR running B2F forwarding with RMS stations in both my windows and linux versions. Again, I'm an experimenter so the software (like usual NOS style) is not always the most user friendly. I'm just going to say, I'm encouraged for my own ham radio needs. Multipsk as a packet modem works too :) > This appears to be the only "maintained" version of JNOS I took over from James Dugal in 2004, and rebranded it as JNOS 2.0, you can see it in the credits on my official site for JNOS 2.0. James passed away years ago, passing the tourch so to speak, as others did to him as well when they got tired of working on it, or just had to give it up. My primary development platform for years was LINUX, it still is, just that I feel I need to get moving into the Windows (very untapped user base) domain. Just wish I had more time to devote to it, I'm a busy family and working man too like a lot of the people on this group. > haven't looked at the code to see how deep into the stack he's > getting but his dependence on winp cap indicates it still has some > degree of coupling to layer 3. The windows version I started with WinPcap cause I wanted a quick way to tie into the WIN32 tcp stack. I've tried to do raw sockets and it's just plain ugly and I got frustrated. The WinPcap has turned out to be pretty decent for what I need. I use the original NOS ip stack code, no windows IP or TCP functions, it's all NOS (yeah obsolete, exciting eh) code for ip routing, and such. Anyways, just thought I would try and clarify a few things. Feel free to ask me if you have more questions about all of this. With kind regards, Maiko Langelaar / VE4KLM * http://www.langelaar.net/projects/jnos2

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 71
by Rob Janssen 12 Apr '14

12 Apr '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] ampr-ripd for openwrt > From: > marius(a)yo2loj.ro > Date: > 04/12/2014 12:56 PM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > For the Mikrotik mipsbe metarouter architecture, I have a repository > online, where you can find ampr-ripd included: > http://yo2loj.ro/openwrt/mr-mips/packages/ > > I asked the question for someone else, a newcomer in gateway land. I forgot to ask which hardware architecture he uses, as I first assumed that openwrt always means those modified Linksys routers. The above list has an ampr-ripd with version 1.6 but a recent date. Is it really 1.6 or is it the latest version? Rob

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 71
by Rob Janssen 12 Apr '14

12 Apr '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] syn and such attacks on 44 net lately ? > From: > Gustavo Ponza <g.ponza(a)tin.it> > Date: > 04/12/2014 07:31 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Hi Maiko and all, > >> Anyone else noticing the SYN and FIN WAIT 1 status on their >> 44 systems lately ? Telnet, Smtp, HTTP, and such. Seems to >> be a 'bit' heavy this past few weeks. >> >> Maiko / VE4KLM > > just reported several times publicly and privately with no reply ... :) > Just look at someone of that below. > > gus i0ojj There are at least two different kinds of attack: 1. the ones that try to connect to your system to scan for vulnerabilities (including Heartbleed) 2. the ones that try to use your system for reflection to another victim. I have seen many of the second kind lately. Note that it is no use to complain to the owner of the "sending address" in this case, because it is spoofed and not the real sender. it is the intended victim of the attack! The symptom is many incoming connections in SYN_RECV state in the netstat -t output. What happens is you receive a SYN with a spoofed sender address, and you are supposed to send a number of SYN ACK packets to the "sender". As this is done repeatedly and to many different destinations, the "sender" (the victim) is hammered with traffic. The real cause of this problem is the lack of uptake of BCP38 (SAF, source address filtering). While "we" are sometimes suffering because of source address filtering when we want to dump traffic sourced in net 44 directly on the internet (instead of tunneling it back via amprgw), SAF in fact is a very good thing, and providers not doing it should be convinced to implement it to end those spoofed address attacks. Back to the SYN problem. I see two different schemes of this attack: 1. the SYN packets are sent with a source port that is a well-known service, like 80, 443, 119, 110 2. the SYN packets are sent with the usual random high-numbered port. The first ones are easily filtered with an iptables rule: iptables -A (chainname) -p tcp --syn -m multiport --source-ports 0:1023 -j DROP This blocks all connects from a privileged port, and should not hurt any normal operation. In fact it would be good if this rule was applied externally at amprgw, so that all this crap does not enter our tunnels. I have added it to several of my systems and the systems at work already. The second ones are a bit more tricky. You cannot simply block those as they look similar to normal traffic. However, if you have the typical low-traffic amateur radio system, you can use the "recent" module to limit unanswered traffic from the same IP address. iptables -A (chainname) -p tcp ! --syn -m recent --name tcp --remove iptables -A (chainname) -p tcp --syn -m recent --name tcp --set iptables -A (chainname) -p tcp --syn -m recent --name tcp --update --seconds 30 --hitcount 5 -j DROP What we do here is limit the number of "open" SYN packets from the same IP address to 5 in 30 seconds. When a SYN comes in, the second and third rules setup a bucket for the sending address in which those events are counted. When another packet comes in, the first rule resets that bucket and traffic from that system is allowed. So for normal incoming connections there is no impact, as the SYN/SYN ACK/ACK 3-way handshake quickly removes the special treatment of the client. However, for those spoofed SYN packets for which there is never any followup traffic, after 5 of those from the same system the "sender" is blocked from further access until they stop doing that for another 30 seconds. Works fine, this rule blocks tens of thousands of packets a day here and ends the issue of many incoming connections in SYN_RECV state. Note that these rules (or at least the first one) should be inserted BEFORE the typical "-m state -state ESTABLISHED,RELATED -j ACCEPT" rule that is often near the beginning of the list, because that rule will match on the followup packets of the connection so the --remove rule will never be reached, and the result would be that a client cannot make more than 5 connects in 30 seconds. Not a problem for telnet, but will be a problem when you run a website. Unfortunately this kind of "recent traffic" rule does not lend itself well for application at amprgw, because it has to maintain a lot of state and will probably be overloaded by the traffic being handled there. Rob

2 1

44.133.48.66 !!!
by Maiko Langelaar 12 Apr '14

12 Apr '14

Good afternoon, It would see that 44.133.48.66 is popping, snmpding, and other amounts of traffic from time to time to various ampr.org systems and doing so *without warning* type of thing. I just got hit with a bunch of SNMP requests, others have been hit with POP requests. Can anyone find out who the owner of that particular system or network is, so that I can contact the entity or person. Or perhaps a bit more draconian, can someone deal with it. Thanks in advance. Maiko Langelaar VE4KLM

4 5

ampr-ripd for openwrt
by Rob Janssen 12 Apr '14

12 Apr '14

Does someone have a binary of ampr-ripd for openwrt available on the net? It would save the effort of gearing up a development environment only to compile this little program... Rob

2 1

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by kb9mwr＠gmail.com 12 Apr '14

12 Apr '14

I was guessing most folks who run NOS these days do it on top of Linux. I don't have a problem with anyone who still wants to run it. So if you still doing the routing (encap stuff) on the NOS side, maybe its time to re think that. Just point the NOS default routes to the Linux and let it do what it does best. Doing the routing on the NOS side of things seems a bit backwards these days (cough encap.txt) Of course you cannot do that if you are still running NOS on an old DOS box. So is that why we still export the route addprivate nos format stuff on the portal? >> Alright how many people are still running some sort of NOS on DOS? >> >> Time to move forward folks and use the excellent routing capabilities of Linux. >> And let those who still need it the old way learn the pain of >> conversion. Give them a reason to upgrade/ move forward. >> >> </Off my soap box> >Or we can go the other way... Turn off all these fancy routers and >protocols and turn the radios back on... We never had better RF >technology available for cheap and I don't see much use being made of >it.. > >A CONVERS session on JNOS on a DOS box at 1200 baud can be more >'special' then thousands of words on these commercial infrastructure >systems with canned tools... > >Bill, WA7NWP > >PS. New toys arrived this week and with a bit of luck they'll be on >the air. 9k6 (and maybe much much more) in the 440 band for $80 a >side - just plug the USB into a RPI or whatever... ________________________________

1 0

Wiki issues
by Neil Johnson 12 Apr '14

12 Apr '14

I can see the main page, but if I click on a link the following page displays no text. -Neil -- Neil Johnson http://erudicon.com

2 2

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by Bryan Fields 11 Apr '14

11 Apr '14

On 4/11/14, 12:26 PM, lleachii(a)aol.com wrote: > TOS section 7c requires him to provide an AMPRNet connection for AMPR > devices local to him; but not necessarily via rip44. Since its not valid at > this time to tunnel to a 44subnet via a 44 address, I don't see how he's in > compliance (save via RF, which is their local AMPRNet anyway). Where would hamradio be with out armchair lawyers? I love this hobby. If he's using 44net space and announcing it to the internet via BGP he is providing access to the users behind his BGP router that have AMPRnet addresses. Sure they may not have access to the rest of AMPRnet via the IPIP routes, but that's optional. I'd even venture to guess most hams on his system won't care/know that it's missing the IPIP tunnels. People using AMPRnet space in BGP are most likely concerned with providing access to the internet via ham radio, not accessing slow 9600 baud links from the internet. > Bart also mentioned: > >>>>> It allows our microwave network to remain connected to the rest of >>>>> AMPRnet as long as we have at least 1 ISP that isn't dead. > **The problem would also solved if he announces 209.189.196.68/32 on both > ISP connections.** A /32 is going to be route filtered, and it's not his IP space, it's a /30 or /31 from his upstream BGP peer. So no, this is not possible. The entire *IDEA* of BGP is to allow you to control your own redundancy and peering to the routing table. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

3 2

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by kb9mwr＠gmail.com 11 Apr '14

11 Apr '14

Alright how many people are still running some sort of NOS on DOS? Time to move forward folks and use the excellent routing capabilities of Linux. Every time I look at the encap.txt and see stuff like: route addprivate 44.129/16 encap 118.22.1.194 I ask myself why do we still export is this way. I say export it as: ip route add 44.129.0.0/16 via 118.22.1.194 dev tunl0 onlink And let those who still need it the old way learn the pain of conversion. Give them a reason to upgrade/ move forward. </Off my soap box> ---- Quote--- Bart, Don brought up some good points. In addition: - non Linux-kernel routers (e.g. JNOS and TNOS) would not be able to route to you as they would need to be reprogrammed and recompiled (FYI, JNOS and TNOS is the most commonly used AMPR Network OS)

2 1

NANOG 61 June 2-4
by Bryan Fields 11 Apr '14

11 Apr '14

https://www.nanog.org/meetings/nanog61/home I'll be here, and Tim Osbourn W7RSZ as well. Is there anyone else going? I'd enjoy having a dinner or lunch breakout to meet with some of the AMPRnet users at NANOG. Post if you're going and we'll arrange something if we have some interest. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

4 3

Re: [44net] Portal doesn't allow IPIP anycast via 44net
by Bryan Fields 11 Apr '14

11 Apr '14

On 4/11/14, 11:37 AM, lleachii(a)aol.com wrote: > It's much easier, and doesn't require a total reconfiguration of AMPR to > simply have Bart run a 44GW speaking rip 44 using his Public IP address as > the GWip - be advised that he is required to do so under the Terms of > Service: That's a heck of a jump in logic. I see nothing in there requiring anyone to run rip44d. All it means is you need have the ability of supplying connectivity to other hams in your area out of your subnet. I'm doing this via GRE and VPN dialers. I have little interest in connecting to the rest of AMPRnet hosts who are not rotatable in the global table. My interest is supplying access over RF using the AMPR space and setting up routed redundant multi-megabit links. What AMPRnet has running now is akin to the GRX network IMO. It's private with one interconnection to the internet. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] AMPRNet BGP vs non-BGP routing
by Bryan Fields 11 Apr '14

11 Apr '14

On 4/11/14, 11:32 AM, Bart Kus wrote: > It allows our microwave network to remain connected to the rest of > AMPRnet as long as we have at least 1 ISP that isn't dead. The > microwave network peers with the Internet at 2 different points at > present, but more points will come in the future. It's a robustness > improvement in the face of partial failures, like in a natural disaster > when an ISP's fiber gets torn or their building collapses. So this is a hack to correct for the hack of AMPRnet IPIP tunnels. Argh, it makes my head hurt. If AMPRnet was treated like any other network on the internet, this problem would go away. At worst anyone not redundantly connected to the global internet would lose connectivity if their small gateway went down. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re: [44net] AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
by Brian Kantor 11 Apr '14

11 Apr '14

As far as I know, because of routing restrictions on the amprgw network connectivity, hosts on BGP-announced subnets of 44/8 will be unable to communicate with hosts on tunnel-routed subnets of 44/8 unless the BGP-announced subnet also runs a listed tunnel router gateway with a non-44/8 gateway address. This is because the building-level router one hop upstream from amprgw has a fixed route directing all 44/8 traffic to amprgw. This building-level router does not speak BGP and so cannot learn about BGP-announced subnets of 44/8. This is a historical artifact; it predates the availability of BGP-announced 44/8 subnets by many years. We hope to change this topology in the future to connectivity with the border router that DOES speak BGP, but indications are that that change will not be able to be done soon. In the meantime, gateway tunnel routers with a non-44 gateway address (that's all of them, except HamWan's proposed gateway) are the workaround to this restriction. I'm sorry for this difficulty but it's what we're stuck with for now. - Brian

6 12

Portal doesn't allow IPIP anycast via 44net
by Bart Kus 10 Apr '14

10 Apr '14

Hi, In trying to migrate HamWAN to IPIP anycast as discussed in a previous thread. I have run across a problem at the very last step. The relevant screenshot is at http://imgur.com/X2BfziT . Cannot attach the PNG due to message size restrictions. Basically, when I try to change the Gateway IP for our 44.24.240.0/20 subnet to be 44.24.221.1, I get the error message "Invalid gateway IP address". I'm sure this was intentionally coded at some point, but I believe this to be a design error. Here's why: 1) 44.24.221.1 is outside the associated prefix list for this gateway (44.24.240.0/20 only). 2) 44.24.221.0/24 will not be configured to have an IPIP gateway as it is being announced directly on the Internet. Given those two conditions, anyone with traffic for 44.24.240.0/20 can send it via Internet or IPIP to 44.24.221.1. When sending to 44.24.221.1 (outer IPIP header dst-addr), there should be no conflicting route and the default route should be taken, resulting in proper packet delivery to HamWAN. Can someone add this gateway manually and then fix the portal interface problem? Our tunnels are re-configured into the new desired state and awaiting packets. :) We are presently in AMPR tunnel downtime mode until that gateway is set + propagated. Thanks! --Bart

7 12

Can't communicate with 44.0.0.1 from 44-space?
by Bart Kus 10 Apr '14

10 Apr '14

Hi, I have a couple traces to share: [eo@Seattle-ER1] > /tool traceroute address=44.0.0.1 src-address=209.189.196.68 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 209.189.196.65 0% 10 1.9ms 0.8 0.4 1.9 0.5 2 209.189.202.195 0% 10 0.7ms 73.1 0.4 261 108.6 3 206.81.80.99 0% 10 0.7ms 5.1 0.5 10.7 3.9 4 69.28.171.145 0% 10 28ms 26.6 20 38.1 5.2 5 69.28.171.210 0% 10 22.8ms 21.4 18.6 31.9 3.9 6 198.32.176.33 0% 10 21.6ms 19.5 19.1 21.6 0.7 7 137.164.47.19 0% 10 21.4ms 24.1 21.4 29 2 8 137.164.46.67 0% 10 25.1ms 25.1 23.6 27.1 0.9 9 137.164.46.244 0% 10 34.7ms 33.5 32.4 35.6 1.2 10 137.164.47.15 0% 10 39.4ms 39.7 39.3 41.5 0.6 11 137.164.23.54 0% 10 39.7ms 40.2 39.5 43.2 1 12 132.239.254.163 0% 10 40.5ms 41.5 39.7 49.1 2.7 13 132.239.255.131 0% 10 39.6ms 40.2 39.6 43.1 1 14 44.0.0.1 10% 10 39.7ms 39.9 39.6 40.5 0.3 [eo@Seattle-ER1] > /tool traceroute address=44.0.0.1 src-address=44.24.242.22 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 209.189.196.65 0% 5 0.7ms 1.3 0.5 2.5 0.7 2 209.189.201.195 0% 5 3.5ms 1.5 0.5 3.5 1.2 3 206.81.80.99 0% 4 0.4ms 4.1 0.4 8.1 3.5 4 69.28.171.145 0% 4 25.7ms 24.7 19.6 29.6 3.6 5 69.28.171.210 0% 4 34.7ms 25.3 21.5 34.7 5.5 6 198.32.176.33 0% 4 19.5ms 20.4 19.3 23.2 1.6 7 137.164.47.19 0% 4 23.7ms 23.6 21.9 25.4 1.3 8 137.164.46.1 0% 4 24.4ms 26.3 24.4 27.5 1.2 9 137.164.46.248 0% 4 36.1ms 33.8 32.1 36.1 1.5 10 137.164.47.111 0% 4 42.9ms 40.3 39.1 42.9 1.6 11 137.164.23.54 0% 4 41.2ms 45.8 39.8 61.6 9.1 12 100% 4 timeout 13 100% 4 timeout 14 100% 4 timeout 15 100% 4 timeout 16 100% 4 timeout They'll look like crap without monospace font, and I don't wanna use HTML cuz the content of my message will be torn out of the email and replaced with a web link. So, adjust your fonts + screen size accordingly to properly view the traces. The only difference between them is the source address. Both addresses are bound to that router. That router holds IPIP tunnels to every ENCAP.txt network. Since 44.0.0.1 is not one of these networks, there is no tunnel that covers that IP, so the packets go over the regular internet. We BGP announce 44.24.242.22, so the trace from that IP should succeed in theory. Can someone explain what's breaking here and how to fix it? Thanks, --Bart

2 2

Linux Gateway Tutorial
by Neil Johnson 07 Apr '14

07 Apr '14

I'm trying to decide how to write a "How To" guide for setting up a Linux Gateway for the Wiki. I'm planning on basing it on the excellent guide found here (with Credit): http://marc.storck.lu/blog/2013/08/howto-setup-an-amprnet-gateway-on-linux/ But I'm wondering what level of Linux Administration and IP Networking Expertise I should assume. If I assume zero, it's going to be a looong guide, probably too long. Below is a link to the diagram I was planning to base the guide off of. AMPRNet Gateway Diagram - https://docs.google.com/drawings/d/1xAcMbROBpbuRFY0tVf1VdBrAP0ZQwTsE6Eqokn2… Comments welcome. Thanks -Neil

13 24

Wiki Updates
by Neil Johnson 07 Apr '14

07 Apr '14

All, I finished by volunteer stint at a youth robotics competition, so I have been poking around the Wiki making some changes. Mainly I have been adding some small pieces of content to eliminate the Wiki links that go to empty pages, but I have also rearranged some of the content on the main page. If you run across any issues, please let me know. I hope that is okay with everyone. -Neil -- Neil Johnson, N0SFH http://erudicon.com

1 0

Pi bug for ipencap?
by Brian Rogers 07 Apr '14

07 Apr '14

Greetings; I've noticed recently after doing a package update on the iproute packages I can no longer configure my tunnel interface tunl0. Mainly I'm trying to reset the ttl to 64 for traceroute to properly work. Everything I've searched comes up empty. Here's what I see: root@gw:/usr/local/bin# iptunnel show tunl0: ip/ip remote any local any ttl inherit nopmtudisc root@gw:/usr/local/bin# ifconfig tunl0 tunl0 Link encap:IPIP Tunnel HWaddr inet addr:44.88.0.1 Mask:255.255.255.255 UP RUNNING NOARP MULTICAST MTU:0 Metric:1 ttl is stuck on inherit and MTU autoconfigs to 0. This I know is set by nopmtudisc however if I try to adjust things: root@gw:/usr/local/bin# ip tunnel change tunl0 ttl 64 ttl != 0 and noptmudisc are incompatible root@gw:/usr/local/bin# ip tunnel change pmtudisc mode ipip add tunnel tunl0 failed: No such file or directory Why would it try to ADD? the command is CHANGE. Has anyone else suffered this before and if so what was the fix? Thanks in advance. -- 73 de Brian Rogers - N1URO email: <n1uro(a)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: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

4 6

Re: [44net] 44Net Digest, Vol 3, Issue 67
by Steve Wright 06 Apr '14

06 Apr '14

> The key here is access to "Amateur Radio Frequencies", e.g. getting on the > air / RF. Well, you cannot possibly open the door to the Internet, then close it again, or have half of it open and the other half closed, then change it again tomorrow, or change it when someone gets upset - all you are going to have is a 44net dominated by strong negative feelings and a whole lot of arguing - probably exactly what you have already. The decision has been made already to continue with an amateur PUBLIC 44net. If Members want to firewall off all incoming !44/8, then that is their choice, and they should do that, and no one should comment on their choice, and should certainly not be disparaging about it. Same rule applies to all others doing as they choose as well. Let's fix this wiki and get the documentation sorted. Steve ZL1BHD

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 66
by Bryan Fields 04 Apr '14

04 Apr '14

On 4/4/14, 3:13 PM, Steve Wright wrote: > This is going to go nowhere. Go play with your netrom nodes and have fun > pinging each other at 1200baud, and keep being hostile to wireless ISPs who > just offered the use of tens of thousands of $$ worth of outdoor 100mbit > gear for no charge. TBH, 99% of WISP's run gear in the 100's of dollars range, it's not professional or even ham radio grade IMO. I've seen some real poor installations and even seen them kicked off sites. We should strive to be better than the average WISP. I'd say there is not implied guarantee that some one using a 44/8 IP is going to be a licensed ham radio operator. You as a control operator of the station are ultimately responsible for the transmissions. I don't get to concerned about it personally. I cannot police 100% of the traffic transiting my nodes, and I don't think anyone can. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 66
by Steve Wright 04 Apr '14

04 Apr '14

> Hmm, even here you may notice several people with quite networking > experience wanted to get involved but when they asked for help because > it is not that easy to understand how 44net works as there is tremendous > lack of information, they got pretty rude replies, like, they should > write documentation themselves. > > It's like there is some kind of elitism. If you are not involved in > development since mid 70's, and if you actually need to read > documentation, then you are not in a game. Yup, exactly. > I'd like to grant access to Amateur Radio frequencies if the source ip > is within 44.0.0.0/8. I assume that only radio amateurs are "behind" > net44 addresses. You see, but that is completely useless, because you just firewalled the entire internet. This is going to go nowhere. Go play with your netrom nodes and have fun pinging each other at 1200baud, and keep being hostile to wireless ISPs who just offered the use of tens of thousands of $$ worth of outdoor 100mbit gear for no charge. Think about it. S

2 1

Re: [44net] routable or private?
by Steve Wright 04 Apr '14

04 Apr '14

I guess my point is - there are those who sit around and cry and beat their forehead with their fist over authentication, the rules, third party traffic etc etc, and there are those who just go ahead, build it, and use it. The difficulty for me is, I returned to 44net hoping for the latter, or at the very least some tutorials on the wiki where it might be done, meet some people that are doing it, but the reality is more that the 44net list is dominated by crybabies who would far rather point the finger, overtly discuss, and get irate at the rulebreakers than actually build anything positive. My suggestion, if you were interested, which you're not, is to sit back a little and let the people who ARE ACTUALLY BUILDING SOMETHING, along with those who DO ACTUALLY INTEND to build something to get on with the task and keep your distracting discussion to yourself. Or maybe this is just never going to happen on this list, and we are forever doomed to listen to the repeated diatribe of how to overtly authenticate and heavily police and analyse every vagrant network ping like its' some heinous DDOS attack. If so, why not start a new list yourself and name it appropriately? Hrm?? :) Are we going put together a wiki on how to build a routable internet-connected 44net or not? What will it be? If we're going to shout, take offence, throw toys, and do nothing then I don't care for it. Make a decision. Steve

3 2

Re: [44net] routable or private?
by kb9mwr＠gmail.com 04 Apr '14

04 Apr '14

> Are we going put together a wiki on how to build a routable > internet-connected 44net or not? Google "setup an AMPRnet Gateway" the info is out there, one of the entries comes back from the wiki, It's actually a very simple process.

1 0

Re: [44net] 44net and consider... 100.64.0.0/10
by lleachii＠aol.com 03 Apr '14

03 Apr '14

* Here in the Washington DC area, we are ready and willing to make use of address space over RF links and make use of 44 address space. * I personally use 44 space for experimentation and development of new protocols, which in most cases, might not work over the Public Internet. I also am working to implement services and mesh access to/from agencies the our ARES/RACES serves (e.g. standing links in situation rooms of our local hospitals, public health facilities, shelter go-kits, etc.). * I'm not sure you reviewed RFC-6598 before suggesting use of 100.64.0.0/10 address space; but there are many technical restrictions that must be considered if using this address space. - DNS and Reverse DNS cannot be used - The addresses should not be forwarded outside of the "carrier's network," which could happen easily, even if by mistake - DNS filtering of addresses is recommended as to prevent leakage of 100.64.0.0/10 queries into the public Internet - A gateway's connectivity to the Public Internet may be lost if the carrier providing your "public" IP address switches to Carrier-Grade NATing (CGN) - Newer devices may be RFC6598 aware and not behave correctly using CGN IP space (e.g. not provide DNS responses, not routing or forwarding packets, etc.) If you need other private address space consider... 100.64.0.0/10 as defined in RFC-6598. 73, Lynwood KB3VWG

1 0

past and the future
by kb9mwr＠gmail.com 03 Apr '14

03 Apr '14

I can echo a lot of what Robbie wrote. My dad was in broadcast radio when I was younger. I read an article by Larry Kollar, KC4WZK on the Amateur Packet Radio Network that was floating around on dial-up BBS's and really caught my attention. That kind of sealed the deal that I needed to get into the hobby. When the locals gave me a copy of NOS, that was great. Before you know it I had two NOS boxes networked using NE2000 drivers. Moved from 1200 to 9600, and drooled when reading the VE3JF higher speed pages. We even did webpages on 9600 baud RF in the mid 90's when we all gravitated to Linux. Lots of learning and fun. Moving forward if you know anyone in the hobby with coding skills there are plenty of things that can be done. Hopefully in the future we can attract a few more of these types when they see the relevance ham radio can offer with higher speed networks and that sort. I am sure Chris could use a hand. How about a openwrt package for hams? Be that out of part 15 frequency control, or something like rip44d http://wiki.openwrt.org/doc/devel/packages Then there is always application ideas on 44net. I am impressed with what is out there already. On the RF side the broadband hamnet firmware developers could probably always use a hand too. 73 Steve, KB9MWR

3 2

Introducing myself
by charles＠thefnf.org 03 Apr '14

03 Apr '14

Hello, Charles Wyble here. I'm new to the list and thought I would introduce myself. Glad to be here. I'm the cofounder and CTO of the Free Network Foundation (http://www.thefnf.org). I'm not currently licensed as a HAM, however my co founder is. I stumbled across 44net via some folks up in Seattle doing a HAM WAN net. My background is in large scale systems (10000+ servers), storage, security, virtualization and basic data center networking. I'm now getting into WAN networking and the fact that an entire /8 is available to HAMs has convinced me to get my license very soon. For anyone who wants to experiment with BGP/WAN networking etc, please do let me know. (I've seen some folks on list express that, and I'll be reaching out). I know my cofounder will be requesting some address space very soon to experiment with. This is a great opportunity to get started on the real internet, because as mentioned IPv4 space is almost impossible to get these days. I look forward to being an active participant in the list. As far as I know, this is the only address space that's publicly administered/discussed etc. That alone is a huge draw for me. Everyone else that has space keeps governance closed.

2 1

Re: [44net] routable or private?
by Steve Wright 03 Apr '14

03 Apr '14

> If the answer to either of the above is "yes", then there is the potential > for traffic which violates radio licensing laws to be carried by radio. And > after all, I thought RADIO was what 44-net was supposed to be about? No, 44net is a PUBLIC IP address range. There are plenty of PRIVATE IP ranges that we can freely and arbitrarily use without care or regard whatsoever, and the 10/8 network is large enough for hams to build a substantial world-wide network without further ado. Why my main concern is with all this 44net stuff, and what we're seeing a lot of, is peoples' scaremongering and huge propensity to self-regulate and self-police to the absurd, resulting in the 44net never being any more than another reason to have an argument on some forum and then sit back on our arse and do nothing whatsoever. If this is actually going to be the case then my recommendation would be to find some facebook group or other forum to put ones' efforts into, and see if you might stir up some irrational waste-of-time argument there, because doing it in a 44net forum is likely to, at the very least, cause quite a few people to just give up, and at the very worst, have someone very concisely and perhaps not so politely explain the problem to you. Steve

14 16

Re: [44net] routable or private?
by William Lewis 01 Apr '14

01 Apr '14

At 08:37 AM 04/01/14, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >Somethings not right ... > >I did a traceroute to 44.68.52.1 and 44.68.52.254 and this is what I >received for both: < ... SNIP ... > >The last hop (88.149.154.126) is address space in Italy ? Interesting... 88.149.x.x addresses have been trying to hack me and keep getting banned. Although, not specifically that address. Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) (530) 263-1595 (Home/Office) ______________________________________________ ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

2 2

Re: [44net] routable or private?
by Bryan Fields 31 Mar '14

31 Mar '14

On 3/31/14, 4:04 PM, Steve Wright wrote: > Can we please make a decision on this and move ahead? > > I'd like to know, one way or the other, because I sure aint interested in > all this private 44net stuff.. > > Is 44net routable or private? I vote routeable. My /24 is announced, can't say I really work that hard to keep my tunnels updated. I use my space to provide services to amateur radio and the internet. I just lit up an Allstar RTCM node and asterisk server for simulcast recently. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re: [44net] routable or private?
by William Lewis 31 Mar '14

31 Mar '14

If we give 44/8 back, then those of us routing 44 traffic over RF to other 44 stations get screwed, now don't we. :/ 44/8 is for amateur radio only. There are plenty of us using it. I have ports to both other 44 stations, as well as BPQ stations that can't use it. Beside, no one is mandating any station use it in their configurations. The beauty of *you* not wanting to use it is..... You don't have to. The beauty of *me* wanting to use it is.... I get to. Bill KG6BAJ At 01:04 PM 03/31/14, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ > > If this is, " a hack to backbone a semi-private network on top of the > > public internet" then why do we need 44/8? Please explain why 10/8 would > > not work just as well? > > > >[....] if it's not going to be routable then why do we need 44/8? use > > RFC1918 space and give 44/8 back. [...] We could attract many > > into this hobby if we'd simply offer to be the teachers of the IP > > networking craft using standards based methods used by everyone else >across > > the internet. > > > >PRECISELY. > >Can we please make a decision on this and move ahead? > >I'd like to know, one way or the other, because I sure aint interested in >all this private 44net stuff.. > >Is 44net routable or private? > > > >Steve >

2 1

Can't add redundant AMPR gateway to portal
by Bart Kus 31 Mar '14

31 Mar '14

Screenshot This network (44.24.240.0/20) is available via both 209.189.196.68 and 198.178.136.80. However, I'm unable to list more than one point of contact. I realize this was probably a design decision at some point, but it doesn't seem like a good idea from a redundancy perspective. --Bart PS: If you're wondering why the image looks like crap, it's to satisfy the puny 32kB message size limit of the list.

11 29

marking and iproute2
by Michael E Fox - N6MEF 31 Mar '14

31 Mar '14

I've been told that one can use iptables (presumably the mangle table) to mark packets inbound on different interfaces and then use iproute2 to send the responses back out the same interface. Is anyone doing this and, if so, would you be willing to share how you do that? Thanks, Michael N6MEF

1 0

isn't 44net being a "full mesh" a misnomer? Is it even necessary?
by Eric Fort 31 Mar '14

31 Mar '14

It would seem to me that while due to the fact we are tunneling most everything we may have a logical full mesh but far from a physical full mesh. What does a tunneled logical full mesh really accomplish for us other than making things all the more complicated? Wouldn't traditional peering and routing done "the normal way" be much easier? I can see a valid place for nailing up vpn links and various tunnels, i.e. last mile access and tying islands together though something other than IPIP with links negotiated on a peering basis as needed, but what does a full logical mesh of tunnels give us? It seems that since it's built of tunnels and thus virtual rather than physical we just unnecessarily complicate the mess wherein the tunneled traffic and the tunnels themselves end up taking multiple and somewhat changing hops to get from one end to another. IP was designed such that I could hand a packet off and basically go, "ok, now it's your problem to deliver it (on a best effort basis)", thus I shouldn't need to know every conceivable route to every conceivable endpoint. What prevents us from using it that way? Eric AF6EP

8 12

Re: [44net] 44Net Digest, Vol 3, Issue 61
by Steve Wright 31 Mar '14

31 Mar '14

> I've created a basic tutorial on the wiki for setting up a Ubuntu > Server gateway. > Good work! I'd be keen to help with a wiki page on a Mikrotik connection example. I have hardware installed, and also have Kamikazi running on MetaROUTER if anyone wants to fiddle with it. Steve -- Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers +64 21 040 5067

2 1

Re: [44net] 195.146.144.9.80 oddness
by kb9mwr＠gmail.com 30 Mar '14

30 Mar '14

Marius, Correct you are. Dumb mistake on my part. Happens when you have been up all night apparently.

1 0

195.146.144.9.80 oddness
by kb9mwr＠gmail.com 30 Mar '14

30 Mar '14

Weirdness: I don't have a DNS entry for 44.92.21.1.80, as it is non existant on the network I feed. So how is it that I get constant activity from it? Does anyone else get a lot of traffic from that IP address? tcpdump -vvv -s0 -n proto ipencap 9515068, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 195.146.144.9.80 > 44.92.21.1.80: Flags [S], cksum 0x0a01 (correct), seq 186 tcpdump -i eth0 -vvv host amprgw.sysnet.ucsd.edu or ip proto \\icmp amprgw.sysnet.ucsd.edu > CPE-75-87-213-229.new.res.rr.com: IP (tos 0x0, ttl 81, id 33817, offset 0, flags [DF], proto TCP (6), length 52) sme.sk.http > hsmm-gw.kb9mwr.ampr.org.http: Flags [S], cksum 0xdff7 (correct), seq 1415087399, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

2 2

Wiki User Registration Impossible?
by Ryan Elliott Turner 29 Mar '14

29 Mar '14

Hey list, I'd love to document some of the recent discussion (private 44net space? rip vs encap? encap location?) but I can't edit any pages without being authenticated it seems. On top of that, there is no link to the registration URL. When I try to go to the registration URL ( http://wiki.ampr.org/index.php?title=Special:UserLogin&type=signup ), I get the error "You do not have permission to create this user account". So, I'd love to help start documenting this stuff, but seems like I'll need some help myself first. -- Ryan Turner

3 3

44Net Private addressing
by Rod Ekholm 29 Mar '14

29 Mar '14

I found a statement on http://en.wikipedia.org/wiki/AMPRNet that says: 44.128.0.0/16[edit<http://en.wikipedia.org/w/index.php?title=AMPRNet&action=edit&section=2> ] *44.128.x.x* is the testing subnet and consists of 65,536 (216) addresses. Much akin to 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16 or 192.168.0.0/16, this is an unroutable private IP block<http://en.wikipedia.org/wiki/Private_network>. Connectivity to the rest of the network should be given through router gateways <http://en.wikipedia.org/wiki/Gateway_(telecommunications)> much as one would do with Network address translation<http://en.wikipedia.org/wiki/Network_address_translation> in any other private IP block. Is this truly the case? When I look at the portal, this /16 would be towards the end of the US allocations, and just before the Japan allocations. If this is not true, do we have a Private block in the 44/8 for use that is not routable? -- Rod Ekholm kc7aad(a)gmail.com

4 3

Re: [44net] 44Net Digest, Vol 3, Issue 19
by Steve Wright 26 Mar '14

26 Mar '14

Interesting reading! I too would like to see a routed approach - all this clumsy tunnelling house of cards junk is never going to be reliable. The overly-managed approach doesn't help either. It needs to be far simpler to manage a /24 than what we have now. All the legal speak in that "contract" can get binned too. As far as outdoor links are concerned - why do you not use the Ubiquiti 2.4,3.3, and 5.8Ghz gear? It goes really really over long distances even without external amps, and will happily run in the ham bands. Steve On Tue, Jan 28, 2014 at 9:00 AM, <44net-request(a)hamradio.ucsd.edu> wrote: > Send 44Net mailing list submissions to > 44net(a)hamradio.ucsd.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://hamradio.ucsd.edu/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)hamradio.ucsd.edu > > You can reach the person managing the list at > 44net-owner(a)hamradio.ucsd.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > > Today's Topics: > > 1. Re: amprnet portal (Bryan Fields) > 2. Re: amprnet portal (kb9mwr(a)gmail.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Jan 2014 18:09:57 -0500 > From: Bryan Fields <Bryan(a)bryanfields.net> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] amprnet portal > Message-ID: <52E595C5.9090303(a)bryanfields.net> > Content-Type: text/plain; charset=ISO-8859-1 > > On 1/26/14 2:20 PM, kb9mwr(a)gmail.com wrote: > > It would be interesting to hear more about how those other BGP > > announced chunks of 44net are using the space. > My segment 44.98.254.0/24 is being used for one PtP data link now, and > some > asterisk based repeater controllers. > I have email for kb9mci.net on it (but need to get SWIP/PTR going Brian > ;). > > My intent is to fire up some of the doodle labs 23cm link cards as we get > another repeater site and link it over on that space. As this grows over > the > next couple years it will be quite a high speed data network with VoIP as > the > primary purpose. Doing all the RF links in the ham bands is part of the > fun. > (anyone have a OFDM rated 20-30 watt amp for 23cm that's not $2k?) > > One of the pet peeves I've have is not being able to access the other AMPR > net > space with out tunnels. I think tunnels are just an ugly hack IMO. I'd > like > to see us transition into more of a regionally routed network, rather than > the > few BGP nets and UCSD gateway. Well aware of how much time this would take > I'm not ready to write up a proposal just yet (ampRFC?). > > If anyone wants a subnet I'd be happy to route it to you, as I'm not using > the > whole /24 and won't be for some time. Global routing policies being what > they > are, a /24 is the smallest subnet you can announce. > > My interest lies in high speed networks, and see little to no value in 9600 > baud IP networks in 2014 :) > > 73's > > -- > Bryan Fields > > 727-409-1194 - Voice > 727-214-2508 - Fax > http://bryanfields.net > > > > ------------------------------ > > Message: 2 > Date: Mon, 27 Jan 2014 12:06:01 -0600 > From: kb9mwr(a)gmail.com > To: "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] amprnet portal > Message-ID: > < > CAK4XxyT5f_UxV5CpzHRX9O0QEtUbGxD0txexZHGRDQTTdA_9yg(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Brian, > > Interesting, thanks for sharing. > > Amplifiers are something I really think the ham community needs to think > about. > > They exist, but like you say, but at outrageous prices. i.e.: > > http://www.shireeninc.com/300-500mhz-20-watts-outdoor-amplifier/ > > I have been reading Dubus magazine (focused on microwave), hoping to > read more data oriented construction articles. > > I am much in the same line of thinking. 1200 and 9600 is really not > worth re-deploying in 2014. The regulatory landscape needs some major > changes so that manufactures can put something different in the hands > of many. > > Steve > > > ------------------------------ > > _______________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net > > > End of 44Net Digest, Vol 3, Issue 19 > ************************************ > -- Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers +64 21 040 5067

13 19

Re: [44net] 44Net Digest, Vol 3, Issue 58
by Rob Janssen 26 Mar '14

26 Mar '14

44net-request(a)hamradio.ucsd.edu wrote: > I have had a couple requests to tailor my attempt to document setting > up a Linux AMPRNet gateway for the Raspberry Pi. > > I've just recently purchased a Pi and have been looking over the > documentation, and I don't think it will work for what I'm trying to > document. I have a quite simple setup for a Raspberry Pi as a Linux AMPRnet gateway, but in my experience everyone's setup is different and what works fine for me is not what other people want to use. My Raspberry Pi is in a datacenter so no NAT worries. It terminates all tunnels (IPIP) and users Marius' RIP daemon for automatic routing. This works very well after we have ironed out some problems. It also runs a local copy of KA9Q NET which I access from home via "screen", and it forwards a subnet of 44 adresses via an IPsec tunnel to my home machine, where several of these addresses are used to provide other services (e.g. WWW). The setup basically only brings up tunl0 and assigns an address, sets up a separate route table and rules for net-44, manually inserts a couple of routes and then fires up the ampr-ripd. Maybe 10 lines of bash code, that is all. As I wrote, the setup is very simple and the details vary enough for it to be less useful to others than I thought. I forwarded my complete config to a fellow amateur who has a Raspberry Pi as well, ready for him to load it, but he never did that and somehow prefers to build it again for himself. And probably that is better anyway, as most of the fun of building such a thing is the studying of the matter and the debugging. Tinkering with the Raspberry Pi and networking is like homebrewing, copying an existing configuration is like buying a shiny new Icom. Rob

1 0

Re: [44net] Linux Gateway Tutorial
by kb9mwr＠gmail.com 26 Mar '14

26 Mar '14

--- Snip --- One of the major drawbacks to the IPIP tunnels used to transport AMPRNet data is that they don't work when you are using Network Address Translation (NAT). --- Snip --- I disagree. As long as protocol 4 is forwarded (or just use DMZ) it works fine. I use 192.168.1.X on all my normal stuff at home, and my Ras Pi running rip44d has a an address of 192.168.1.2. In my main home router I point DMZ to that address of the Pi. I use a single USB dongle and that interface has a 44.92.X.X address and connects to some Ubiquiti gear. Works fine. http://www.qsl.net/kb9mwr/wapr/tcpip/rip44d.html http://www.qsl.net/kb9mwr/wapr/tcpip/

1 0

44net cool toys
by Steve Wright 25 Mar '14

25 Mar '14

Ok what are people actually DOING over their Internet-connected 44 radio net? VOIP? APRS? Video links? Repeater linking? IP cameras? Remote bases? Any innovative suggestions? Steve -- Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers +64 21 040 5067

7 11

Re: [44net] 44Net Digest, Vol 3, Issue 57
by Steve Wright 25 Mar '14

25 Mar '14

> From: "Marius Petrescu" <marius(a)yo2loj.ro> > Why do you need to get off this list to do it another way? > That is the whole idea of this list: Find new ways, and share your ideas. > Boldly go where no one has gone before :-) Sorry, I received a very discouraging email from a list member. I'll go back to my usual tasks for a while. Steve

1 0

Can't add redundant AMPR gateway to portal
by Bart Kus 25 Mar '14

25 Mar '14

Screenshot This network (44.24.240.0/20) is available via both 209.189.196.68 and 198.178.136.80. However, I'm unable to list more than one point of contact. I realize this was probably a design decision at some point, but it doesn't seem like a good idea from a redundancy perspective. --Bart PS: If you're wondering why the image looks like crap, it's to satisfy the puny 32kB message size limit of the list.

1 0

Cannot find encap.txt file in portal
by Jesse Hindmarsh 25 Mar '14

25 Mar '14

Can someone tell me if the encap.txt file is still available in the portal? I was looking for it today and cannot seem to find it. Thanks Jesse - WC3XS

5 4

Re: [44net] ampr.org IP addresses available for New Jersey.
by Bryan Fields 24 Mar '14

24 Mar '14

On 3/24/14, 7:22 PM, Robbie De Lise wrote: > Each link you setup between 2 nodes in the mesh needs a /30. > You can get 64 /30's in a /24. /31's are better :) http://tools.ietf.org/rfc/rfc3021.txt 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

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

24 Mar '14

On 3/22/14, 11:14 AM, Geoff Joy wrote: > 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. +1 I've said there are numerous things I don't care for with the way 44net is used and deployed (not a personal attack :). I've also mentioned I don't have the time to write up proposals and do stuff to change it. As such I'm not going to bitch about it (or at least try not to). I'd be happy to start a working group if I have some help, but between my day job, building a simulcast repeater system, and doing the paperwork to get our repeater group to to be 501c3 non-profit I just don't have the time to do it all myself. I for one would like to get away from the IPIP encap, and get more distributed interconnects to the internet for 44/8. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

8 8

ampr.org IP addresses available for New Jersey.
by Mark Phillips 24 Mar '14

24 Mar '14

Hi all, It's a work in progress but the following link should provide a link to the IP 44/8 address allocation document for NJ. http://mrprosser.g7ltt.com We have very little AX.25 traffic in NJ but we do have a growing Mesh community which would benefit from this space. Hands up if you want some! Mark

5 5

Re: [44net] 44Net Digest, Vol 3, Issue 56
by Steve Wright 24 Mar '14

24 Mar '14

> From: Robbie De Lise <robbie.delise(a)gmail.com> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] 44net problems - was: 44net cool toys > > We announce 44.144.0.0/16 over BGP to the public internet (in Belgium) > This ip space is then run on our local variant of "hamwan/hamnet" in > Belgium on 2.4ghz accesspoints and 5ghz and recently 24ghz backbone > links. > [....] very interesting read trimmed Well done! Very nice! I think the best way to set up my local HamWAN is just to get off this list and go do it your way. Others can also make up their mind for themselves. Steve

2 1

How do I work the gateways robot?
by Mark Phillips 24 Mar '14

24 Mar '14

Hi folks, Is there a howto available that will tell me how to work the gateways robot? I am almost done working on the subnet breakdown for NJ (I'm the NJ co-ord) and will be needing to make some changes in order to put the plan into place. I'll be looking to add hosts to the DNS, change some existing hosts and change the master NJ subnet gateway (currently pointed at my house). I'm not proposing anything that hasn't already been done before. I'm simply chopping up the subnet into further subnets and allocating them to each of the counties with the "spare" numbers then being available for clever data experiments should there be any. Ordinarily I'd be doing this via the portal but ...... Thanks Mark G7LTT/NI2O

2 9

ham mesh ip address
by Daniel Curry 23 Mar '14

23 Mar '14

I was wondering if the 44 ip address can be use for ham mesh 2.4 GHz channel 1 - 6? Reason for the question is from what I understand that is the amateur radio frequency and it should be ok? Hey just asking. K6DLC -- Daniel Curry IPV6 Sage Certified PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92 San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]

4 3

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

Portal security
by Chris 10 Mar '14

10 Mar '14

Over the past few weeks, the portal has been subject to several brute force attacks on random usernames. In the past few days some accounts have been compromised because they used weak passwords. The attackers didn't do anything with any of the compromised accounts, it was most likely a script collecting valid usernames & passwords for later use. As a result I have tightened up security and some accounts will tell you that you need to verify your email address when you try to login. Please follow the link to have the verification email sent to you, then follow the instructions in the email when you receive it. Due to the enhanced security you will notice a CAPTCHA appears if you get your password wrong a few times, if you continually get your password wrong, the response time for the login process will get longer - this is intentional. It would help greatly if you could use a strong password, one that is at least 12 characters in length and contains a mixture of letters, numbers and punctuation characters, no "real" words and no "numbers instead of letters", e.g. "numb3r". Thanks, Chris

3 3

Portal password / login failure
by Willie Hein WJ3G 06 Mar '14

06 Mar '14

Is it just me, or is there a problem logging in to the portal? tia Willie, WJ3G

6 22

44Net Digest, Vol 3, Issue 44
by Gabriel Medinas 27 Feb '14

27 Feb '14

Hello Rob, thanks for your information, I changed to 44.0.0.1 from 169.228.66.251, but dont see here any rip broadcast from this IP, i waiting if arrive in any moment. 73 de Gabriel. YV5KXE YV AmpNet Coordinator 44net-request at hamradio.ucsd.edu wrote: > Subject: > [44net] RIP UDP question > From: > Gabriel Medinas <gmedinas at gmail.com> > Date: > 02/26/2014 05:48 PM > > To: > 44net at hamradio.ucsd.edu > > > Hello all, > > I want test to receive the RIP2 broadcast in my JNOS but dont work: > > Trace jnos monitor: > > (tun0) 169.228.66.251->192.168.2.110 UDP Don't use that version. Use the one that is from 44.0.0.1 -> 224.0.0.9 instead. (there are two RIP broadcasts and some time ago Brian already considered to stop the one from 169.228.66.251 to the public IP adress. This one is sent to a different portnumber so your jnos probably does not recognize it) Rob

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 44
by Rob Janssen 26 Feb '14

26 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] RIP UDP question > From: > Gabriel Medinas <gmedinas(a)gmail.com> > Date: > 02/26/2014 05:48 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Hello all, > > I want test to receive the RIP2 broadcast in my JNOS but dont work: > > Trace jnos monitor: > > (tun0) 169.228.66.251->192.168.2.110 UDP Don't use that version. Use the one that is from 44.0.0.1 -> 224.0.0.9 instead. (there are two RIP broadcasts and some time ago Brian already considered to stop the one from 169.228.66.251 to the public IP adress. This one is sent to a different portnumber so your jnos probably does not recognize it) Rob

1 0

RIP UDP question
by Gabriel Medinas 26 Feb '14

26 Feb '14

Hello all, I want test to receive the RIP2 broadcast in my JNOS but dont work: Trace jnos monitor: (tun0) 169.228.66.251->192.168.2.110 UDP 0000 ........pLaInTeXtpAsSwD.....,.......[yZ.........,.........Y..... 0040 ....,.......E..>........,.......Q.v>........,I@.....2.D>........ 0080 ,.@.....[yZ.........,.......[yZ.........,I......2.D>........,... 00c0 ....W...........,...................,........K..........,....... 0100 ............,........&..........,^..................,.......v... 0140 ........,........K..........,........K..........,.......yc...... 0180 ....,........K..........,.......^e0.........,........K.......... 01c0 ,........K...... (tun0) 192.168.2.110->169.228.66.251 ICMP UnreachablePort Returned 169.228.66.251->192.168.2.110 UDP 192.168.2.110 is my JNOS IP in LAN (also 44.152.0.60) 169.228.66.251 (amprnetgw-ucsd) The jnos return a ICMP UnreachablePort, have check firewall, ip forwading in opensuse 13.1 linux, router and in my autoexec.nos: ip upstairs 224.0.0.9 rip ttl 43200 start rip #rip accept 44.0.0.1 rip accept 169.228.66.251 rip trace 9 rip.log My question, why my jnos said unreachablePort? Thanks. Gabriel YV5KXE

1 0

Re: [44net] Suggestion?
by kb9mwr＠gmail.com 24 Feb '14

24 Feb '14

Thanks Chris. Now if there is a problem originating from one of the gateways we know who to get a hold of. It may also be desirable if their callsign had a link to method of contact (email) that is on file for them. But I heard a whois function is in the works, and I assume that will have something like that. Steve

4 3

anyone seeing these?
by Brian 23 Feb '14

23 Feb '14

I've been getting absolutely bombarded with dns query frames most of which come from commercial IPs (that are now blocked) however I'm seeing some from what appears to be 44/8, but I suspect most of these are spoofed. There's always the chance someone's been compromised. An example from wireshark: 72 13.058158 44.96.84.78 44.88.0.9 DNS Standard query A oitutrxutxx.www.luse7.com I know this IP is not configured so it must be spoofed (aka: no DNS) and it doesn't appear to be alive, nor is this the only one from 44/8. 140 35.327781 44.180.172.99 44.88.0.9 DNS Standard query A ttx.www.luse8.com 595 181.341697 44.219.111.186 44.88.0.9 DNS Standard query A m.www.luse9.com I'm sure this is a DNS worm of sorts but it was attacking my MFNOS node (which does not even have a dns server compiled in it) at the rate of 500,000 frames a minute. While harmless to such, it's still bandwidth used for nothing. Has anyone seen these sort of junk dns requests before? -- 73 de Brian Rogers - N1URO email: <n1uro(a)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: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

2 1

Suggestion?
by kb9mwr＠gmail.com 23 Feb '14

23 Feb '14

On the gateways list page or under the details (at: https://portal.ampr.org/gateways_list.php) could another column be added to show the associated call sign of the person who maintains that entry? Right now there really doesn't seem to be a way to tell.

4 3

purposeful interloper...
by Jerome Schatten 23 Feb '14

23 Feb '14

Now this guy appears every 60 sec., and he obviously knows what he's doing. Anyone else seeing him? How does he do it? Sat Feb 22 14:12:57 2014 - tun0 recv: IP: len 74 169.228.66.251->192.168.1.149 ihl 20 ttl 50 prot IP IP: len 54 67.185.10.74->44.135.160.40 ihl 20 ttl 46 DF prot UDP UDP: len 34 48465->6781 Data 26 0000 CQ AMPR! CQ AMPR! CQ AMPR! Sat Feb 22 14:12:57 2014 - tun0 recv: IP: len 74 169.228.66.251->192.168.1.149 ihl 20 ttl 50 prot IP IP: len 54 67.185.10.74->44.135.160.40 ihl 20 ttl 46 DF prot UDP UDP: len 34 48465->6781 Data 26 0000 CQ AMPR! CQ AMPR! CQ AMPR! (encap) 67.185.10.74->44.135.160.40 DF UDP CQ AMPR! CQ AMPR! CQ AMPR! Sat Feb 22 14:12:57 2014 - tun0 sent: IP: len 56 192.168.1.149->67.185.10.74 ihl 20 ttl 254 prot ICMP ICMP: type Unreachable code Port Returned IP: len 54 67.185.10.74->44.135.160.40 ihl 20 ttl 46 DF prot UDP UDP: len 34 48465->6781 Data 26 jerome - ve7ass ------

3 2

Re: [44net] Cisco IOS Example?
by Jason Begley 23 Feb '14

23 Feb '14

Email me off list for some examples. I hope you are using something bigger than a 2651xm because the config gets too large for nvram otherwise. I'll also send you a script for converting the encap file to tunnels/routes too. 73 Jason ky9j -------- Original message -------- From: Phil Pacier - AD6NH <ad6nh(a)aprs2.net> Date: 02/15/2014 4:34 PM (GMT-05:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] Cisco IOS Example? (Please trim inclusions from previous messages) _______________________________________________ Good day all. Does anyone have a rough example of a 44Net tunnel setup for Cisco IOS? I only have a /32 to play with and would like to put it on the WAN router. Thanks! -- Phillip Pacier - AD6NH APRS Tier2 Network Coordinator --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

7 6

Every 10 seconds...
by Jerome Schatten 22 Feb '14

22 Feb '14

Maybe someone knows who '44.64.193.1' is and can contact him? tnx jerome - ve7ass Fri Feb 21 20:08:58 2014 - tun0 recv: IP: len 96 24.229.88.253->192.168.1.149 ihl 20 ttl 240 prot IP IP: len 76 44.64.193.1->224.0.0.5 ihl 20 ttl 1 tos 192 prot 89 0000 ...,.,.......r.....................(.................... Fri Feb 21 20:08:58 2014 - tun0 recv: IP: len 96 24.229.88.253->192.168.1.149 ihl 20 ttl 240 prot IP IP: len 76 44.64.193.1->224.0.0.5 ihl 20 ttl 1 tos 192 prot 89 0000 ...,.,.......r.....................(.................... (encap) 44.64.193.1->224.0.0.5 prot 89 0000 ...,.,.......r.....................(.................... (encap) 44.135.160.40->44.64.193.1 ICMP Time ExceededTime-to-live Returned 44.64.193.1->224.0.0.5 prot 89 0000 ...,.,.. Fri Feb 21 20:08:58 2014 - tun0 sent: IP: len 76 192.168.1.149->24.229.88.253 ihl 20 ttl 254 prot IP IP: len 56 44.135.160.40->44.64.193.1 ihl 20 ttl 254 tos 192 prot ICMP ICMP: type Time Exceeded code Time-to-live Returned IP: len 76 44.64.193.1->224.0.0.5 ihl 20 ttl 0 tos 192 prot 89 0000 ...,.,..

4 5

Odd Portal Login
by William Lewis 19 Feb '14

19 Feb '14

Is it just me..... or when first logging into the portal, it appears to not take your username and password, and gives you a second login screen. And then the second login screen does log you in. Am I the only one seeing this ?? Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) (530) 263-1595 (Home/Office) ______________________________________________ ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

4 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net