- 44net - mailman.ardc.net

Ampr

by lleachii.aol.com

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

11 years, 2 months

2
1
0 0

Re: [44net] Portal doesn't allow IPIP anycast via 44net

by lleachii＠aol.com

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

11 years, 2 months

14
41
0 0

Re: [44net] Running for ARDC director position

by lleachii.aol.com

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

11 years, 2 months

1
0
0 0

Re: [44net] Running for ARDC director position

by ktolliver

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

11 years, 2 months

4
4
0 0

Re: [44net] Running for ARDC director position

by .

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

11 years, 2 months

2
1
0 0

Re: [44net] Test New Tool - APRS Code Recovery

by Marius Petrescu

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

11 years, 2 months

8
12
0 0

Re: [44net] Running for ARDC director position

by .

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

11 years, 2 months

1
0
0 0

Re: [44net] Running for ARDC director position

by Bryan Fields

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

11 years, 2 months

4
3
0 0

Wiki

by Chris

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

11 years, 2 months

2
2
0 0

ampr.org subdomains

by Dean Gibson AE7Q

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

11 years, 2 months

2
1
0 0

Re: [44net] AMPRNet BGP vs non-BGP routing

by Bryan Fields

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

11 years, 2 months

3
2
0 0

NOS "versions"

by Eric Fort

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

11 years, 2 months

5
9
0 0

some answers I hope to latest NOS questions ...

by Maiko Langelaar

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

11 years, 2 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 71

by Rob Janssen

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

11 years, 2 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 71

by Rob Janssen

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

11 years, 2 months

2
1
0 0

44.133.48.66 !!!

by Maiko Langelaar

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

11 years, 2 months

4
5
0 0

ampr-ripd for openwrt

by Rob Janssen

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

11 years, 2 months

2
1
0 0

Re: [44net] Portal doesn't allow IPIP anycast via 44net

by kb9mwr＠gmail.com

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... ________________________________

11 years, 2 months

1
0
0 0

Wiki issues

by Neil Johnson

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

11 years, 2 months

2
2
0 0

Re: [44net] Portal doesn't allow IPIP anycast via 44net

by Bryan Fields

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

11 years, 2 months

3
2
0 0

Re: [44net] Portal doesn't allow IPIP anycast via 44net

by kb9mwr＠gmail.com

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)

11 years, 2 months

2
1
0 0

NANOG 61 June 2-4

by Bryan Fields

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

11 years, 2 months

4
3
0 0

Re: [44net] Portal doesn't allow IPIP anycast via 44net

by Bryan Fields

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

11 years, 2 months

1
0
0 0

Re: [44net] AMPRNet BGP vs non-BGP routing

by Bryan Fields

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

11 years, 2 months

2
1
0 0

Re: [44net] AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)

by Brian Kantor

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

11 years, 2 months

6
12
0 0

Portal doesn't allow IPIP anycast via 44net

by Bart Kus

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

11 years, 2 months

7
12
0 0

Can't communicate with 44.0.0.1 from 44-space?

by Bart Kus

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

11 years, 2 months

2
2
0 0

Linux Gateway Tutorial

by Neil Johnson

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

11 years, 2 months

13
24
0 0

Wiki Updates

by Neil Johnson

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

11 years, 2 months

1
0
0 0

Pi bug for ipencap?

by Brian Rogers

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.

11 years, 2 months

4
6
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 67

by Steve Wright

> 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

11 years, 2 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 66

by Bryan Fields

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

11 years, 2 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 66

by Steve Wright

> 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

11 years, 2 months

2
1
0 0

Re: [44net] routable or private?

by Steve Wright

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

11 years, 3 months

3
2
0 0

Re: [44net] routable or private?

by kb9mwr＠gmail.com

> 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.

11 years, 3 months

1
0
0 0

Re: [44net] 44net and consider... 100.64.0.0/10

by lleachii＠aol.com

* 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

11 years, 3 months

1
0
0 0

past and the future

