[HamWAN PSDR] Baldi deployment report

[Dylan Ambauen]

Kenny, I have not yet determined the Pi's new address. I assume r1.baldi is
the dhcp server for the new LAN, but I don't seem to have access to
r1.baldi. No problem.

Instead, moved the Pi's switch port to bridge=Building2, and configured a
DHCP server for the segment, waiting for the Pi to pull a new ip address.

Also realizing that Bart named the DMR router's new loopback as r2.baldi,
very clean, thank you Bart.

---
Dylan Ambauen
360-850-1200


On Sun, Jun 7, 2020 at 11:40 AM Kenny Richards <richark at gmail.com> wrote:

> Dylan,
>
> Were you able to access the Pi for programming the radios?
>
> Thanks
> Kenny
>
> On Sun, Jun 7, 2020 at 10:04 AM Dylan Ambauen <dylan at ambauen.com> wrote:
>
>> Sounds like a long day Bart. The local LAN has been a dream up there for
>> years.
>>
>> You put the DMR router on the routing protocol now too, great.
>> And the old SXT5 link to Baldi sector is gone:
>> wlan1.baldi.af7pr-baldi.hamwan.net (44.24.240.219)
>> ether1.baldi.af7pr-baldi.hamwan.net (44.25.137.34)
>>
>> Mike, Rob, Rod, the local DHCP server for 44.25.137.33/28 was on the
>> link radio.
>> Additionally, the switch ports are now bridged to the local LAN. Devices
>> should be up, but will have new ip addresses on the Baldi LAN, instead of
>> in 44.25.137.22/38
>> Bart says the VHF repeater didnt pull a DHCP address from Baldi LAN, it
>> was being used as a master for a while, so it's config required a static ip
>> address. I put theVHR repeaters switch port8 into the bridge for .33/28,
>> now called Building2.
>> And vhf.af7pr-baldi.hamwan.net is now back online.
>> There is very little necessity in maintaining 44.25.137.33/28 address
>> space anymore, there is plenty of space on baldi LAN. Perhaps there are
>> some reasons I'm not anticipating?
>> We can still use that block, moving the old devices back to how they were
>> numbered. Otherwise, we can find the new addresses and update DNS.
>>
>> ---
>> Dylan Ambauen
>> 360-850-1200
>>
>>
>> On Sat, Jun 6, 2020 at 11:59 PM Bart Kus <me at bartk.us> wrote:
>>
>>> Hello,
>>>
>>> We deployed stuff @ Baldi today.  First, the good news:
>>>
>>> 1) We installed the cable between the buildings, and got all of them on
>>> the gigabit LAN.
>>> 2) The 24-port switch for the middle building didn't arrive on time, so
>>> we're using the full switch that was there already.
>>> 3) We aligned the Beacon.Baldi dish and managed to get another 10dB of
>>> signal out of it now that it's focused solely on Beacon.
>>> 4) We got access points deployed into all the buildings.
>>> 5) We got the link to CampMurray working at last.  The 3ft dish was
>>> discovered to be damaged and had to be replaced with a 2ft from my
>>> personal inventory.  This will need an RF Armor shield, and an
>>> additional expense report for the Baldi deploy budget to cover the cost
>>> of the dish itself.
>>>
>>> Now for not great news:
>>>
>>> 1) The Ethernet link between the northernmost building and the new
>>> Rattlesnake.Baldi dish seems to be faulty.  It was raining hard when we
>>> were installing this, so maybe there's water in the connector. It's also
>>> deployed pretty close to lots of VHF/UHF antennas, so maybe the RFI is
>>> killing the Ethernet.  We need to go back on a dry day, hopefully with a
>>> cable analyzer, and examine the situation.  If it's VHF/UHF RFI, then
>>> we'll need to run fiber to the modem.  I have disabled the power to the
>>> dish for now, on the theory that water is causing PoE arcing at the
>>> modem contacts and we don't want that electrolysis process to continue.
>>> Power draw to the modem is not unusual, about 3.2W, although it has been
>>> observed to be quite variable at times, from 3W to 4W.
>>>
>>> 2) The AP in the northernmost building appears to have really bad
>>> performance.  I had a hard time pinging it over WiFi from within the
>>> shack.  Had to resort to using wired Ethernet to get any packets moving
>>> and work done.  I've no idea the cause of this.  Perhaps a spectrum scan
>>> is required.
>>>
>>> 3) The VHF DMR up there appears to have been static-IP configured and
>>> didn't migrate properly.  We'll need some follow-up remote work to
>>> re-program the repeater for DHCP.
>>>
>>> I think that's everything noteworthy.
>>>
>>> --Bart
>>>
>>> _______________________________________________
>>> PSDR mailing list
>>> PSDR at hamwan.org
>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org
>> http://mail.hamwan.net/mailman/listinfo/psdr
>>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20200607/f36e4b92/attachment.html>