April 2014 - PSDR - mailman.hamwan.org

44.x.x.x HamWAN network at Paine
by Dean Gibson AE7Q 01 May '14

01 May '14

I have an idea to provide additional radio network connectivity to the Snohomish County DEM at Paine on 23cm, that would require one or two fixed 44.x.x.x IP addresses at the DEM, and one at my house (separate from my MikroTik radio), that would be accessible via the present 44.24.240.x connection to Paine (and perhaps any other 44.24.240.0/20 address). Both involve the use of two (or more) Icom ID-1 radios in D-Star DD mode. Background: An Icom ID-1 in DD mode acts just like a piece of Ethernet cable (except that it is half-duplex and limited to a raw 128Kbps speed). No IP address is (or can be) assigned to the device. Any Ethernet packet reaching the ID-1's Ethernet port (whatever the content) is simply encapsulated and transmitted if the radio is in DD-mode. Similarly, any received data (properly encapsulated by another ID-1) is simply sent out the receiving radio's Ethernet port. The only radio configuration possible is to select a 23cm frequency and set the radio into DD-mode. Most of these actions can either be done by the radio's control head, or via a USB port "connected" to a Windows PC running Icom's control software for the ID-1. This prior sentence is important in the following discussion. As an aside, the transmission of an ID-1 can be addressed to and received by a D-Star DD-mode "repeater" module, routed via the D-Star network over the Internet to another such "repeater" module anywhere in the world, and retransmitted over the air to a receiving ID-1 radio. This mechanism, while perhaps interesting, is not the subject of this eMail. I only mention it so as to avoid confusion. In scenario #1 for the ID-1 that already is installed at the Snohomish County DEM: 1. The Ethernet port of the ID-1 is directly connected to a switch at the DEM that is on the 44.24.240.x network. In this mode, any packets received over-the-air by the ID-1 are injected into the local 44.24.240.x network, and are routed in exactly the same manner as from any other device hard-wired to the 44.24.240.x network at the DEM. Further, any Ethernet packets seen by the ID-1 (whether intended for radio transmission or not), would be transmitted by the ID-1. 2. Another ID-1, located (say) at my house would be connected to a router, which would act as though it were directly connected to the 44.24.240.x network at the DEM. I don't view the above scenario as a good idea. For one thing, the indiscriminate transmissions from the DEM of unrelated 44.x.x.x packets doesn't seem like a good idea. For another, there is no security. So, that brings me to scenario #2: 1. At the Snohomish County DEM, place a router (or bridge) between the ID-1 and the 44.24.240.x network. 2. In this scenario, the ID-1 located at my house would also be connected to a router that acts as though it were directly connected to the 44.24.240.x (or any other) network at the DEM. Now, here is the wrinkle (to both scenarios): The ID-1 at the DEM is currently in VERY LOW utilization, being (as so far as we know) only able to contact my ID-1 (in either digital data or voice mode), and the two 23cm D-Star K7LWH repeater modules (one voice, and presumably one data) in Bellevue. Also, the ID-1 also supports normal FM voice mode, and is easily able to hit with one watt (from both the DEM and my house) the KB7CNN 23cm FM repeater on East Tiger Mountain. So, it would be nice to use the DEM's ID-1 radio in different modes, as needed, and switch modes or frequencies REMOTELY as desired. The solution to this the use of a Digi "Anywhere/5" (or "/2") Ethernet-to-USB box (I have several). With the installation of Digi drivers on any Windows PC, these allow a PC anywhere in the world to connect over the Internet to a Digi box and have access to several remote USB devices (including any connected USB hubs). In particular, the USB control port of an ID-1. In fact, this is how I control my ID-1 at home: this allows me to control the ID-1 from any Windows PC. Hence the desire for a fixed 44.24.240.x IP address for the Digi box at the DEM, allowing REMOTE control and configuration of the ID-1 when the Internet is not available. While the Digi box can be connected to any network at the DEM, it seems most productive to connect it to the 44.24.240.x network there, allowing remote configuration and control of the ID-1 in an Internet outage (this can be disabled by unplugging the ID-1's USB port). Unfortunately, the Digi USB boxes are only usable from Windows systems (Digi's remote SERIAL (RS-232) port boxes are supported not only on Windows from 98 on, but on most variants of Linux ...). Yes, this provides a much slower connection to the DEM than the MikroTik radios, but doesn't have quite the strict line-of-sight issues that 5cm does, and thus permits some mobile access. To Scott Hokaker: I am willing to provide a Digi "Anywhere/5" box on permanent loan (or perhaps donation) to this project. I also have a couple of consumer-grade routers (Linksys BEFSR41, Netgear WGT624v2) that are similarly available, if they are suitable. Comments welcome! -- Dean