by kb9mwr＠gmail.com

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

11 years, 3 months

3
2
0 0

Introducing myself

by charles＠thefnf.org

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.

11 years, 3 months

2
1
0 0

Re: [44net] routable or private?

by Steve Wright

> 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

11 years, 3 months

14
16
0 0

Re: [44net] routable or private?

by William Lewis

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.

11 years, 3 months

2
2
0 0

Re: [44net] routable or private?

by Bryan Fields

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

11 years, 3 months

2
1
0 0

Re: [44net] routable or private?

by William Lewis

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 >

11 years, 3 months

2
1
0 0

Can't add redundant AMPR gateway to portal

by Bart Kus

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 years, 3 months

11
29
0 0

marking and iproute2

by Michael E Fox - N6MEF

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

11 years, 3 months

1
0
0 0

isn't 44net being a "full mesh" a misnomer? Is it even necessary?

by Eric Fort

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

11 years, 3 months

8
12
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 61

by Steve Wright

> 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

11 years, 3 months

2
1
0 0

Re: [44net] 195.146.144.9.80 oddness

by kb9mwr＠gmail.com

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

11 years, 3 months

1
0
0 0

195.146.144.9.80 oddness

by kb9mwr＠gmail.com

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

11 years, 3 months

2
2
0 0

Wiki User Registration Impossible?

by Ryan Elliott Turner

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

11 years, 3 months

3
3
0 0

44Net Private addressing

by Rod Ekholm

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

11 years, 3 months

4
3
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 19

by Steve Wright

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

11 years, 3 months

13
19
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 58

by Rob Janssen

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

11 years, 3 months

1
0
0 0

Re: [44net] Linux Gateway Tutorial

by kb9mwr＠gmail.com

--- 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/

11 years, 3 months

1
0
0 0

44net cool toys

by Steve Wright

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

11 years, 3 months

7
11
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 57

by Steve Wright

> 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

11 years, 3 months

1
0
0 0

Can't add redundant AMPR gateway to portal

by Bart Kus

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 years, 3 months

1
0
0 0

Cannot find encap.txt file in portal

by Jesse Hindmarsh

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

11 years, 3 months

5
4
0 0

Re: [44net] ampr.org IP addresses available for New Jersey.

by Bryan Fields

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

11 years, 3 months

2
1
0 0

Re: [44net] 44net problems - was: 44net cool toys

by Bryan Fields

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

11 years, 3 months

8
8
0 0

ampr.org IP addresses available for New Jersey.

by Mark Phillips

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

11 years, 3 months

5
5
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 56

by Steve Wright

> 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

11 years, 3 months

2
1
0 0

How do I work the gateways robot?

by Mark Phillips

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

11 years, 3 months

2
9
0 0

ham mesh ip address

by Daniel Curry

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]

11 years, 3 months

4
3
0 0

Re: [44net] 44net problems - was: 44net cool toys

by Bryan Fields

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

11 years, 3 months

4
3
0 0

YV Gateway on air (again)

by Gabriel Medinas

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

11 years, 3 months

2
1
0 0

Re: [44net] 44net problems - was: 44net cool toys

by Geoff Joy

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

11 years, 3 months

2
2
0 0

44net problems

by Steve Wright

> #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

11 years, 3 months

1
0
0 0

Re: [44net] 44net problems - was: 44net cool toys

by Steve Wright

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

11 years, 3 months

8
8
0 0

Re: [44net] 44net cool toys

by Steve Wright

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

11 years, 3 months

7
6
0 0

OT: FCC Invites Public Comment on Petition Affecting 10-10.5 GHz Band

by Bryan Fields

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

11 years, 3 months

1
0
0 0

Re: [44net] 44net cool toys - not

by kb9mwr＠gmail.com

>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.

11 years, 3 months

3
3
0 0

Re: [44net] 44net cool toys - not

by Steve Wright

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

11 years, 3 months

4
3
0 0

NTP 'monlist' DDOS attacks

by Brian Kantor

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

