[HamWAN PSDR] CapitolPark <-> QueenAnne link
randy at neals.ca
Fri Mar 30 01:50:28 PDT 2018
Bart, I appreciate the summary/detail, almost as much as I appreciate your
work fixing things!
Coordinating the work of maintaining a larger network like HamWAN is not
easy, but with notes like this, it provides a log-book function.
On Thu, Mar 29, 2018 at 11:17 PM, Bart Kus <me at bartk.us> wrote:
> After hours of debugging, I got this 20MHz single-polarity link moving up
> to 55Mbit. A high resolution spectrum analysis on both sides did indeed
> show a better frequency to use for the link. Spectrum analysis captures
> There was also an IP conflict between two modems @ Capitol Park. The
> conflicting IP has been removed from CapitolPark-S3.
> The QueenAnne modem used for the link is not one used anywhere else on the
> network. It's a very low-end modem, and as a result it was having CPU/RAM
> starvation issues when running our regular diagnostic tools, which lead to
> out-of-memory conditions and kernel crashes. A different test methodology
> had to be used to verify the link speed (testing through the modem, instead
> of to the modem).
> The modem that links QueenAnne with the Westin building (on the QueenAnne
> side) had a mis-configured OSPF router-id. This was fixed.
> I'm still seeing weird routing decisions being made by OSPF. These are
> triggered by our point-to-point route entries (18.104.22.168/24 space).
> More research needs to be done here, and perhaps a re-write of how we
> define point-to-point interface addresses. Any OSPF experts in the house?
> I also discovered R1.QueenAnne was still vulnerable to hacking due to a
> mis-configuration of its control software. It missed the updates that were
> sent out to the whole network. This has been fixed now. R1.QueenAnne also
> didn't have the diagnostic bandwidth-server setup correctly. This was
> With the CapitolPark-QueenAnne link performing well now:
> [eo at CapitolPark-QueenAnne] /system resource> /tool bandwidth-test
> 22.214.171.124 direction=both
> status: running
> duration: 57s
> tx-current: 28.0Mbps
> tx-10-second-average: 28.4Mbps
> tx-total-average: 27.5Mbps
> rx-current: 27.6Mbps
> rx-10-second-average: 28.0Mbps
> rx-total-average: 27.0Mbps
> lost-packets: 288
> random-data: no
> direction: both
> tx-size: 1500
> rx-size: 1500
> its OSPF config has been reset to a normal preference level, so that
> packets no longer try to avoid that link as they are routed through the
> network. This link can be sped up by upgrading to a dual-polarity modem @
> While testing if the OSPF hop cost was being calculated correctly in the
> Beacon-Haystack-QueenAnne RF link (they both connect to the same dish @
> Haystack), I discovered a mis-config on the Haystack.Beacon modem (bad LAN
> IP binding) which was preventing it from bringing up OSPF on its LAN
> interface. This was fixed and that modem should act like an actual router
> now, moving traffic.
> During the same Beacon testing, I was reminded that our Baldi-Beacon RF
> link sucks
> It was optimized for speed to Tukwila, which is now gone, so a trip needs
> to be scheduled to Baldi to rotate the dish a few degrees north and get
> that link going strong.
> I normally wouldn't send this kind of verbose email to psdr@, but I hope
> it's illuminating as to the type and extent of work required to keep this
> network running well.
> PSDR mailing list
> PSDR at hamwan.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PSDR