10 20

Firewall Changes for HamWAN
by Nigel Vander Houwen 25 Apr '14

25 Apr '14

Hello All! Tonight myself and the other admins have spent some time working on improving the firewall implemented at our edge routers to help improve security and compliance, and I installed them on both edges a short time ago. We are now at this point implementing a default block of traffic coming in from the internet at large, unless specifically exempted. What does this mean for you? 1. For most things, you should not notice this change at all. Anything you request from your hamwan connection should work fine as the response will be related to your connection. 2. If you want to be able to reach a service you have on your hamwan connection from the internet at large, please let myself or another admin know, and we can add that to the known exceptions. This is a temporary state until we can get a web interface for managing your HamWAN DNS and firewall rules. 3. If you do notice any problems, please reach out to us. The best is via the #hamwan channel on irc.freenode.net, but email will work as well. Thanks, Nigel K7NVH

3 2

Re: [HamWAN PSDR] HamWAN use cases [was: hamwan.net DDNS]
by Rod Ekholm 23 Apr '14

23 Apr '14

I really like to use Mikrotik's "The Dude" for the SNMP graphing and value history. It has a lot of value, though it may not do some of the really fancy things (ie: Google Earth API's) that other applications do. But for free, it's a powerful tool to use in conjunction with the Mikrotik appliances (and other vendors if you're willing to add the MIBs)! On 2014-04-22 13:15, Nigel Vander Houwen wrote: > Dean, > > ... > 4. Yes. I need to configure the monitoring server to actually poll SNMP, and then we can tell the maps to use the RRD data. Since you say you've enabled that, I'll configure that now. > > You are correct, since live data is based on the RRDs, if a client is disconnected, the latest RRD values will be 'U', and be presented to the javascript as nulls. I don't know that I'd replace that with the last good value, as that's no longer a true representation of the network, but I don't think I'd be opposed to having that data be potentially in the info box, though it would require some more work to set up. > > Nigel K7NVH You'd only show the last "old" value if you could show the date/time for it (and perhaps "thin" the connecting line). What would be really cool, is an app that captured (on a second-by second basis) and graphed (in the classical sense) the signal strength over time, either from your end or from the client's end. It would be especially helpful in setting up an antenna, rather than the bouncy values from "monitor" (I note that you can set the polling interval to a fraction of a second). Hmm, I wonder if Java (not JavaScript) has a decent API for SNMP (I presume that's the best way to capture the data). -- Rod Ekholm kc7aad(a)gmail.com

1 0

hostname on ampr.org?
by Dean Gibson AE7Q 22 Apr '14

22 Apr '14

Now that I have an IP address (albeit DHCP) on HamWAN, how do I assign an ampr.org DNS hostname to it, and (if feasible) a reverse IP DNS entry? Do I: 1. Contact someone here? 2. Contact John Hays (the owner of 44.24.0.0/16)? 3. Need a fixed IP address for these features? This is not urgent; I'm just curious what the plans are for hostnames on ampr.org (or even hamwan.org) Right now I DDNS-update my own DNS server to point "hamwan.ae7q.net" to my present DHCP address. However, that may or may not be accessible by some "44-only" network users. Eg, I may want/"need" a hostname served by someone's (authoritative) DNS server on the 44.x.x.x/8 network, which seems to suggest a hostname (or sub-domain) in the ampr.org domain. The pattern seems to be either a hostname of the form <callsign>.ampr.org, *OR *a delegation of a sub-domain with the same name. Either works for me, although if I also get one of John's UDRX-440 radios (I've had reservation for one, for the past year), I'd need another hostname anyway, so maybe a ampr.org sub-domain and a static IP (for its DNS server) is the way to go ... -- Dean AE7Q

12 50

Kitsap County Tests: East Bremerton, West Bremerton, Silverdale
by Daniel Ransom 19 Apr '14

19 Apr '14

