May 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

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

1.2GHz to Paine [was: 44.x.x.x HamWAN network at Paine]
by Dean Gibson AE7Q 30 May '14

30 May '14

Scott Honaker and I have moved forward on this project: 1. We have installed a gateway (Linksys BEFSR41) between the ID-1 and the internal ARES/RACES subnet (not 44.x.x.x) of the DEM. 2. We have installed a Digi "AnywhereUSB" box to give us remote access to the ID-1's USB port, and thus remote control of the ID-1 radio. This not only allows multiple use of the ID-1 (which has useful 1.2GHz FM and digital voice modes as well as Ethernet data), but provides for remote frequency agility and a diagnostic capability. This works beautifully (eg, to search for and use a low-noise frequency)! Unfortunately, what does not work very well, is the RF portion of the connection. PINGs failed at a rate of over 99% when using the 1.2GHz antenna at the 70 ft level on the tower, so we swapped the antenna with the one used for the Icom 1.2GHz repeater (which wasn't seeing any action anyway) at 100 ft. That made a "dramatic" improvement, as PINGs now only fail at a 98% rate (depends upon the time of day, etc)! Antenna comparison between 1.2GHz and 5.9 GHz for the two sites: 1. On 1.2GHz, both antennas are omni-directional. 2. At the DEM, the 1.2GHz antenna is now at the 100' level, whereas the 5.9GHz antenna is at 150'. 3. At my home, the 1.2GHz antenna is about 10' above the 5.9GHz antenna, and it's on the same line-of-sight path. Note that voice communication between the two sites using the two ID-1 radios, is fine (there is a slight bit of noise on FM). The big difference, in my opinion? I'll bet that the wireless protocol used by the MikroTik radios includes an aggressive error correction and retry protocol, whereas the ID-1 is like a piece of Ethernet cable, and thus relies on the standard TCP/IP retry mechanism. The TCP/IP protocols, while "unreliable" in the technical sense of the term, require a higher overall reliability than a typical raw wireless connection. What this says (and I'm a bit surprised to note this), is that sites considering using ID-1 radios for data communications, may find that even with the tighter siting requirements of 5.9GHz, that the latter may be more successful (whether or not part of HamWAN). In addition to being a lower-cost radio with a much higher data rate, the MikroTik radios offer a built-in router, which can obviate the need for a separate router. -- Dean ps: The callsign and digital code filtering features of D-Star that we previously discussed, are not available (greyed out in the software) for digital *data* mode. Huh? Another fine example of software of the "seven last words" of poor program design: "Why would you want to do that?"

4 17

SeaPac 2014
by Dean Gibson AE7Q 24 May '14

24 May '14

Is HamWAN exhibiting @ SeaPac this year? Before you answer, note the following: 1. I had been thinking of attending/exhibiting, but since other factors have delayed my getting a dual 5SHPn/small antenna setup, the end result was that I have no current plans to attend. However, if HamWAN was exhibiting (or wanted to exhibit), I would go (at my own cost) if you wanted someone to man the table. 2. It's not too late (two weeks away) to decide. Last year I decided to exhibit *the weekend before* SeaPac, and got a table kitty-corner across from Icom. I had a "club" (non-profit) table for $50, which gave me a place to sit for the whole weekend and talk to interesting people. Last year, I demoed two Icom D-Star radios sending data to each other (@ 1200 bps!) and each "connected" (via WiFi) to two Android tablets running Telnet; this year, I wanted to demo something with a bit more speed ... 3. I would prefer to not sit at a table and hand out flyers, but actually have working equipment with a working demo. It doesn't have to not be a dumb demo; people just want to see something that actually works. -- Dean

1 0

KU7M and his dBm
by Dean Gibson AE7Q 24 May '14

24 May '14

First of all, Kenny: welcome! Now that you have a HamWAN connection, I hope you are no longer mad at me. Where is your antenna (inside/outside, height above ground, etc)? On a related but more serious side, do you have a direct line-of-sight path to Capitol Hill, or do you go through trees? The reason I ask is, my path goes through some trees. When it is windy, that causes my RX signal level (dBm value) to vary about 5 dB (mostly down). I have wondered whether mounting my antenna higher would help my overall value (of course it would help when it is windy). My average RX signal level is 80 dBm (no winds), and yours appears to be 83 dBm. However, you are twice as far from your cell site as I am from mine, and since power falls off as the square of the distance, I'd expect (in similar configurations and siting) that you would experience a 6 dB difference. Since the difference is only 3 dB, that suggests that (all things being equal, which they never are) I might gain *at most* 3 dB by moving the antenna.

4 9

5SHPn v6.13 firmware upgrade
by Dean Gibson AE7Q 21 May '14

21 May '14

