June 2014 - PSDR - mailman.hamwan.org

Questions from poking around Cacti view of network?
by Kenny Richards 16 Sep '15

16 Sep '15

I was going through the graphs/data available via Cacti server and had few questions. 1) What are the Rainier and Tacoma PTP links for on Baldi? Both are showing no traffic recently, are they for future growth? 2) There are three PTP links at Paine I was curious about. I'm guessing the 'Monroe' link is really Bart's client node. But is the Shoreline and 'Bruce' PTP links purpose? The Shoreline link is showing lots of traffic, is that the uplink from the Westin? 3) There seems to be a big hole in the data in the last 24 hours, any idea what happen? Seems to impact all the data sources, so probably something on the server side? Thanks Kenny

6 7

8dB drop in ten minutes!
by Dean Gibson AE7Q 23 Jul '14

23 Jul '14

This morning (well after the update to v6.15 last night) just after 9:30am, I saw a 8dB drop in both TX and RX signal levels, which persist at this time. I did a "reset configuration", which did not solve the problem. Did anyone do a change at Paine sector 2 around 9:30am?

5 13

Switching to the 10MHz frequency plan
by Bart Kus 25 Jun '14

25 Jun '14

Hi, Can I hear any objections to switching to the 10MHz frequency plan? We'd be retaining the 5MHz bandwidths for now to keep the power spectral density high, it would just be moving the center frequencies onto the 10MHz plan. This switch would let us keep those center frequencies through 2 upgrade cycles sometime in the future: 1) Expansion from 5MHz to 10MHz channels 2) Expansion from 10MHz SISO to 10MHz MIMO Presently our speeds are limited to 10Mbit/sector. Upgrade phase 1 would bring us to 20Mbit/sector without any additional hardware costs. Upgrade phase 2 would bring us to 40Mbit/sector with a hardware replacement of sector antennas and sector modems. Hardware in phases 0 (present), 1 and 2 can happily co-exist within the same region if we take this change. If we stick on the 5MHz plan, any 10MHz hardware will interfere. The 20MHz plan collides with other radios present at some of our sites, so expansion to 20MHz will be difficult, if it ever happens at all. The 10MHz plan should be good for the next few years until we find some better solutions should the need for speed be there. Portland is thinking of bringing up a compatible system so that users can roam up and down the coast without re-programming and they've asked for confirmation on the frequencies. The other benefit of coordination onto the same channel plan is the border between the Washington and Oregon systems will not be full of interference. Users could roam between the systems seamlessly. If there are any objections to switching to the 10MHz plan, please speak up. --Bart

5 6

Re: [HamWAN PSDR] Internet Maintenance Notification
by Tom Hayward 16 Jun '14

16 Jun '14

Hi Jann, Our network is happy to receive your packets to 44.24.240.0/20 direct via internet, or IPIP encapsulated via 44.24.221.1. This is a published AMPR gateway (at least, it was listed in the encap a few hours ago when I last checked). We're not asking everyone to use BGP. In fact, we support packets from public/BGP networks and IPIP encapsulated packets alike. There is no spec that says gateways must be outside of 44.0.0.0/8. We picked 44.24.221.1 as a gateway because it fit the needs of our network only to discover later that it doesn't work with all AMPR configurations. There is no technical reason for this limitation; it merely comes down to configuration. I'd like to see the bugs worked out of the configuration so that what we publish to AMPR is honored. Our configuration conforms to the AMPR IPIP mesh design and works well with many existing AMPR networks. I don't know specifically why we can't communicate with your network. If you have manually installed a route to 44.24.240.0/20, that may be the problem. The route as defined in the AMPR encap file should work just fine, or if you like, just send packets out the default gateway and we will receive them via internet routing. Tom KD7LXL On Mon, Jun 16, 2014 at 10:07 PM, Jann Traschewski <jann(a)gmx.de> wrote: > Ooops, it's my gateway. I'm well aware of a missing IPIP route > (44.24.240.0/20 via 44.24.221.1 if I remember right) at DB0FHN. After > half a year I did reboot the machine and didn't reinstall that route > since I didn't expect anyone talking to us... > > The route 44.24.240.0/20 via 44.24.221.1 is very special since nobody > else uses a 44-address as a gateway IP-address for now. Tom might > remember my experiment to manually add this route at DB0FHN. The route > is not published by the AMPR gateway and even if it would publish it, it > would fail for most IPIP-gateways. So I'm pretty sure I was the only > IPIP-gateway supporting communication to 44.24.240.0/20. > > Since DB0FHN is the core router for the IPIP net44 connectivity of the > Hamnet, all Hamnet-Nodes doesn't have a special route to 44.24.240.0/20. > However most Hamnet-Nodes can talk *to* 44.24.240.0/20 since packets > will travel to their next default gateway in that particular region and > then will be processed by SNAT/DNAT or Masqueradeing with commercial IP > addresses. Of course that is not very useful for people coming *from* > 44.24.240.0/20 trying to contact Hamnet-Nodes. That's one of the reason > why I'm promoting the "amateur radio intranet" using net44-ip-addresses > only... > > I even think it isn't very polite to keep asking the rest of the world > to put BGP connected gateways in their area rather than to understand > how many other hosts are really connected to net44 (it is *not* only > some popular AMPR configuration scripts as my example above is showing). > BGP connected gateways are very new in the AMPRNet world and the first > thing I would be interested in if I start with BGP direct connected > networks is "full connectivity" to all hosts on net44. Rather than to > insist in support of IPIP-gateway addresses with net44-addresses I'm > pretty sure there would be a solution to get a *single* commercial > IP-address from the ISP for that purpose. > > I'm really open for respectful discussions and I'm also willing to move > net44 forward (e.g. I support to have net44 IPIP gateways and did test > the functionality at DB0FHN). We recently started to define ranges for > BGP direct connected networks in our IP-address space and already have > the permission to announce one network (two more to come). So we are > constantly moving forward. > > What I'm missing on the net44 discussion list and especially on the > #HamWAN Freenode IRC-channel is fair and respectful treatment of others. > > 73, > Jann > DG8NGN > Ps: I'm going to install the 44.24.240.0/20 route again on Friday since > I have a very important meeting at the european comission in Brussels > regarding the 23-cm-band (Galileo).

