44net January 2014

44net@mailman.ampr.org

49 participants
35 discussions

44.133.48.66 !!!
by Maiko Langelaar 12 Apr '14

12 Apr '14

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

4 5

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

06 Apr '14

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

4 6

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

26 Mar '14

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

13 19

Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20)
by Bryan Fields 01 Feb '14

01 Feb '14

On 1/29/14 2:05 PM, Steve Wright wrote: > This mesh crap really needs to be binned, or at the very least not try and > do anything important over it, such as route an entire /16. If you want to > connect a /24 with it to make a neat local play toy then go for it, but > using it as an enterprise routing tool is absurd at the very least, and at > it's WORST, it's very likely to just completely stop anyone from trying to > build anything new over it because it's connectivity and throughput sucks. This. So this is how I'd see it work, I need to write up a proposal for it. You have regional BGP routers that route subnets to the internet. These could then tunnel the subnets to end users via GRE. End users could route via an IGP over this tunnel to the regional speaker(s). Multiple tunnels would give redundancy. The regional speakers would have a tunnel between them. In the event of an outage the other BGP speakers would route subnets. Multiple links from end users to other BGP speakers (or non-speakers that are aggravation routers) would provide redundancy to the end users. Of course nothing prevents having a direct BGP speaker with an RF link to end users, most data centers will not have roof rights however. We could setup redistribution that would pull announcements from BGP if end nodes went down. Each BGP speaker could announce the subnets it knows about and a /8 providing we have a mesh of the backbone bgp speakers. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

10 13

Re: [44net] DNS records 44.131.56.0/24
by Michael E Fox - N6MEF 31 Jan '14

31 Jan '14

We've had a year of people putting things in, only to be told it isn't live yet. Damped annoying. If the thing is not live and if any entries made now will not be put in, then please, please take the darn link off the website until it IS ready. Michael Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Chris <chris(a)g1fef.co.uk> Date:01/20/2014 12:49 PM (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] DNS records 44.131.56.0/24 (Please trim inclusions from previous messages) _______________________________________________ Basically, the DNS portion of the portal is ready and awaiting deployment, we are implementing an email robot to run alongside, much the same as we did for the gateway robot, once it is completed and tested the whole thing can be deployed. The email robot should be ready in about a week. When it is deployed we will announce the fact on this list at which point any new requests will be processed, any requests sent in prior to the deployment will not be processed. Regards, Chris > On 20 Jan 2014, at 20:34, Nick G4IRX <g4irx.44net(a)nowindows.net> wrote: > > (Please trim inclusions from previous messages) > _______________________________________________ > Thanks for clarifying Chris. Presumably my requests will sit there until it becomes active? > > Nick. > >> On 20/01/2014 20:20, Chris wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >> The DNS section of the portal is not active yet > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

2 1

[nos-bbs] strange udp broadcasts...
by Nigel Vander Houwen 31 Jan '14

31 Jan '14

First, apologies for this email not being a valid reply. Finally got around to getting on the mailing list, so I haven't gotten the previous thread to reply to. I've adjusted our scripting that generates our AMPR tunnels on the HamWAN edge routers to disable neighbor discovery for those interfaces, and the change should now be in effect. Thanks, Nigel K7NVH

4 4

Re: [44net] [nos-bbs] strange udp broadcasts...
by Don Moore 30 Jan '14

30 Jan '14

I too am getting this and have been for a few weeks now but initiated by a different address... 07:04:00.406011 IP 209.189.196.68 > 192.168.1.150: IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 119 (ipip-proto-4) 07:05:00.408246 IP 209.189.196.68 > 192.168.1.150: IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 119 (ipip-proto-4) 73, Don On Thu, Jan 30, 2014 at 12:49 AM, Jerome Schatten <romers(a)shaw.ca> wrote: > 44ers... > > So every minute of every hour of every day, I get this below; it started > several weeks ago. It looks like it's coming from the Ampr portal -- why? > 24.84.205.232 is indeed my ip and it seems that 209.84.205.232 is the > same ip as the rip broadcasts are coming from. Is there any way to turn > this off other than turning off rip? > > Wed Jan 29 21:35:27 2014 - tun0 recv: > IP: len 167 209.189.196.68->192.168.1.149 ihl 20 ttl 55 DF prot IP > IP: len 147 0.0.0.0->255.255.255.255 ihl 20 ttl 64 prot UDP > UDP: len 127 5678->5678 Data 119 > 0000 ..1.....Seattle-ER1....6.7....MikroTik............FLNH-GLS0....R > 0040 B2011UAS......................T......ampr-24.84.205.232 > (encap) 0.0.0.0->255.255.255.255 UDP > 0000 ..1.....Seattle-ER1....6.7....MikroTik............FLNH-GLS0....R > 0040 B2011UAS......................T......ampr-24.84.205.232 > > jerome - ve7ass > > _______________________________________________ > nos-bbs mailing list > nos-bbs(a)tapr.org > http://www.tapr.org/mailman/listinfo/nos-bbs >