Change log below. While a "#" comment can't be placed directly at the end of a command, a semicolon does end a command, so a comment at the end of a line, preceded by a ";" works! Unlike my previous upgrade from v6.10 to v6.12, which reduced my dBm levels by 5 dB (even after a firmware downgrade) until I reset the configuration, this upgrade has made no difference in the dBm levels. What's new in 6.13 (2014-May-15 16:03): *) console - comments are now accepted where new command can start, that is, where '/' or ':' characters can be used to start new command, e.g. /interface { # comment until the end of the line print } *) backup - backups by default are encrypted now (with user password). To use backup on older versions, you should disable encryption with dont-encrypt flag when creating it; *) files with '.sensitive.' in the filename require 'sensitive' permission to manipulate; *) lcd - reduce CPU usage when displaying static screens; *) l2tp - fixed occasional server lockup; *) pptp - fixed memory leak; *) sstp - fixed crashes;

1 0

Proposal: Change HamWAN board meeting to once monthly
by Benjamin Krueger 15 May '14

15 May '14

Hi Folks, It seems pretty obvious that meeting once every week is too often for most folks. There often isn't enough to talk about, and it's a big time commit. I propose that we change the meeting schedule to once monthly on the first Tuesday, at the same 7pm pacific time. Please reply with your thoughts, and if there are no serious complications we can take a vote to implement this change. -- Benjamin

1 0

Re: [HamWAN PSDR] HamWAN use cases [was: hamwan.net DDNS]
by Dean Gibson AE7Q 14 May '14

14 May '14

On 2014-04-22 16:23, Dean Gibson AE7Q wrote: > > On 2014-04-22 16:06, Nigel Vander Houwen wrote: >> Hey Dean, >> >> Can you give me the output of >> >> /interface wireless registration-table print oid >> >> On your modem? Mikrotik decided to make the OIDs different based on >> what you're connected to, and this is easier than snmpwalking it. Actually, when you SNMP-walk it, it appears that the signal strength and TX/RX rates are duplicated. One place is specific to the connected MAC address (I thought that was weird until I thought about it a bit), and the other place has no relation to the connection. >> >> Thanks, Nigel > > Having worked very briefly w/ SNMP (and hating it), I understand > COMPLETELY (grin). OK, where's voltage and temperature ??? /system health print oid voltage: .1.3.6.1.4.1.14988.1.1.3.8.0 temperature: .1.3.6.1.4.1.14988.1.1.3.10.0 I can't find the message where someone recommended "The Dude", but I've installed it. The beta version (4.0b3) seems to be better in general than the current release version (3.6), although the graphing in the latter uses better scaling, in my opinion: One ought to be able to turn dynamic scaling (vertical axis) on and off, and in the latter case, specify the limits. Oh, well; it's gotten me to probing around in the SNMP map, and I have "Dude" charting voltage and temperature (the above OIDs give them in TENTHS). The latter is more interesting, because (duh) it goes up and down w/ the outside temperature. Maybe Bart or Tom can associate that with propagation (grin).

4 11

Signal processing challenge
by Bart Kus 10 May '14

10 May '14

Hello, Do you like software defined radios? Do you like digital communications? Me too! I took a Ubiquiti XR3 radio modem configured to operate in NV2 mode with 20MHz bandwidth centered at 3.65GHz, and mixed it with a 3.68GHz local oscillator. The resulting unfiltered mess got fed to my oscilloscope which digitized it into the attached file. The sampling rate was 250MSa/s and the capture length was 32768 samples. The data in the file represents a single NV2 beacon transmission, which lasts about 84us. The captured signal should be centered at 30MHz with a 20MHz bandwidth. Having looked at the signal in the frequency domain before digitizing it in the time domain, I can tell you there are some unwanted mixing products here along with the desired signal: Main Signal The above image shows a marker (X) on the main signal at ~30MHz. Product 1 The above image shows a marker (X) at one mixing product at ~1.68GHz. Product 2 The above image shows a marker (X) at another mixing product at ~2.0GHz. Can you extract the data from this beacon frame? The outermost encoding should be 20MHz 802.11a OFDM. --Bart

1 0

HamWAN over tideflats
by Tom Hayward 08 May '14

08 May '14

Last weekend I had the chance to play with my HamWAN portable setup (this is the Poynting dish, RouterBoard Metal 5SHPn, 11.1V battery, and tripod combo you see on http://hamwan.org/ homepage). I set up at the Camano Island survey location shown on the map. It's right at water level with a clear view toward Everett. When I first set up, I got a signal level of about -58 dBm. Wow! This is great for 21 miles at 5.9 GHz. As the tide went out, I saw the signal dip to around -76 dBm. This was over about 250 yards of mudflats. As the tide came back in, I saw the signal climb until the water reached the bulkhead (about 5 ft from antenna), and the signal level hit -54 dBm. The computer model predicts a path loss of 145 dB, which would put my signal level at -71 dBm. You can see from the numbers that the water improves the signal level. This was not predicted. What causes it? Kenny linked me to an interesting paper on the topic, although my observations differed from theirs: http://www.researchgate.net/publication/224138836_Slow_Frequency_Hopping_fo… I find the effect of tides on signal level very intriguing. This is the sort of effect that makes 5.9 GHz microwave interesting to me. Tom KD7LXL

7 11