11 years, 3 months

3
2
0 0

Portal security

by Chris

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

11 years, 3 months

3
3
0 0

Portal password / login failure

by Willie Hein WJ3G

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

11 years, 3 months

6
22
0 0

44Net Digest, Vol 3, Issue 44

by Gabriel Medinas

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

11 years, 4 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 44

by Rob Janssen

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

11 years, 4 months

1
0
0 0

RIP UDP question

by Gabriel Medinas

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

11 years, 4 months

1
0
0 0

Re: [44net] Suggestion?

by kb9mwr＠gmail.com

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

11 years, 4 months

4
3
0 0

anyone seeing these?

by Brian

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.

11 years, 4 months

2
1
0 0

Suggestion?

by kb9mwr＠gmail.com

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.

11 years, 4 months

4
3
0 0

purposeful interloper...

by Jerome Schatten

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 ------

11 years, 4 months

3
2
0 0

Re: [44net] Cisco IOS Example?

by Jason Begley

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

11 years, 4 months

7
6
0 0

Every 10 seconds...

by Jerome Schatten

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 ...,.,..

11 years, 4 months

4
5
0 0

Odd Portal Login

by William Lewis

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.

11 years, 4 months

4
3
0 0

rip44d

by lleachii＠aol.com

Marius, Are you still maintaining perl based rip44d software? -Lynwood KB3VWG

11 years, 4 months

3
6
0 0

Re: [44net] annual reminders

by William Lewis

Brian / Chris: I take some of that back..... Upon further testing, if I edit someone's region description, the portal tells me it saved it. But when I go back into the record, it is *not saved* at all. So, bug report of a different nature. Thanks Bill Lewis / KG6BAJ

11 years, 4 months

5
5
0 0

Cisco IOS Example?

by Phil Pacier - AD6NH

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

11 years, 4 months

1
0
0 0

Re: [44net] ampr-ripd 1.9 released

by Rob Janssen

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] ampr-ripd 1.9 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/13/2014 05:14 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello OMs, > > Latest update, with improvements (again) sugested by Rob Jannsen (PE1CHL) - > tnx. Rob. > > - added option to adjust TCP window size on routes > - console is now detaching on daemon startup It works well, thank you! Rob

11 years, 4 months

1
0
0 0

Re: [44net] ampr-ripd 1.8 released

by Rob Janssen

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] ampr-ripd 1.8 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/12/2014 06:15 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > -w is a good idea and I will implement it. > > Regarding the daemon function, AFAIK it is not available on all systems and > does not have a standardized behavior. > I wrote the code as portable as possible (e.g. static memory allocations, > minimal needed libraries). > Since the only action on the parent is exit(), I don't think that waiting > time is relevant. > > Thank you for your input. > > Marius, YO2LOJ Ok. I think daemon is available on many Unix/Linux-like platforms. However, it is not a very complicated function. What you wrote in ampr-ripd is nearly the same, except for that daemon() closes stdin, stdout and stderr when going to daemon mode. At least on a debian system, when ampr-ripd is started from a shell script under /etc/init.d, and when it does not close the controlling tty, init keeps a process running (startpar) that waits until it does that. I think that is part of the logic that prints the OK or FAIL messages in the init procedure. So, you could add some fclose or close calls in that part of the code. (only when verbose=0) I used the following workaround before I discovered daemon(): ampr-ripd -options </dev/null >/dev/null 2>&1 Rob

11 years, 4 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 34