1 0

Internet Maintenance Notification
by Tim Osburn 16 Jun '14

16 Jun '14

FYI: I will be moving HamWAN off of the Cisco 7206 and over to the Cisco ASR 9k routers today so it's possible you may see a blip in the internet access if any at all. Tim Osburn www.osburn.com 206.812.6214 W7RSZ

5 6

Network Planning Mtg Sat 9am for New OR/SW Wash Group
by Kenneth Tolliver 16 Jun '14

16 Jun '14

Attached is the flyer for this Saturday's High Speed Digital Ham Network planning meeting. It's from 9am to Noon at the Tigard North Dakota LDS Meetinghouse. 11065 SW North Dakota, Tigard OR 97223. All hams are invited to help us design/plan a new High Speed Digital Network for Hams. We hope it will eventually connect with the Puget Sound HamWAN project in the Seattle Area and run down to at least Albany, Oregon. Hopefully, it will also go east to Hermiston, Oregon; giving coverage along the Columbia Gorge. We will start planning for coverage of the Portland/Vancouver Area. It will use commercial/consumer Microwave equipment on 2.4 GHz, 3.6GHz, and 5.8 GHz. It will be a very fast network. We will need good Node Sites, IP Network Design, and lots of hands on-- try it out stuff. If you are interested in being part of the project in Oregon & SW Washington come to the meeting. You don't have to be a RF Engineer or a Network Nerd; but it sure would help us if you were. There are jobs for every skill level. We need your help. This is not part of HamWAN or NW-MESH. I just thought those groups would have some pepole interested in helping our project. Come help us bring Amateur Radio into the High Speed Digital Era. Nothing is written in stone. Your input is needed. Hope to see you there. 73 Ken Tolliver K7ICY 503-544-7945 Flyer Attached.

1 0

5SHPn v6.15 firmware upgrade
by Dean Gibson AE7Q 13 Jun '14

13 Jun '14

Part of the change log below. What's new in 6.15 (2014-Jun-12 12:25): *) ... What's new in 6.14 (2014-Jun-06 15:34): *) ... *)*ssh server - allow none cipher;* *) ...

2 1

Loss of 44.x.x.x connections
by Dean Gibson AE7Q 12 Jun '14

12 Jun '14

OK, someone's apparently been messing with the HamWAN routing table again ... traceroute to 44.225.56.72 (44.225.56.72), 30 hops max, 38 byte packets 1 5shpn-1_dmz (192.168.44.254) 0.436 ms 0.259 ms 0.253 ms 2 dhcp-44-24-240-161.paine-s2.hamwan.net (44.24.240.161) 54.989 ms 50.222 ms 4.484 ms 3 ptp2-shoreline.paine.hamwan.net (44.24.240.135) 4.955 ms 4.338 ms 4.001 ms 4 w0.paine.k7nvh.hamwan.net (44.24.242.11) 62.214 ms 21.459 ms 51.757 ms 5 ipip1.seattle-er1.hamwan.net (44.24.242.16) 877.546 ms 360.904 ms 113.455 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * *

3 3

Bellevue Site Survey?
by John D. Hays 12 Jun '14

12 Jun '14

K7LWH (Lake Washington Ham Club) has a repeater site atop Lincoln tower in Bellevue. At last night's board meeting the topic came up of hooking the site to HamWan (as a client). Looking at the coverage map, it looks like the ground level near the building is marginal, but the antenna would be atop a 450' tall building. Is there anyone who would be willing to do a site survey with antenna and radio to evaluate if this would be a reliable site? The club will buy and install equipment once the site is surveyed and they obtain permission (very likely). This link would be to support D-STAR (including a RP2D node) and echolink in the repeater rack. ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays>

3 2

DNS mapping
by Dean Gibson AE7Q 09 Jun '14

09 Jun '14

I did: =>dig -x 44.24.240.173 @a.ns.hamwan.net. ; <<>> DiG 9.2.4 <<>> -x 44.24.240.173 @a.ns.hamwan.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55622 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;173.240.24.44.in-addr.arpa. IN PTR ;; ANSWER SECTION: *173.240.24.44.in-addr.arpa. 3600 IN PTR ae7q.hamwan.net.* ;; Query time: 147 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Thu May 15 20:44:05 2014 ;; MSG SIZE rcvd: 73 =>dig ae7q.hamwan.net. @a.ns.hamwan.net. ; <<>> DiG 9.2.4 <<>> ae7q.hamwan.net. @a.ns.hamwan.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46180 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ae7q.hamwan.net. IN A ;; AUTHORITY SECTION: *ae7q.hamwan.net. 3600 IN NS ns1.ae7q.ampr.org.* ;; Query time: 101 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Thu May 15 20:45:39 2014 ;; MSG SIZE rcvd: 64 =>dig ns1.ae7q.ampr.org. @ampr.org. ; <<>> DiG 9.2.4 <<>> ns1.ae7q.ampr.org. @ampr.org. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27978 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 1 ;; QUESTION SECTION: ;ns1.ae7q.ampr.org. IN A ;; ANSWER SECTION: *ns1.ae7q.ampr.org. 3600 IN A 44.24.240.173* ;; AUTHORITY SECTION: ampr.org. 3600 IN NS ampr-dns.in-berlin.de. ampr.org. 3600 IN NS ampr.org. ampr.org. 3600 IN NS munnari.OZ.AU. ampr.org. 3600 IN NS ns1.defaultroute.net. ampr.org. 3600 IN NS ns2.threshinc.com. ampr.org. 3600 IN NS ns0.comgw.net. ampr.org. 3600 IN NS hamradio.ucsd.edu. ;; ADDITIONAL SECTION: ampr.org. 3600 IN A 44.0.0.1 ;; Query time: 157 msec ;; SERVER: 44.0.0.1#53(44.0.0.1) ;; WHEN: Thu May 15 20:47:46 2014 ;; MSG SIZE rcvd: 263 Now, this is not correct. While I appreciate the PTR record for 44.24.240.173, it needs to point to a *hostname* record ("A" or CNAME"), not a *domainname* record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net effectively declares ae7q.hamwan.net as a *subdomain*, with ns1.ae7q.ampr.org as its*nameserver*. Now, ns1.ae7q.ampr.org has the IP address of 44.24.240.173, but that doesn't mean that the domain ae7q.hamwan.net is anywhere near 44.24.240.x. The correct solution to this problem is to replace the NS record for ae7q.hamwan.net with a reference to a host; eg: 1. ae7q.hamwan.net. 3600 IN A 44.24.240.173 2. ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.ampr.org. The administrative advantage of the CNAME is that if my IP address changes, you don''t have to change the forward record (you'll still have to update PTR records). The administrative disadvantage is that the CNAME is dependent upon a different administrative organization. However, neither solution above allows for ae7q.hamwan.net to be a subdomain. If you want to allow ae7q.hamwan.net to be a subdomain, you need to lay the following foundation: 173.240.24.44.in-addr.arpa. 3600 IN PTR ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) ae7q.hamwan.net. 3600 IN NS ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) ns1.ae7q.hamwan.net. 3600 IN A 44.24.240.173 ; (if ns1.ae7q.ampr.org. is not used) That by itself will not allow *me* to add subdomain records, but it lays the foundation. I prefer creating ns1.ae7q.hamwan.net (all three records above), as it keeps the records independent of a different administrative organization. If you want to get carried away, you could also add the following record: www.ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) -- Dean

4 19