I had good success thanks to Tom at KD7LXL. Thanks for your help, Tom on 147.30 WB7DOB/R! From East Bremerton (looking into downtown Seattle): -88 dB Haystack-S3/AE7SJ -79 dB N7FSP/Baldi-S3 -81 dB N7FSP/Baldi-S1 -81? db Mirrormont (didn't capture the data, but good signal) From West Bremerton on the ground at Kitsap County EOC (looking into trees): -79 dB Haystack-S3/AE7SJ I need to get above the vegetation. From West Bremerton on Lansing St. N (other side of the trees--looking at Bainbridge and Port Orchard): -77 dB Haystack-S3/AE7SJ -82 dB N7FSP/Baldi-S3 -85 dB N7FSP/Baldi-S1 no Mirrormont We will have good signals to Baldi and Haystack. From Silverdale (red spot on coverage prediction at Ridgetop Rd.) no signals (lots of vegetation to the east and south) I need to get above the vegetation. No Capitol Park. I will do Port Orchard Fire Station 8 (Kitsap County Alternate EOC, KD7WDJ) tomorrow. I will revisit Manchester and list the stations I received. 73 from Dan at K7MM

3 5

Outside the 2nd story window
by Dean Gibson AE7Q 18 Apr '14

18 Apr '14

Pending a permanent installation, I now have the antenna outside my 2nd story window (pictures pending), hanging from the 2nd story rain gutter (plumbing PVC piping/fittings make excellent mounting fixtures!). This has resulted in about a 6dB increase in signal strength. Questions (from "interface wireless monitor 0"): 1. "Signal-strength" (I take it this is receive signal strength?) typically runs -86dBm to -90dBm; "tx-signal-strength" typically runs about 5dB better, although I have seen them the same. With the same radio at both ends (the other end is the DEM at Paine), I would think they would usually be the same, except for possible reflections, which I would think would be "equal opportunity" in occasionally giving a better value to the receive value, but that never happens. 2. What is "current-distance"? It's showing as "10" or "11". I'm exactly 5 miles from the Paine DEM, so I would have thought that this might be the round-trip distance, except I would have thought that a physical distance would be reported in kilometers (the manufacturer being outside of the USA). Now I do not have to leave the window open ... -- Dean AE7Q

3 5

Re: [HamWAN PSDR] AMPRnet tunnel outage
by Dean Gibson AE7Q 11 Apr '14

11 Apr '14

Resent with my correct eMail address ... On 2014-04-10 18:56, Dean Gibson wrote: > > On 2014-04-10 18:27, Bart Kus wrote: >> .... >>> >>> />traceroute 44.24.240.173 >>> traceroute to 44.24.240.173 (44.24.240.173), 30 hops max, 38 byte >>> packets >>> 1 209.59.211.184 (209.59.211.184) 0.172 ms 0.075 ms 0.062 ms >>> ... >>> 17 44.24.242.19 (44.24.242.19) 95.778 ms 98.257 ms 95.279 ms >>> 18 44.24.242.10 (44.24.242.10) 142.098 ms 103.353 ms 148.017 ms >>> 19 44.24.240.132 (44.24.240.132) 137.942 ms 112.522 ms 113.787 ms >>> 20 * * * >>> 21 * * */ >>> >> >> Nope, that shouldn't be. The network correctly routed your packets >> to the right sector @ Paine, and then failed on the very last hop in >> communicating with your modem? Depending on where the trace was >> originating from and the state of your modem's routing table at the >> time, your modem may have had different ideas about how to reply. >> Or, you might have been disconnected at the time? >> >> Where are these following traces from? The modem? Was there a >> specific source IP used? > > The trace came from my computer on the Internet at 209.59.217.159, > with the exact command you see above. Are you sure that 44.24.240.132 > is the right sector? Everything I see comes from 44.24.240.161. Note > (not included above but in my previous message) that I can traceroute > to .132 OK, but attempting to go any further back in the inbound > traceroute list, seems to repeat a HamWAN IP address and then *stop*. > The modem was on, I was monitoring it with */interface wireless > monitor 0*, and the "last-ip" field never changed (as it usually does > on an attempted access). > > When I post my various messages, none of them are at all urgent, but I > like to post "anomalies" if they are of help in administration. I'm > just experimenting.

4 11

AMPRnet tunnel outage
by Bart Kus 10 Apr '14

10 Apr '14

Hello, We are presently without access to AMPRnet tunnels as some technical issues @ AMPRnet headquarters are being sorted out. This will likely last 24 hours. This downtime is being taken in support of the HamWAN IPIP Anycast initiative which will provide redundancy to our AMPRnet tunnels. We might be the first AMPR network in the world to provide such fault-tolerance, so these are exciting times despite the growing pains. Internet access remains available during this outage, and any AMPRnets which are BGP-announced are also available right now. Only IPIP-based AMPRnets are affected. --Bart

2 2

Connecting to 44.0.0.1 (or not)
by Dean Gibson AE7Q 09 Apr '14

09 Apr '14

Via my external host (directly on the Internet): />ping ampr.org// //PING ampr.org (44.0.0.1) 56(84) bytes of data.// //64 bytes from ampr.org (44.0.0.1): icmp_seq=0 ttl=45 time=93.5 ms/ Through the HamWAN radio: />ping ampr.org// //PING ampr.org (44.0.0.1) 56(84) bytes of data.// //From 44.24.240.135 icmp_seq=0 *Destination Host Unreachable*/ A routing loop???: />traceroute ampr.org// //traceroute to ampr.org (44.0.0.1), 30 hops max, 38 byte packets// // 1 5shpn-1_ext (192.168.3.251) 0.411 ms 0.237 ms 0.228 ms// // 2 44.24.240.161 (44.24.240.161) 127.458 ms 23.392 ms 74.152 ms// // 3 44.24.240.136 (44.24.240.136) 55.588 ms 28.191 ms 4.444 ms// // 4 44.24.242.7 (44.24.242.7) 131.127 ms 434.037 ms 1232.351 ms// // 5 44.24.242.16 (44.24.242.16) 74.558 ms 347.674 ms 517.633 ms// // 6 gi1-0-149-sea1.threshinc.com (209.189.196.65) 775.778 ms 380.374 ms 529.840 ms// // 7 ge0-1-thbr03.threshinc.net (209.189.201.195) 338.481 ms 264.768 ms 277.434 ms// // 8 tge2-2.fr3.sea2.llnw.net (206.81.80.99) 368.613 ms 253.695 ms 502.565 ms// // 9 tge2-2.fr3.sjc.llnw.net (69.28.171.145) 1324.350 ms 1615.159 ms 139.687 ms// //10 ve5.fr4.sjc.llnw.net (69.28.171.210) 165.213 ms 299.371 ms 167.546 ms// //11 paix-px1--limelight-10ge.cenic.net (198.32.251.193) 197.806 ms 3515.491 ms calren-cenic.paix.net (198.32.176.33) 204.395 ms// //12 dc-svl-px1--paix-px1-ge.cenic.net (137.164.47.173) 247.990 ms 358.917 ms *// //13 * * *// //14 * dc-lax-core2--svl-core1-10ge.cenic.net (137.164.47.24) 433.794 ms 227.051 ms// //15 dc-lax-core1--lax-core2-10ge-4.cenic.net (137.164.46.68) 289.399 ms 266.228 ms 303.996 ms// //16 dc-riv-core1--lax-core1-10ge-4.cenic.net (137.164.46.103) 287.258 ms 299.758 ms 301.851 ms// //17 dc-sdg-agg1--riv-core1-10ge-2.cenic.net (137.164.47.15) 572.338 ms 391.259 ms 148.496 ms// //18 dc-ucsd-1--sdg-agg1.cenic.net (137.164.23.54) 453.700 ms 149.203 ms 375.147 ms// //19 * * *// //20 * * *// //21 dc-sdg-agg1--riv-core1-10ge-2.cenic.net (137.164.47.15) 448.335 ms 385.200 ms 486.918 ms// //22 dc-ucsd-1--sdg-agg1.cenic.net (137.164.23.54) 204.232 ms * 249.699 ms// //23 * * *// //24 * * *// //25 * * *// //26 * * *// //27 * * *// //28 * * *// //29 * * *// //30 * * */ Probably not a HamWAN problem ... just commenting. -- Dean

4 4

RFO
by Tim Osburn 09 Apr '14

09 Apr '14

Per Tom's request :) http://www.osburn.com/140409-hamwan-outage-notification.pdf Tim Osburn www.osburn.com 206.812.6214 W7RSZ

1 0