by Rob Janssen

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 33 > From: > Steve Wright <stevewrightnz(a)gmail.com> > Date: > 02/11/2014 11:41 PM > > To: > 44net(a)hamradio.ucsd.edu > > >> > >> > >> > Any connects from ports >> >below 1024 are highly suspect for being reflection attacks so above I >> >block them all. > Another good trick is to block all outgoing connects to port 80 - this > makes it quite inconvenient for a virus to download its payload. In fact, > block all outgoing connects, and allow only what YOU want to do. Well, I do have that on the webserver at work. What those injection-attacks on PHP programs often do is include something that is fetched from a remote webserver. As the webserver cannot make outgoing connects, this always fails. However, for a typical hamradio computer that serves both as a server and a client, blocking outgoing port 80 is a bit unpractical. The attack is still/again going on, this time with source port 119: 21:49:23.716879 216.18.208.109 -> 44.137.41.97 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:24.514385 216.18.208.109 -> 44.137.41.101 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:24.819003 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:25.914034 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:25.927587 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:27.009032 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:27.349359 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:28.106015 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 Rob

11 years, 4 months

1
0
0 0

ampr-ripd 1.8 released

by Marius Petrescu

Hello OMs, Another addition and a new version. Added support for setting a specific route metric for the created routes using the -m option (regular routes until now had metric 0). This allows routes from other sources, e.g. BGP or OSPF to take precedence over those created by ampr-ripd. For those not needing "fancy" routing, there's no need to upgrade. Download from http://www.yo2loj.ro/hamprojects/ or http://yo2tm.ampr.org/hamprojects/ (as usual), or get it via github: https://github.com/yo2loj/ampr-ripd/ Direct links: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.8.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.8.tgz Have fun, Marius, YO2LOJ

11 years, 4 months

2
2
0 0

Re: [44net] ampr-ripd 1.8 released

by Rob Janssen

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] ampr-ripd 1.8 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/11/2014 06:00 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello OMs, > > Another addition and a new version. > > Added support for setting a specific route metric for the created routes > using the -m option (regular routes until now had metric 0). > This allows routes from other sources, e.g. BGP or OSPF to take precedence > over those created by ampr-ripd. When you make another version, consider: - a -w option to set the window (now fixed at 840), setting 0 means no window setting. - in the section to become a daemon, make use of the daemon() function. e.g.: if (FALSE == debug) { if (daemon(0,verbose)<0) { PERROR("Can not become a daemon"); } } The advantage is that the program detaches from the terminal, which is required when you want to start it in a /etc/init.d script and do not want to keep init waiting for the program. Rob

11 years, 4 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 33

by Steve Wright

> > > Any connects from ports > below 1024 are highly suspect for being reflection attacks so above I > block them all. Another good trick is to block all outgoing connects to port 80 - this makes it quite inconvenient for a virus to download its payload. In fact, block all outgoing connects, and allow only what YOU want to do.

11 years, 4 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 32

by Rob Janssen

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 31 > From: > John Ronan <jpronans(a)gmail.com> > Date: > 02/10/2014 10:01 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hi Rob/all, > Well as long as it wasn't just me the packets were hitting, I'm happier :). I guess your 'firewall' is a chain you created yourself? Either that or my iptables/kernel is quite a bit older than yours. > > Thats a nice/handy ruleset actually, thanks for the reply. > > Oh, apologies for my slowness in replying, birthday party (my own) Saturday meant I was recovering yesterday. > > Regards > John > EI7IG Yes, "firewall" is a chain that is joined to the INPUT chain for some of the traffic. In a typical Linux tunneling server you first separate the raw input and the tunnel input, and then deal with that in separate chains. In my tunnel router I have 4 of them, one for internet traffic to the public IP address, one for traffic destined to the 44-net address of the router, one for 44-net traffic routed thu to systems behind my router, and one for traffic destined to my locally running copy of NETCHL (most others would use JNOS there). It gets kind of difficult to handle all of that in one INPUT chain. So my INPUT chain is built like this: iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -i eth0 -d 111.222.333.444 -j firewall iptables -A INPUT -i tunl0 -j firewall2 etc, and similar for the FORWARD chain. BTW, the "attack" on http (which probably was not sourced from the addresses in the packets, but was rather meant to be a reflection attack on some other party) continued through today and ended a few hours ago. The second example that I posted became the main attack later, and I added another rule below the first line in my example: iptables -A firewall -p tcp -m multiport --sport 0:1023 --syn -j DROP This blocks any incoming connects that are coming FROM port numbers below 1024. Those do not occur in normal practice. Port numbers below 1024 are "special" ports for protected system services and normally are never the source port for connects. Any connects from ports below 1024 are highly suspect for being reflection attacks so above I block them all. Rob