6 7

Getting mikrotik router gateway connected to amprgw
by Ryan Elliott Turner 30 Jan '14

30 Jan '14

Hi list, I'm trying to get a mikrotik RB2011 connected to AMPRGW but not having success. /ip route check 44.0.0.1 status: ok interface: ampr-gw nexthop: 44.0.0.1 /tool traceroute 44.0.0.1 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 44.34.128.1 0% 2 0.5ms 0.5 0.5 0.5 0 host unreachable from 44.34.128.1 2 0% 0 0ms Using the sniffer, I've tried to also ping my address (44.34.128.1) from the outside, but it does not get through. In addition, pinging 44.0.0.1 from the router fails as well (tracert shown above). I do however see a discovery attempt going out and not getting any response back. /tool sniffer quick interface=ampr-gw INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE ampr-gw 33.3 1 -> 44.34.128.1:5678 (discovery) 255.255.255.255:5678 (discovery) ip:udp 114 I do have an IPIP interface to the edge router for 44.24.240.0/20, and that is operating properly; I can access their network, and they can access mine. So, I'm a bit puzzled by this. My config amprgw: /interface ipip add local-address=99.173.137.24 name=ampr-gw remote-address=169.228.66.251 /ip route add distance=1 dst-address=44.0.0.0/8 gateway=ampr-gw Any help is greatly appreciated! -- Ryan Turner

3 8

Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20)
by Bryan Fields 30 Jan '14

30 Jan '14

On 1/30/14 12:47 AM, Heikki Hannikainen wrote: > As I understand it, currently all BGP sites must have an IPIP gateway too > to enable connectivity with all the rest of the non-BGP sites. This, i've got it going, but requiring a mesh of tunnels is nasty and it's hard to maintain (absent custom protocols) As it stands now, my BGP space can talk to the rest of the internet, but no other 44/8 (excluding the 9 BGP subnets). I'd love to write up an draft proposal for AMPRnet on how to fix this, but I just don't have the time right now. I'd want it as a standard that works on all routers at least for the "core". Perhaps even a route reflector software would work (ALU/CSCO/JNPR have this now). Even foundcade would work, the MLX's don't shit the bed anymore :) Mikrotik is not something you can put in a CO/datacenter for obvious reasons. I'd love to say we need a custom protocol, but the chances of getting that supported on anything production grade is slim to none. Argh, I'll have to make time to do this. I travel about 75% of the time for work, it sucks. I'm a bit hungover in an airport now even :) 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 20
by Steve Wright 29 Jan '14

29 Jan '14

With the BPG routed system, the > gateway is another weak link in the routing chain. What happens if > the BPG gateway goes down - every station down stream is isolated. > Yes thats correct. Why do you think an unreliable gateway is the proper way to build a network? If that subnet needs failover, then add failover. This is a volunteer effort, with > distributed network design and management. > No, it's a volunteer effort that's broken, because everyone wants to over-engineer some new unduly-complicated idea into a very uncomplicated system that actually works REALLY WELL EVERYWHERE else.. > What we have now, with IPIP Encap (protocol 4) is a FULLY MESHED > network. How much better can you get than a network that speaks DIRECTLY > gateway to gateway with NO intermediate hops??? Isn't this one of the > benefits of HSMM-Mesh in that any node that has a path to another node can > continue to pass traffic when other nodes have failed? > > This mesh crap really needs to be binned, or at the very least not try and do anything important over it, such as route an entire /16. If you want to connect a /24 with it to make a neat local play toy then go for it, but using it as an enterprise routing tool is absurd at the very least, and at it's WORST, it's very likely to just completely stop anyone from trying to build anything new over it because it's connectivity and throughput sucks. It's just a subnet for gods sake - stop playing with it and route the shit already, then we might actually get to DO SOMETHING over it. Puhleeease.. >

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net January 2014