11 years, 4 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 31

by Rob Janssen

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] incoming traffic. > From: > John Ronan <jpronans(a)gmail.com> > Date: > 02/09/2014 05:10 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hi All, > > I've seeing continuous traffic coming in from amprgw.sysnet.ucsd.edu. from 5.135.135.42 to 44.155.6.1 port 80 over my tunnel. Anyone else seeing the same? > > > I've disabled my tunnel for the moment as I don't have the time at the moment to chase it down. > > Regards > John > EI7IG It is not specifically from that address. It appears to be a distributed attack on http servers, at least to network 44. I see the same incoming stream of connects to several hosts in my subnet, all from a different source IP. Sometimes after several hours it stops and starts from another IP. I have crafted iptables rules that block it effectively: iptables -A firewall -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A firewall -p tcp --syn -m recent --name tcp --set iptables -A firewall -p tcp --syn -m recent --name tcp --update --seconds 30 --hitcount 15 -j DROP iptables -A firewall -p tcp --dport 80 --syn -j ACCEPT iptables -A firewall -p tcp --dport 443 --syn -j ACCEPT iptables -A firewall -p tcp -j DROP It just drops any source IP that sends more than 15 connects in 30 seconds. Adjust for the port numbers that you want to accept (80 and 443 in this example) There is also an internet-wide scan from source address 64.78.174.63 with traffic like this: 21:04:33.762663 64.78.174.63 -> 44.137.40.2 TCP 52 [TCP Port numbers reused] http > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 I see it on another server outside net-44 as well. It is blocked by the same rule but I have just firewalled the entire 64.78.160.0/20 net as this does not look like someone I want to deal with. Rob

11 years, 4 months

2
1
0 0

Reg Exp

by William Lewis

BTW.... Anybody in the group good at formulating REGEX expressions ? If so, contact me off-list. kg6baj(a)n1oes.org Thanks Bill

11 years, 4 months

1
0
0 0

Mail Hacker

by William Lewis

Thanks to all that replied. Got the iptables to forward the connects to my linux side where the commercial postfix server is running. Postfix doing what it's supposed to and killing it all if it's not a user on my box. Again, thank you to all who gave suggestions. Bill KG6BAJ

11 years, 4 months

1
0
0 0

incoming traffic.

by John Ronan

Hi All, I've seeing continuous traffic coming in from amprgw.sysnet.ucsd.edu. from 5.135.135.42 to 44.155.6.1 port 80 over my tunnel. Anyone else seeing the same? I've disabled my tunnel for the moment as I don't have the time at the moment to chase it down. Regards John EI7IG

11 years, 4 months

6
7
0 0

Re: [44net] Mail hacker

by kb9mwr＠gmail.com

Part of the beauty of our own IP address space is security provided by knowing your neighbors. I'd never run an open SIP or mail server on the wide internet anymore. Spam filtering is a big headache. Again, I'd firewall everyone but us for the mail port: iptables -A INPUT -s ! 44.0.0.0/8 -p tcp --dport 25 -j DROP If you have a google apps account (free for non profits) you can use them as a mail exchanger. Set your DNS records, to something like this: gvcity.ampr.org MX 10 gvcity gvcity.ampr.org MX 20 aspmx.l.google.com Outside (non 44 net) IP will timeout with a direct connect to 44.2.14.1 and will move try the next exchanger preference, in this case google. Google will accept the mail on your behalf, and they have good spam filtering (better than I could ever figure out how to incorporate with sendmail) and then I typically use fetchmail to transfer the mail from google back into my local mailboxes. If someone else wants to document a mailserver setup with spam protection, I'm all eyeballs on that one. I'm sure a number of people would appreciate that tutorial.

11 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net