Re: [AFMUG] Packetflux & 450M Timing

[George Skorup]

So.. is "Cambium Sync" still a power interruption scheme or something 
completely new? I thought the thing they were going to move to was 1588v2?


On 11/15/2016 1:26 AM, Forrest Christian (List Account) wrote:


I guess I need to be more clear on this. ..

There are two types of sync over power.

The first is being called Canopy sync,  which is compatible  with the 
450i and earlier radios.


The second is being called Cambium sync and is compatible with the 
450M and I'm guessing later radios.


Currently there are devices that produce the cambium sync pulse...  
The CMM5 and I'm about 100% certain that Last Mile Gear has one as 
well.   I have the technical information I need,  just haven't had a 
chance to get the circuit designed (I only received it shortly before 
wispapalooza), let alone tested.



On Nov 14, 2016 7:52 PM, "Forrest Christian (List Account)" 
mailto:li...@packetflux.com>> wrote:


No,  Cambium elected  to drop the traditional sync over power on
the 450M.

So,  you either need to use timing port sync (via the aux port) or
use what they're calling cambium sync.

The 1U injector is very close.  I need to finish validation on the
latest board revisions and then will be releasing it to production
assuming there isn't some showstopper I missed.


On Nov 14, 2016 7:34 PM, "Matt" mailto:matt.mailingli...@gmail.com>> wrote:

Shouldn't the sync over power for the 450M be the same as PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
mailto:li...@packetflux.com>> wrote:
> All of the currently shipping syncbox product line are
compatible.  For sync
> over power, I have the specs, but the design isn't done yet.
>
>
> On Nov 14, 2016 5:40 PM, "Sam Lambie" mailto:samtaos...@gmail.com>> wrote:
>>
>> A question for Forrest mostly. Have you come up with a
timing product for
>> the 450m AP yet? If not, have you got a timeline for release?
>>
>> Sam
>>
>> --
>> --
>> Sam Lambie
>> Taosnet Wireless Tech.
>> 575-758-7598  Office
>> www.Taosnet.com 

Re: [AFMUG] Packetflux & 450M Timing

[Forrest Christian (List Account)]

I guess I need to be more clear on this. ..

There are two types of sync over power.

The first is being called Canopy sync,  which is compatible  with the 450i
and earlier radios.

The second is being called Cambium sync and is compatible with the 450M and
I'm guessing later radios.

Currently there are devices that produce the cambium sync pulse...  The
CMM5 and I'm about 100% certain that Last Mile Gear has one as well.   I
have the technical information I need,  just haven't had a chance to get
the circuit designed (I only received it shortly before wispapalooza), let
alone tested.

On Nov 14, 2016 7:52 PM, "Forrest Christian (List Account)" <
li...@packetflux.com> wrote:

> No,  Cambium elected  to drop the traditional sync over power on the 450M.
>
> So,  you either need to use timing port sync (via the aux port) or use
> what they're calling cambium sync.
>
> The 1U injector is very close.  I need to finish validation on the latest
> board revisions and then will be releasing it to production assuming there
> isn't some showstopper I missed.
>
> On Nov 14, 2016 7:34 PM, "Matt"  wrote:
>
>> Shouldn't the sync over power for the 450M be the same as PMP450i?
>>
>> How is the 1u sync injector coming?
>>
>>
>> On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
>>  wrote:
>> > All of the currently shipping syncbox product line are compatible.  For
>> sync
>> > over power, I have the specs, but the design isn't done yet.
>> >
>> >
>> > On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>> >>
>> >> A question for Forrest mostly. Have you come up with a timing product
>> for
>> >> the 450m AP yet? If not, have you got a timeline for release?
>> >>
>> >> Sam
>> >>
>> >> --
>> >> --
>> >> Sam Lambie
>> >> Taosnet Wireless Tech.
>> >> 575-758-7598 Office
>> >> www.Taosnet.com
>>
>

Re: [AFMUG] IPv4 auction alternatives?

[Mike Hammett]

If only Sony supported IPv6... 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Kurt Fankhauser"  
To: af@afmug.com 
Sent: Monday, November 14, 2016 7:36:53 PM 
Subject: Re: [AFMUG] IPv4 auction alternatives? 



IPv6 is a necessity in so many ways I can't wait to see it adopted widespread. 
There are so many limitations to IPv4 with NAT. The BIGGEST thing I see is the 
gamers with the PS4's and it gets very beneficial if you have multiple PS4's in 
the same house. Apparently when Sony designed the games for UPnP they never 
anticipated that there would be multiple PS4 consoles behind a single public 
IPv4 address and so I guess you can't have two consoles playing the exact same 
game because the consoles fight for the same exact port ranges and the NAT 
router doesn't know which console on the internal LAN to forward the traffic 
too. Its a common problem apparently that Sony has acknowledged and basically 
said there will be no fix. But IPV6 wouldn't have had this problem in the first 
place. 


http://community.us.playstation.com/t5/PlayStation-Network-Support/MULTIPLE-PLAYSTATION-4-s-ONE-NETWORK-NEEDS-FIXED-ASAP-Confirmed/td-p/44774137
 






On Sun, Nov 13, 2016 at 6:14 PM, Paul Stewart < p...@paulstewart.org > wrote: 



Yeah … that was an insane chunk of change - the MS purchase of Nortel blocks…. 


JJ and team at Comcast did a stand up job with IPv6 enablement, promotion of it 
etc… 







On Nov 13, 2016, at 5:47 PM, Mike Hammett < af...@ics-il.net > wrote: 


*nods* MS spent how much to get Nortel's blocks? 

Comcast is completely dual stacked... as they manage their modems through IPv6, 
not IPv4. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 






From: "Paul Stewart" < p...@paulstewart.org > 
To: af@afmug.com 
Sent: Sunday, November 13, 2016 4:45:33 PM 
Subject: Re: [AFMUG] IPv4 auction alternatives? 

Yup .. back in time the major ISP’s were saying “there’s no content on IPv6” … 
so the content guys responded and through IPv6 day and other initiatives 
answered back. That was several years ago and there has been some progress but 
still lots of small and large players who are slow to get moving … I feel this 
pain in $$job where only DSL is dual stack (and recently wireless) but cable 
modem for example is not ready and it’s going to be a while … 


The content guys care just as much about IPv6 - they consume massive amount of 
IPv4 address blocks, especially with even increasing SSL content ….. 







On Nov 13, 2016, at 5:35 PM, Mike Hammett < af...@ics-il.net > wrote: 


Many content providers that aren't on Amazon are already completely IPv6, with 
some dual-stacked elements. ;-) 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 






From: fiber...@mail.com 
To: af@afmug.com 
Sent: Sunday, November 13, 2016 4:28:57 PM 
Subject: Re: [AFMUG] IPv4 auction alternatives? 

Content providers like Netflix, Facebook, etc. don't really have any reason to 
go IPv6 only. Best they can do is start offering IPv6 access also, on top of 
IPv4. 

Many content providers don't care. The pain is felt purely on the ISP side. The 
best we can hope for is that enough ISPs deploy IPv6 (only), so that most 
content providers can't continue to totally ignore IPv6 in the long term. 

Not that IPv6 support is always sunshine and roses, as can be seen by Netflix 
blocking IPv6 tunnels. 

Jared 



Sent: Sunday, November 13, 2016 at 11:05 PM 
From: "Paul Stewart" < p...@paulstewart.org > 
To: af@afmug.com 
Subject: Re: [AFMUG] IPv4 auction alternatives? 

I’m thinking 5 years or less… what it’ll take to start pushing this heavily is 
for someone like Netflix, Facebook etc to go IPv6 only…. great theory that 
probably won’t happen unfortunately …. 


On Nov 13, 2016, at 10:54 AM, Chuck McCown < ch...@wbmfg.com [ 
mailto:ch...@wbmfg.com ]> wrote: 

That day will come, but I think it is 5 years in the future or more. 



From: Cassidy B. Larson 
Sent: Saturday, November 12, 2016 11:16 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] IPv4 auction alternatives? 

Wonder if I could offer an “IPv6-Only” type of account at a discounted rate. 
They'd get their Netflix, their Facebook and everything else that’s v6 
reachable. 
If they can’t get to a v4 only site/service, then they can be the vocal ones 
complaining to the site owners to get their act in gear. 



On Nov 12, 2016, at 10:47 PM, Sterling Jacobson < sterl...@avative.net > wrote: 


Except that you literally cannot ‘move to IPv6’ and have happy clients yet. 

From: Af [ mailto:af-boun...@afmug.com ] On Behalf Of Kurt Fankhauser 
Sent: Saturday, November 12, 2016 7:17 PM 
To: af@afmug.com 
Subject: Re: [AFMUG] IPv4 auction alternatives? 


Wow, didn't know that /24's were going for that high. I would move to IPv6 as 
fast as I can! 



On Fri, Nov 11, 20

Re: [AFMUG] Packetflux & 450M Timing

[That One Guy /sarcasm]

i should pay more attention, no sync over power? balls and dicks

On Mon, Nov 14, 2016 at 7:50 PM, Kurt Fankhauser 
wrote:

> I can't wait till someone puts two 450M's pointed in the same direction
> and basically they could potentially get 1Gbps over 40mhz of spectrum in a
> 90 degree view. Now times that by 4 since you might have customers on all
> sides of the tower and what are we looking at here? 4Gbps total capacity
> and only using 80mhz of spectrum on the complete tower (assuming 8 450M
> AP's)??? Then add 3.65ghz in the mix once the FCC opens up the other 100mhz
> and Cambium comes out with a 3.65 version. So another 4Gbps capacity for
> that band 8Gbps tower capacity Someone will do this, I'm sure of it.
>
> On Mon, Nov 14, 2016 at 1:57 PM, Bill Prince  wrote:
>
>> Put in context, the 450M will fit in where 3, 4, 5, or maybe even 6
>> standard 450 APs fit. So you should figure that as 70/3, or 70/4, or
>> whatever fits your situation.
>>
>>
>> bp
>> 
>>
>>
>> On 11/14/2016 10:50 AM, George Skorup wrote:
>>
>>> The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is
>>> around 1A max per port. What you could do for now is a GigE-POE-APC and the
>>> new aux port version SyncBox Junior.
>>>
>>> On 11/14/2016 12:34 PM, Matt wrote:
>>>
 Shouldn't the sync over power for the 450M be the same as PMP450i?

 How is the 1u sync injector coming?


 On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
  wrote:

> All of the currently shipping syncbox product line are compatible.
> For sync
> over power, I have the specs, but the design isn't done yet.
>
>
> On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>
>> A question for Forrest mostly. Have you come up with a timing product
>> for
>> the 450m AP yet? If not, have you got a timeline for release?
>>
>> Sam
>>
>> --
>> --
>> Sam Lambie
>> Taosnet Wireless Tech.
>> 575-758-7598 Office
>> www.Taosnet.com
>>
>
>>>
>>
>


-- 
If you only see yourself as part of the team but you don't see your team as
part of yourself you have already failed as part of the team.

Re: [AFMUG] Packetflux & 450M Timing

[Kurt Fankhauser]

I can't wait till someone puts two 450M's pointed in the same direction and
basically they could potentially get 1Gbps over 40mhz of spectrum in a 90
degree view. Now times that by 4 since you might have customers on all
sides of the tower and what are we looking at here? 4Gbps total capacity
and only using 80mhz of spectrum on the complete tower (assuming 8 450M
AP's)??? Then add 3.65ghz in the mix once the FCC opens up the other 100mhz
and Cambium comes out with a 3.65 version. So another 4Gbps capacity for
that band 8Gbps tower capacity Someone will do this, I'm sure of it.

On Mon, Nov 14, 2016 at 1:57 PM, Bill Prince  wrote:

> Put in context, the 450M will fit in where 3, 4, 5, or maybe even 6
> standard 450 APs fit. So you should figure that as 70/3, or 70/4, or
> whatever fits your situation.
>
>
> bp
> 
>
>
> On 11/14/2016 10:50 AM, George Skorup wrote:
>
>> The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is
>> around 1A max per port. What you could do for now is a GigE-POE-APC and the
>> new aux port version SyncBox Junior.
>>
>> On 11/14/2016 12:34 PM, Matt wrote:
>>
>>> Shouldn't the sync over power for the 450M be the same as PMP450i?
>>>
>>> How is the 1u sync injector coming?
>>>
>>>
>>> On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
>>>  wrote:
>>>
 All of the currently shipping syncbox product line are compatible.  For
 sync
 over power, I have the specs, but the design isn't done yet.


 On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:

> A question for Forrest mostly. Have you come up with a timing product
> for
> the 450m AP yet? If not, have you got a timeline for release?
>
> Sam
>
> --
> --
> Sam Lambie
> Taosnet Wireless Tech.
> 575-758-7598 Office
> www.Taosnet.com
>

>>
>

Re: [AFMUG] OT: Something beautiful happened on Election Night

[Jeremy]

Congrats!  Election night almost put my wife into labor too!!

On Mon, Nov 14, 2016 at 5:00 PM, Jaime Solorza 
wrote:

> In my family there are 6 girls named Isabella Popular name
>
> On Nov 14, 2016 2:57 PM, "Ben Royer"  wrote:
>
> Thanks you all, we are very blessed!
>
> Thank you,
> Ben Royer, Operations Manager
> Royell Communications, Inc.
> 217-965-3699 www.royell.net
>
> *From:* Jerry Head 
> *Sent:* Monday, November 14, 2016 12:33 PM
> *To:* af@afmug.com
> *Subject:* Re: [AFMUG] OT: Something beautiful happened on Election Night
>
> Congratulations!
>
>
> On 11/14/2016 12:17 PM, Ben Royer wrote:
>
> My love and I welcomed our newest family member into the world, our
> daughter Isabelle!
> �
> [image: Isabelle]
> �
> �
> Thank you,
> Ben Royer, Operations Manager
> Royell Communications, Inc.
> 217-965-3699 www.royell.net
>
>
>
>

Re: [AFMUG] IPv4 auction alternatives?

[Josh Reynolds]

VOIP.

VOIP hates NAT.

On Nov 14, 2016 7:36 PM, "Kurt Fankhauser"  wrote:

> IPv6 is a necessity in so many ways I can't wait to see it adopted
> widespread. There are so many limitations to IPv4 with NAT. The BIGGEST
> thing I see is the gamers with the PS4's and it gets very beneficial if you
> have multiple PS4's in the same house. Apparently when Sony designed the
> games for UPnP they never anticipated that there would be multiple PS4
> consoles behind a single public IPv4 address and so I guess you can't have
> two consoles playing the exact same game because the consoles fight for the
> same exact port ranges and the NAT router doesn't know which console on the
> internal LAN to forward the traffic too. Its a common problem apparently
> that Sony has acknowledged and basically said there will be no fix. But
> IPV6 wouldn't have had this problem in the first place.
>
> http://community.us.playstation.com/t5/PlayStation-Network-Support/
> MULTIPLE-PLAYSTATION-4-s-ONE-NETWORK-NEEDS-FIXED-ASAP-
> Confirmed/td-p/44774137
>
>
>
> On Sun, Nov 13, 2016 at 6:14 PM, Paul Stewart 
> wrote:
>
>> Yeah … that was an insane chunk of change - the MS purchase of Nortel
>> blocks….
>>
>> JJ and team at Comcast did a stand up job with IPv6 enablement, promotion
>> of it etc…
>>
>> On Nov 13, 2016, at 5:47 PM, Mike Hammett  wrote:
>>
>> *nods* MS spent how much to get Nortel's blocks?
>>
>> Comcast is completely dual stacked...  as they manage their modems
>> through IPv6, not IPv4.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>>
>>
>> 
>> --
>> *From: *"Paul Stewart" 
>> *To: *af@afmug.com
>> *Sent: *Sunday, November 13, 2016 4:45:33 PM
>> *Subject: *Re: [AFMUG] IPv4 auction alternatives?
>>
>> Yup .. back in time the major ISP’s were saying “there’s no content on
>> IPv6” … so the content guys responded and through IPv6 day and other
>> initiatives answered back.  That was several years ago and there has been
>> some progress but still lots of small and large players who are slow to get
>> moving …   I feel this pain in $$job where only DSL is dual stack (and
>> recently wireless) but cable modem for example is not ready and it’s going
>> to be a while …
>>
>> The content guys care just as much about IPv6 - they consume massive
>> amount of IPv4 address blocks, especially with even increasing SSL content
>> …..
>>
>>
>> On Nov 13, 2016, at 5:35 PM, Mike Hammett  wrote:
>>
>> Many content providers that aren't on Amazon are already completely IPv6,
>> with some dual-stacked elements.  ;-)
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>>
>>
>> 
>> --
>> *From: *fiber...@mail.com
>> *To: *af@afmug.com
>> *Sent: *Sunday, November 13, 2016 4:28:57 PM
>> *Subject: *Re: [AFMUG] IPv4 auction alternatives?
>>
>> Content providers like Netflix, Facebook, etc. don't really have any
>> reason to go IPv6 only. Best they can do is start offering IPv6 access
>> also, on top of IPv4.
>>
>> Many content providers don't care. The pain is felt purely on the ISP
>> side. The best we can hope for is that enough ISPs deploy IPv6 (only), so
>> that most content providers can't continue to totally ignore IPv6 in the
>> long term.
>>
>> Not that IPv6 support is always sunshine and roses, as can be seen by
>> Netflix blocking IPv6 tunnels.
>>
>> Jared
>>
>>
>>
>> Sent: Sunday, November 13, 2016 at 11:05 PM
>> From: "Paul Stewart" 
>> To: af@afmug.com
>> Subject: Re: [AFMUG] IPv4 auction alternatives?
>>
>> I’m thinking 5 years or less… what it’ll take to start pushing this
>> heavily is for someone like Netflix, Facebook etc to go IPv6 only…. great
>> theory that probably won’t happen unfortunately ….
>>
>>
>> On Nov 13, 2016, at 10:54 AM, Chuck McCown mailto:chuck@
>> wbmfg.com ]> wrote:
>>
>> That

Re: [AFMUG] IPv4 auction alternatives?

[Kurt Fankhauser]

IPv6 is a necessity in so many ways I can't wait to see it adopted
widespread. There are so many limitations to IPv4 with NAT. The BIGGEST
thing I see is the gamers with the PS4's and it gets very beneficial if you
have multiple PS4's in the same house. Apparently when Sony designed the
games for UPnP they never anticipated that there would be multiple PS4
consoles behind a single public IPv4 address and so I guess you can't have
two consoles playing the exact same game because the consoles fight for the
same exact port ranges and the NAT router doesn't know which console on the
internal LAN to forward the traffic too. Its a common problem apparently
that Sony has acknowledged and basically said there will be no fix. But
IPV6 wouldn't have had this problem in the first place.

http://community.us.playstation.com/t5/PlayStation-Network-Support/MULTIPLE-PLAYSTATION-4-s-ONE-NETWORK-NEEDS-FIXED-ASAP-Confirmed/td-p/44774137



On Sun, Nov 13, 2016 at 6:14 PM, Paul Stewart  wrote:

> Yeah … that was an insane chunk of change - the MS purchase of Nortel
> blocks….
>
> JJ and team at Comcast did a stand up job with IPv6 enablement, promotion
> of it etc…
>
> On Nov 13, 2016, at 5:47 PM, Mike Hammett  wrote:
>
> *nods* MS spent how much to get Nortel's blocks?
>
> Comcast is completely dual stacked...  as they manage their modems through
> IPv6, not IPv4.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
>
>
> 
> --
> *From: *"Paul Stewart" 
> *To: *af@afmug.com
> *Sent: *Sunday, November 13, 2016 4:45:33 PM
> *Subject: *Re: [AFMUG] IPv4 auction alternatives?
>
> Yup .. back in time the major ISP’s were saying “there’s no content on
> IPv6” … so the content guys responded and through IPv6 day and other
> initiatives answered back.  That was several years ago and there has been
> some progress but still lots of small and large players who are slow to get
> moving …   I feel this pain in $$job where only DSL is dual stack (and
> recently wireless) but cable modem for example is not ready and it’s going
> to be a while …
>
> The content guys care just as much about IPv6 - they consume massive
> amount of IPv4 address blocks, especially with even increasing SSL content
> …..
>
>
> On Nov 13, 2016, at 5:35 PM, Mike Hammett  wrote:
>
> Many content providers that aren't on Amazon are already completely IPv6,
> with some dual-stacked elements.  ;-)
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
>
>
> 
> --
> *From: *fiber...@mail.com
> *To: *af@afmug.com
> *Sent: *Sunday, November 13, 2016 4:28:57 PM
> *Subject: *Re: [AFMUG] IPv4 auction alternatives?
>
> Content providers like Netflix, Facebook, etc. don't really have any
> reason to go IPv6 only. Best they can do is start offering IPv6 access
> also, on top of IPv4.
>
> Many content providers don't care. The pain is felt purely on the ISP
> side. The best we can hope for is that enough ISPs deploy IPv6 (only), so
> that most content providers can't continue to totally ignore IPv6 in the
> long term.
>
> Not that IPv6 support is always sunshine and roses, as can be seen by
> Netflix blocking IPv6 tunnels.
>
> Jared
>
>
>
> Sent: Sunday, November 13, 2016 at 11:05 PM
> From: "Paul Stewart" 
> To: af@afmug.com
> Subject: Re: [AFMUG] IPv4 auction alternatives?
>
> I’m thinking 5 years or less… what it’ll take to start pushing this
> heavily is for someone like Netflix, Facebook etc to go IPv6 only…. great
> theory that probably won’t happen unfortunately ….
>
>
> On Nov 13, 2016, at 10:54 AM, Chuck McCown mailto:chuck@
> wbmfg.com ]> wrote:
>
> That day will come, but I  think it is 5 years in the future or more.
>
>
>
> From: Cassidy B. Larson
> Sent: Saturday, November 12, 2016 11:16 PM
> To: af@afmug.com
> Subject: Re: [AFMUG] IPv4 auction alternatives?
>
> Wonder i

Re: [AFMUG] OT: Something beautiful happened on Election Night

[That One Guy /sarcasm]

Good deal! That is a fine looking baby.

On Nov 14, 2016 6:00 PM, "Jaime Solorza"  wrote:

> In my family there are 6 girls named Isabella Popular name
>
> On Nov 14, 2016 2:57 PM, "Ben Royer"  wrote:
>
> Thanks you all, we are very blessed!
>
> Thank you,
> Ben Royer, Operations Manager
> Royell Communications, Inc.
> 217-965-3699 www.royell.net
>
> *From:* Jerry Head 
> *Sent:* Monday, November 14, 2016 12:33 PM
> *To:* af@afmug.com
> *Subject:* Re: [AFMUG] OT: Something beautiful happened on Election Night
>
> Congratulations!
>
>
> On 11/14/2016 12:17 PM, Ben Royer wrote:
>
> My love and I welcomed our newest family member into the world, our
> daughter Isabelle!
> �
> [image: Isabelle]
> �
> �
> Thank you,
> Ben Royer, Operations Manager
> Royell Communications, Inc.
> 217-965-3699 www.royell.net
>
>
>
>

Re: [AFMUG] Site monitor relay temp

[That One Guy /sarcasm]

Can I replace my home thermostat with a sitemonitor? That's all a standard
thermostat I'd isn't it, a relay?

On Nov 14, 2016 8:20 AM, "Forrest Christian (List Account)" <
li...@packetflux.com> wrote:

> There was a bug we fixed in relation to this.I need to look at my
> revision notes to determine when this took place,  and verify that the
> updated software made it to the Web page.
>
> Unfortunately my connectivity where I an for most of this week apparently
> blocks VPN access for me and as such I don't have access to this at this
> data point.
>
> On Nov 13, 2016 7:55 PM, "TJ Trout"  wrote:
>
>> I just updated a site monitor and now it won't turn the relay on with
>> temp, my "relay on above" is set to 450 and my current temp reading is 550
>> , I was able to manually turn the relay on is there something on the binary
>> page that needs to be set? Or is this function broken on the lastest
>> firmware?
>>
>

Re: [AFMUG] Packetflux & 450M Timing

[Bill Prince]

Let me be more clear.

The circuit that is pins 4,5 (+), and pins 7,8 (-) is one circuit. Total 
of .75 amps.


The circuit that is pins 1,2 (-), and pins 3,6 (+) is one circuit. Total 
of .75 amps.


That puts 375 milliamps on each pin and each wire. That's because the 
power/current that is going in on pins 7 & 8, has to return on pins 4 & 
5. You can't double that.


Possibly more than I would be comfortable with anyway.


bp


On 11/14/2016 12:18 PM, Chuck McCown wrote:
Half an amp per wire on one chart, 3.5 amps on another chart.  Heating 
and insulation temperature rating are going to be the limiting factors 
there.

Jacks I use have a 1.5 amp rating per pin.
So, I think you can get 12 amps total if the cable is short enough.
*From:* Bill Prince
*Sent:* Monday, November 14, 2016 1:11 PM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] Packetflux & 450M Timing

Each pair is one half of a power circuit. So there are 4 halves. There 
are two issues; how much current can each wire carry, and how much 
current can each connector pin can carry.


bp


On 11/14/2016 11:59 AM, Josh Luthman wrote:
There are four pairs.  AF5x and the H in 24vh or 48vh POE ports of 
Netonix do power over all four pairs.  Speaking with Ubnt support 
last week, AF5x should ideally do four pairs when possible.

48v (0.75*4a) = 144 watts
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Mon, Nov 14, 2016 at 2:44 PM, Bill Prince  wrote:

At 48 volts, and .75 amps per pair of power wires, that would be
36 watts + 36 watts, or 72 watts total?

Just noodling here.

bp


On 11/14/2016 11:38 AM, George Skorup wrote:

For the record,
http://store.packetflux.com/powerinjector-plus-sync-gigabit-version/

says: 1A per port maximum power.  (48 watts at 48 Volts)

So.. is the electronic over-current protection the 1A limit? Or
is this just outdated info? Pretty sure it's >1A because I've
"tested" it (cable leaking water into the GigE-APC, the port
didn't trip, and the card was hot as hell).

I was also unaware that Cambium won't be supporting
sync-over-power on the 450m. I imagine the ringing/bounce issue
killed that idea due to the high power consumption.

On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:


The current products should power the 450M just fine.  The
rating is 1A per pair per port, so at the 48V you're good up to
96W.

On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:

The 450m pulls 70 watts. The current
SyncInjector/PowerInjector+Sync is around 1A max per port.
What you could do for now is a GigE-POE-APC and the new aux
port version SyncBox Junior.


On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same
as PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian
(List Account)
 wrote:

All of the currently shipping syncbox product line
are compatible.  For sync
over power, I have the specs, but the design isn't
done yet.


On Nov 14, 2016 5:40 PM, "Sam Lambie"
 wrote:

A question for Forrest mostly. Have you come up
with a timing product for
the 450m AP yet? If not, have you got a
timeline for release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598  Office
www.Taosnet.com 

Re: [AFMUG] OT: Something beautiful happened on Election Night

[Jaime Solorza]

In my family there are 6 girls named Isabella Popular name

On Nov 14, 2016 2:57 PM, "Ben Royer"  wrote:

Thanks you all, we are very blessed!

Thank you,
Ben Royer, Operations Manager
Royell Communications, Inc.
217-965-3699 www.royell.net

*From:* Jerry Head 
*Sent:* Monday, November 14, 2016 12:33 PM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] OT: Something beautiful happened on Election Night

Congratulations!


On 11/14/2016 12:17 PM, Ben Royer wrote:

My love and I welcomed our newest family member into the world, our
daughter Isabelle!
�
[image: Isabelle]
�
�
Thank you,
Ben Royer, Operations Manager
Royell Communications, Inc.
217-965-3699 www.royell.net

Re: [AFMUG] CNS server - schedule upgrades ??

[Chuck McCown]

We had a huge one last week on Netflix.  12 hours long.  

From: Josh Luthman 
Sent: Monday, November 14, 2016 3:25 PM
To: af@afmug.com 
Subject: Re: [AFMUG] CNS server - schedule upgrades ??

Don't believe it could.  I remember being disappointed and surprised.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Nov 14, 2016 5:06 PM, "Paul McCall"  wrote:

  Can CNS server schedule firmware upgrades for a specific time?



  Paul



  Paul McCall, President

  PDMNet, Inc. / Florida Broadband, Inc.

  658 Old Dixie Highway

  Vero Beach, FL 32962

  772-564-6800  

  pa...@pdmnet.net

  www.pdmnet.com

  www.floridabroadband.com

Re: [AFMUG] CNS server - schedule upgrades ??

[Josh Luthman]

Don't believe it could.  I remember being disappointed and surprised.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Nov 14, 2016 5:06 PM, "Paul McCall"  wrote:

> Can CNS server schedule firmware upgrades for a specific time?
>
>
>
> Paul
>
>
>
> Paul McCall, President
>
> PDMNet, Inc. / Florida Broadband, Inc.
>
> 658 Old Dixie Highway
>
> Vero Beach, FL 32962
>
> 772-564-6800
>
> pa...@pdmnet.net
>
> www.pdmnet.com
>
> www.floridabroadband.com
>
>
>
>
>

[AFMUG] CNS server - schedule upgrades ??

[Paul McCall]

Can CNS server schedule firmware upgrades for a specific time?

Paul

Paul McCall, President
PDMNet, Inc. / Florida Broadband, Inc.
658 Old Dixie Highway
Vero Beach, FL 32962
772-564-6800
pa...@pdmnet.net
www.pdmnet.com
www.floridabroadband.com

Re: [AFMUG] OT: Something beautiful happened on Election Night

[Ben Royer]

Thanks you all, we are very blessed!

Thank you,
Ben Royer, Operations Manager
Royell Communications, Inc.
217-965-3699 www.royell.net

From: Jerry Head 
Sent: Monday, November 14, 2016 12:33 PM
To: af@afmug.com 
Subject: Re: [AFMUG] OT: Something beautiful happened on Election Night

Congratulations!

On 11/14/2016 12:17 PM, Ben Royer wrote:

  My love and I welcomed our newest family member into the world, our daughter 
Isabelle!
  �

  �
  �
  Thank you,
  Ben Royer, Operations Manager
  Royell Communications, Inc.
  217-965-3699 www.royell.net

Re: [AFMUG] Packetflux & 450M Timing

[Forrest Christian (List Account)]

Yes,  that is correct.

On Nov 14, 2016 8:44 PM, "Bill Prince"  wrote:

> At 48 volts, and .75 amps per pair of power wires, that would be 36 watts
> + 36 watts, or 72 watts total?
>
> Just noodling here.
>
>
> bp
> 
>
>
> On 11/14/2016 11:38 AM, George Skorup wrote:
>
> For the record, http://store.packetflux.com/powerinjector-plus-sync-
> gigabit-version/ says: 1A per port maximum power.  (48 watts at 48 Volts)
>
> So.. is the electronic over-current protection the 1A limit? Or is this
> just outdated info? Pretty sure it's >1A because I've "tested" it (cable
> leaking water into the GigE-APC, the port didn't trip, and the card was hot
> as hell).
>
> I was also unaware that Cambium won't be supporting sync-over-power on the
> 450m. I imagine the ringing/bounce issue killed that idea due to the high
> power consumption.
>
> On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:
>
> The current products should power the 450M just fine.  The rating is 1A
> per pair per port, so at the 48V you're good up to 96W.
>
> On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:
>
> The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is
> around 1A max per port. What you could do for now is a GigE-POE-APC and the
> new aux port version SyncBox Junior.
>
>
> On 11/14/2016 12:34 PM, Matt wrote:
>
>> Shouldn't the sync over power for the 450M be the same as PMP450i?
>>
>> How is the 1u sync injector coming?
>>
>>
>> On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
>>  wrote:
>>
>>> All of the currently shipping syncbox product line are compatible.  For
>>> sync
>>> over power, I have the specs, but the design isn't done yet.
>>>
>>>
>>> On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>>>
 A question for Forrest mostly. Have you come up with a timing product
 for
 the 450m AP yet? If not, have you got a timeline for release?

 Sam

 --
 --
 Sam Lambie
 Taosnet Wireless Tech.
 575-758-7598 Office
 www.Taosnet.com

>>>
>
>
>
>

Re: [AFMUG] Packetflux & 450M Timing

[Forrest Christian (List Account)]

I would more say... incomplete information...We need to add "per pair" to
that description.

The 450M does support sync over power, it just is different.

On Nov 14, 2016 8:38 PM, "George Skorup"  wrote:

> For the record, http://store.packetflux.com/powerinjector-plus-sync-
> gigabit-version/ says: 1A per port maximum power.  (48 watts at 48 Volts)
>
> So.. is the electronic over-current protection the 1A limit? Or is this
> just outdated info? Pretty sure it's >1A because I've "tested" it (cable
> leaking water into the GigE-APC, the port didn't trip, and the card was hot
> as hell).
>
> I was also unaware that Cambium won't be supporting sync-over-power on the
> 450m. I imagine the ringing/bounce issue killed that idea due to the high
> power consumption.
>
> On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:
>
> The current products should power the 450M just fine.  The rating is 1A
> per pair per port, so at the 48V you're good up to 96W.
>
> On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:
>
> The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is
> around 1A max per port. What you could do for now is a GigE-POE-APC and the
> new aux port version SyncBox Junior.
>
>
> On 11/14/2016 12:34 PM, Matt wrote:
>
>> Shouldn't the sync over power for the 450M be the same as PMP450i?
>>
>> How is the 1u sync injector coming?
>>
>>
>> On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
>>  wrote:
>>
>>> All of the currently shipping syncbox product line are compatible.  For
>>> sync
>>> over power, I have the specs, but the design isn't done yet.
>>>
>>>
>>> On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>>>
 A question for Forrest mostly. Have you come up with a timing product
 for
 the 450m AP yet? If not, have you got a timeline for release?

 Sam

 --
 --
 Sam Lambie
 Taosnet Wireless Tech.
 575-758-7598 Office
 www.Taosnet.com

>>>
>
>
>

Re: [AFMUG] Packetflux & 450M Timing

[Seth Mattinen]

On 11/14/16 12:44, George Skorup wrote:


In the case of Trango's crazy POE scheme, assuming worst case of about
80 watts, you have ~200ma on each conductor. Ignoring minute differences
anyway. But the return path (aka shield & drain) is carrying all 1.67A
of return current. Which is the least of my concerns with decent cable.



I wonder if they assumed the tower structure itself would be the return 
path since if you were using a traditional DC plant all grounds/returns 
would be bonded.


~Seth

Re: [AFMUG] Packetflux & 450M Timing

[George Skorup]

Yeah, when we talk 4-pair power, it's two pairs positive and two pairs 
negative. Each pair carrying 1A. So it is effectively 2A total on the 
port, or as Forrest said, 96W @ 48VDC. With a 2-pair power (one +, one 
-) radio, all you'd be able to get to it is 48 watts.


In the case of Trango's crazy POE scheme, assuming worst case of about 
80 watts, you have ~200ma on each conductor. Ignoring minute differences 
anyway. But the return path (aka shield & drain) is carrying all 1.67A 
of return current. Which is the least of my concerns with decent cable.


On 11/14/2016 2:11 PM, Bill Prince wrote:


Each pair is one half of a power circuit. So there are 4 halves. There 
are two issues; how much current can each wire carry, and how much 
current can each connector pin can carry.


bp


On 11/14/2016 11:59 AM, Josh Luthman wrote:
There are four pairs.  AF5x and the H in 24vh or 48vh POE ports of 
Netonix do power over all four pairs. Speaking with Ubnt support last 
week, AF5x should ideally do four pairs when possible.


48v (0.75*4a) = 144 watts


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Mon, Nov 14, 2016 at 2:44 PM, Bill Prince > wrote:


At 48 volts, and .75 amps per pair of power wires, that would be
36 watts + 36 watts, or 72 watts total?

Just noodling here.


bp


On 11/14/2016 11:38 AM, George Skorup wrote:

For the record,
http://store.packetflux.com/powerinjector-plus-sync-gigabit-version/

says: 1A per port maximum power.  (48 watts at 48 Volts)

So.. is the electronic over-current protection the 1A limit? Or
is this just outdated info? Pretty sure it's >1A because I've
"tested" it (cable leaking water into the GigE-APC, the port
didn't trip, and the card was hot as hell).

I was also unaware that Cambium won't be supporting
sync-over-power on the 450m. I imagine the ringing/bounce issue
killed that idea due to the high power consumption.

On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:


The current products should power the 450M just fine.  The
rating is 1A per pair per port, so at the 48V you're good up to
96W.


On Nov 14, 2016 7:50 PM, "George Skorup" mailto:geo...@cbcast.com>> wrote:

The 450m pulls 70 watts. The current
SyncInjector/PowerInjector+Sync is around 1A max per port.
What you could do for now is a GigE-POE-APC and the new aux
port version SyncBox Junior.


On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same
as PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian
(List Account)
mailto:li...@packetflux.com>> wrote:

All of the currently shipping syncbox product line
are compatible.  For sync
over power, I have the specs, but the design isn't
done yet.


On Nov 14, 2016 5:40 PM, "Sam Lambie"
mailto:samtaos...@gmail.com>> wrote:

A question for Forrest mostly. Have you come up
with a timing product for
the 450m AP yet? If not, have you got a
timeline for release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598  Office
www.Taosnet.com 

Re: [AFMUG] Packetflux & 450M Timing

[Chuck McCown]

Half an amp per wire on one chart, 3.5 amps on another chart.  Heating and 
insulation temperature rating are going to be the limiting factors there.  
Jacks I use have a 1.5 amp rating per pin.  

So, I think you can get 12 amps total if the cable is short enough.  

From: Bill Prince 
Sent: Monday, November 14, 2016 1:11 PM
To: af@afmug.com 
Subject: Re: [AFMUG] Packetflux & 450M Timing

Each pair is one half of a power circuit. So there are 4 halves. There are two 
issues; how much current can each wire carry, and how much current can each 
connector pin can carry. 


bp


On 11/14/2016 11:59 AM, Josh Luthman wrote:

  There are four pairs.  AF5x and the H in 24vh or 48vh POE ports of Netonix do 
power over all four pairs.  Speaking with Ubnt support last week, AF5x should 
ideally do four pairs when possible. 

  48v (0.75*4a) = 144 watts


  Josh Luthman
  Office: 937-552-2340
  Direct: 937-552-2343
  1100 Wayne St
  Suite 1337
  Troy, OH 45373

  On Mon, Nov 14, 2016 at 2:44 PM, Bill Prince  wrote:

At 48 volts, and .75 amps per pair of power wires, that would be 36 watts + 
36 watts, or 72 watts total?

Just noodling here.



bp


On 11/14/2016 11:38 AM, George Skorup wrote:

  For the record, 
http://store.packetflux.com/powerinjector-plus-sync-gigabit-version/ says: 1A 
per port maximum power.  (48 watts at 48 Volts)

  So.. is the electronic over-current protection the 1A limit? Or is this 
just outdated info? Pretty sure it's >1A because I've "tested" it (cable 
leaking water into the GigE-APC, the port didn't trip, and the card was hot as 
hell).

  I was also unaware that Cambium won't be supporting sync-over-power on 
the 450m. I imagine the ringing/bounce issue killed that idea due to the high 
power consumption.


  On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:

The current products should power the 450M just fine.  The rating is 1A 
per pair per port, so at the 48V you're good up to 96W. 


On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:

  The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync 
is around 1A max per port. What you could do for now is a GigE-POE-APC and the 
new aux port version SyncBox Junior. 


  On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same as PMP450i?

How is the 1u sync injector coming?



On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
 wrote:

  All of the currently shipping syncbox product line are 
compatible.  For sync
  over power, I have the specs, but the design isn't done yet.


  On Nov 14, 2016 5:40 PM, "Sam Lambie"  
wrote:

A question for Forrest mostly. Have you come up with a timing 
product for
the 450m AP yet? If not, have you got a timeline for release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598 Office
www.Taosnet.com

Re: [AFMUG] Packetflux & 450M Timing

[Bill Prince]

Each pair is one half of a power circuit. So there are 4 halves. There 
are two issues; how much current can each wire carry, and how much 
current can each connector pin can carry.


bp


On 11/14/2016 11:59 AM, Josh Luthman wrote:
There are four pairs.  AF5x and the H in 24vh or 48vh POE ports of 
Netonix do power over all four pairs. Speaking with Ubnt support last 
week, AF5x should ideally do four pairs when possible.


48v (0.75*4a) = 144 watts


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Mon, Nov 14, 2016 at 2:44 PM, Bill Prince > wrote:


At 48 volts, and .75 amps per pair of power wires, that would be
36 watts + 36 watts, or 72 watts total?

Just noodling here.


bp


On 11/14/2016 11:38 AM, George Skorup wrote:

For the record,
http://store.packetflux.com/powerinjector-plus-sync-gigabit-version/

says: 1A per port maximum power.  (48 watts at 48 Volts)

So.. is the electronic over-current protection the 1A limit? Or
is this just outdated info? Pretty sure it's >1A because I've
"tested" it (cable leaking water into the GigE-APC, the port
didn't trip, and the card was hot as hell).

I was also unaware that Cambium won't be supporting
sync-over-power on the 450m. I imagine the ringing/bounce issue
killed that idea due to the high power consumption.

On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:


The current products should power the 450M just fine.  The
rating is 1A per pair per port, so at the 48V you're good up to
96W.


On Nov 14, 2016 7:50 PM, "George Skorup" mailto:geo...@cbcast.com>> wrote:

The 450m pulls 70 watts. The current
SyncInjector/PowerInjector+Sync is around 1A max per port.
What you could do for now is a GigE-POE-APC and the new aux
port version SyncBox Junior.


On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same
as PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian
(List Account)
mailto:li...@packetflux.com>> wrote:

All of the currently shipping syncbox product line
are compatible.  For sync
over power, I have the specs, but the design isn't
done yet.


On Nov 14, 2016 5:40 PM, "Sam Lambie"
mailto:samtaos...@gmail.com>>
wrote:

A question for Forrest mostly. Have you come up
with a timing product for
the 450m AP yet? If not, have you got a timeline
for release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598  Office
www.Taosnet.com 

Re: [AFMUG] Packetflux & 450M Timing

[Josh Luthman]

There are four pairs.  AF5x and the H in 24vh or 48vh POE ports of Netonix
do power over all four pairs.  Speaking with Ubnt support last week, AF5x
should ideally do four pairs when possible.

48v (0.75*4a) = 144 watts


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Mon, Nov 14, 2016 at 2:44 PM, Bill Prince  wrote:

> At 48 volts, and .75 amps per pair of power wires, that would be 36 watts
> + 36 watts, or 72 watts total?
>
> Just noodling here.
>
>
> bp
> 
>
>
> On 11/14/2016 11:38 AM, George Skorup wrote:
>
> For the record, http://store.packetflux.com/powerinjector-plus-sync-
> gigabit-version/ says: 1A per port maximum power.  (48 watts at 48 Volts)
>
> So.. is the electronic over-current protection the 1A limit? Or is this
> just outdated info? Pretty sure it's >1A because I've "tested" it (cable
> leaking water into the GigE-APC, the port didn't trip, and the card was hot
> as hell).
>
> I was also unaware that Cambium won't be supporting sync-over-power on the
> 450m. I imagine the ringing/bounce issue killed that idea due to the high
> power consumption.
>
> On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:
>
> The current products should power the 450M just fine.  The rating is 1A
> per pair per port, so at the 48V you're good up to 96W.
>
> On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:
>
> The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is
> around 1A max per port. What you could do for now is a GigE-POE-APC and the
> new aux port version SyncBox Junior.
>
>
> On 11/14/2016 12:34 PM, Matt wrote:
>
>> Shouldn't the sync over power for the 450M be the same as PMP450i?
>>
>> How is the 1u sync injector coming?
>>
>>
>> On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
>>  wrote:
>>
>>> All of the currently shipping syncbox product line are compatible.  For
>>> sync
>>> over power, I have the specs, but the design isn't done yet.
>>>
>>>
>>> On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>>>
 A question for Forrest mostly. Have you come up with a timing product
 for
 the 450m AP yet? If not, have you got a timeline for release?

 Sam

 --
 --
 Sam Lambie
 Taosnet Wireless Tech.
 575-758-7598 Office
 www.Taosnet.com

>>>
>
>
>
>

Re: [AFMUG] Packetflux & 450M Timing

[Bill Prince]

At 48 volts, and .75 amps per pair of power wires, that would be 36 
watts + 36 watts, or 72 watts total?


Just noodling here.


bp


On 11/14/2016 11:38 AM, George Skorup wrote:
For the record, 
http://store.packetflux.com/powerinjector-plus-sync-gigabit-version/ 
says: 1A per port maximum power.  (48 watts at 48 Volts)


So.. is the electronic over-current protection the 1A limit? Or is 
this just outdated info? Pretty sure it's >1A because I've "tested" it 
(cable leaking water into the GigE-APC, the port didn't trip, and the 
card was hot as hell).


I was also unaware that Cambium won't be supporting sync-over-power on 
the 450m. I imagine the ringing/bounce issue killed that idea due to 
the high power consumption.


On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:


The current products should power the 450M just fine.  The rating is 
1A per pair per port, so at the 48V you're good up to 96W.



On Nov 14, 2016 7:50 PM, "George Skorup" > wrote:


The 450m pulls 70 watts. The current
SyncInjector/PowerInjector+Sync is around 1A max per port. What
you could do for now is a GigE-POE-APC and the new aux port
version SyncBox Junior.


On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same as
PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List
Account)
mailto:li...@packetflux.com>> wrote:

All of the currently shipping syncbox product line are
compatible.  For sync
over power, I have the specs, but the design isn't done yet.


On Nov 14, 2016 5:40 PM, "Sam Lambie"
mailto:samtaos...@gmail.com>> wrote:

A question for Forrest mostly. Have you come up with
a timing product for
the 450m AP yet? If not, have you got a timeline for
release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598  Office
www.Taosnet.com 

Re: [AFMUG] Packetflux & 450M Timing

[George Skorup]

For the record, 
http://store.packetflux.com/powerinjector-plus-sync-gigabit-version/ 
says: 1A per port maximum power.  (48 watts at 48 Volts)


So.. is the electronic over-current protection the 1A limit? Or is this 
just outdated info? Pretty sure it's >1A because I've "tested" it (cable 
leaking water into the GigE-APC, the port didn't trip, and the card was 
hot as hell).


I was also unaware that Cambium won't be supporting sync-over-power on 
the 450m. I imagine the ringing/bounce issue killed that idea due to the 
high power consumption.


On 11/14/2016 1:00 PM, Forrest Christian (List Account) wrote:


The current products should power the 450M just fine.  The rating is 
1A per pair per port, so at the 48V you're good up to 96W.



On Nov 14, 2016 7:50 PM, "George Skorup" > wrote:


The 450m pulls 70 watts. The current
SyncInjector/PowerInjector+Sync is around 1A max per port. What
you could do for now is a GigE-POE-APC and the new aux port
version SyncBox Junior.


On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same as PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
mailto:li...@packetflux.com>> wrote:

All of the currently shipping syncbox product line are
compatible.  For sync
over power, I have the specs, but the design isn't done yet.


On Nov 14, 2016 5:40 PM, "Sam Lambie"
mailto:samtaos...@gmail.com>> wrote:

A question for Forrest mostly. Have you come up with a
timing product for
the 450m AP yet? If not, have you got a timeline for
release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598  Office
www.Taosnet.com 

Re: [AFMUG] Packetflux & 450M Timing

[Chuck McCown]

I think that rating might be based on RJ45 contacts.  

From: Forrest Christian (List Account) 
Sent: Monday, November 14, 2016 12:33 PM
To: af 
Subject: Re: [AFMUG] Packetflux & 450M Timing

My personal preference would be not to exceed .75A per pair because that 
matches the official cat5 ratings.  


On Nov 14, 2016 8:03 PM, "Chuck McCown"  wrote:

  And, even though you will exceed published ratings, you can go to 1.5 amps 
per port without saturating the cores of the transformer.  
  It will get hot, but not hot enough to unsolder itself.  

  From: Forrest Christian (List Account) 
  Sent: Monday, November 14, 2016 12:00 PM
  To: af 
  Subject: Re: [AFMUG] Packetflux & 450M Timing

  The current products should power the 450M just fine.  The rating is 1A per 
pair per port, so at the 48V you're good up to 96W. 


  On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:

The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is 
around 1A max per port. What you could do for now is a GigE-POE-APC and the new 
aux port version SyncBox Junior. 


On 11/14/2016 12:34 PM, Matt wrote:

  Shouldn't the sync over power for the 450M be the same as PMP450i?

  How is the 1u sync injector coming?



  On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
   wrote:

All of the currently shipping syncbox product line are compatible.  For 
sync
over power, I have the specs, but the design isn't done yet.


On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:

  A question for Forrest mostly. Have you come up with a timing product 
for
  the 450m AP yet? If not, have you got a timeline for release?

  Sam

  --
  --
  Sam Lambie
  Taosnet Wireless Tech.
  575-758-7598 Office
  www.Taosnet.com

Re: [AFMUG] Packetflux & 450M Timing

[Forrest Christian (List Account)]

My personal preference would be not to exceed .75A per pair because that
matches the official cat5 ratings.

On Nov 14, 2016 8:03 PM, "Chuck McCown"  wrote:

> And, even though you will exceed published ratings, you can go to 1.5 amps
> per port without saturating the cores of the transformer.
> It will get hot, but not hot enough to unsolder itself.
>
> *From:* Forrest Christian (List Account)
> *Sent:* Monday, November 14, 2016 12:00 PM
> *To:* af
> *Subject:* Re: [AFMUG] Packetflux & 450M Timing
>
>
> The current products should power the 450M just fine.  The rating is 1A
> per pair per port, so at the 48V you're good up to 96W.
>
> On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:
>
> The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is
> around 1A max per port. What you could do for now is a GigE-POE-APC and the
> new aux port version SyncBox Junior.
>
>
> On 11/14/2016 12:34 PM, Matt wrote:
>
>> Shouldn't the sync over power for the 450M be the same as PMP450i?
>>
>> How is the 1u sync injector coming?
>>
>>
>> On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
>>  wrote:
>>
>>> All of the currently shipping syncbox product line are compatible.  For
>>> sync
>>> over power, I have the specs, but the design isn't done yet.
>>>
>>>
>>> On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>>>
 A question for Forrest mostly. Have you come up with a timing product
 for
 the 450m AP yet? If not, have you got a timeline for release?

 Sam

 --
 --
 Sam Lambie
 Taosnet Wireless Tech.
 575-758-7598 Office
 www.Taosnet.com

>>>
>
>

Re: [AFMUG] OT: Something beautiful happened on Election Night

[Larry Smith]

Major congratulations!!!

-- 
Larry Smith
lesm...@ecsis.net

On Mon November 14 2016 12:17, Ben Royer wrote:
> My love and I welcomed our newest family member into the world, our
> daughter Isabelle!
>
>
>
>
> Thank you,
> Ben Royer, Operations Manager
> Royell Communications, Inc.
> 217-965-3699 www.royell.net

Re: [AFMUG] Packetflux & 450M Timing

[Chuck McCown]

And, even though you will exceed published ratings, you can go to 1.5 amps per 
port without saturating the cores of the transformer.  
It will get hot, but not hot enough to unsolder itself.  

From: Forrest Christian (List Account) 
Sent: Monday, November 14, 2016 12:00 PM
To: af 
Subject: Re: [AFMUG] Packetflux & 450M Timing

The current products should power the 450M just fine.  The rating is 1A per 
pair per port, so at the 48V you're good up to 96W. 


On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:

  The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is 
around 1A max per port. What you could do for now is a GigE-POE-APC and the new 
aux port version SyncBox Junior. 


  On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same as PMP450i?

How is the 1u sync injector coming?



On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
 wrote:

  All of the currently shipping syncbox product line are compatible.  For 
sync
  over power, I have the specs, but the design isn't done yet.


  On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:

A question for Forrest mostly. Have you come up with a timing product 
for
the 450m AP yet? If not, have you got a timeline for release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598 Office
www.Taosnet.com

Re: [AFMUG] Packetflux & 450M Timing

[Forrest Christian (List Account)]

The current products should power the 450M just fine.  The rating is 1A per
pair per port, so at the 48V you're good up to 96W.

On Nov 14, 2016 7:50 PM, "George Skorup"  wrote:

The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is
around 1A max per port. What you could do for now is a GigE-POE-APC and the
new aux port version SyncBox Junior.


On 11/14/2016 12:34 PM, Matt wrote:

> Shouldn't the sync over power for the 450M be the same as PMP450i?
>
> How is the 1u sync injector coming?
>
>
> On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
>  wrote:
>
>> All of the currently shipping syncbox product line are compatible.  For
>> sync
>> over power, I have the specs, but the design isn't done yet.
>>
>>
>> On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>>
>>> A question for Forrest mostly. Have you come up with a timing product for
>>> the 450m AP yet? If not, have you got a timeline for release?
>>>
>>> Sam
>>>
>>> --
>>> --
>>> Sam Lambie
>>> Taosnet Wireless Tech.
>>> 575-758-7598 Office
>>> www.Taosnet.com
>>>
>>

Re: [AFMUG] Packetflux & 450M Timing

[Bill Prince]

Put in context, the 450M will fit in where 3, 4, 5, or maybe even 6 
standard 450 APs fit. So you should figure that as 70/3, or 70/4, or 
whatever fits your situation.



bp


On 11/14/2016 10:50 AM, George Skorup wrote:
The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync 
is around 1A max per port. What you could do for now is a GigE-POE-APC 
and the new aux port version SyncBox Junior.


On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same as PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
 wrote:
All of the currently shipping syncbox product line are compatible.  
For sync

over power, I have the specs, but the design isn't done yet.


On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
A question for Forrest mostly. Have you come up with a timing 
product for

the 450m AP yet? If not, have you got a timeline for release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598 Office
www.Taosnet.com

Re: [AFMUG] Packetflux & 450M Timing

[Forrest Christian (List Account)]

No,  Cambium elected  to drop the traditional sync over power on the 450M.

So,  you either need to use timing port sync (via the aux port) or use what
they're calling cambium sync.

The 1U injector is very close.  I need to finish validation on the latest
board revisions and then will be releasing it to production assuming there
isn't some showstopper I missed.

On Nov 14, 2016 7:34 PM, "Matt"  wrote:

> Shouldn't the sync over power for the 450M be the same as PMP450i?
>
> How is the 1u sync injector coming?
>
>
> On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
>  wrote:
> > All of the currently shipping syncbox product line are compatible.  For
> sync
> > over power, I have the specs, but the design isn't done yet.
> >
> >
> > On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
> >>
> >> A question for Forrest mostly. Have you come up with a timing product
> for
> >> the 450m AP yet? If not, have you got a timeline for release?
> >>
> >> Sam
> >>
> >> --
> >> --
> >> Sam Lambie
> >> Taosnet Wireless Tech.
> >> 575-758-7598 Office
> >> www.Taosnet.com
>

Re: [AFMUG] Packetflux & 450M Timing

[George Skorup]

The 450m pulls 70 watts. The current SyncInjector/PowerInjector+Sync is 
around 1A max per port. What you could do for now is a GigE-POE-APC and 
the new aux port version SyncBox Junior.


On 11/14/2016 12:34 PM, Matt wrote:

Shouldn't the sync over power for the 450M be the same as PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
 wrote:

All of the currently shipping syncbox product line are compatible.  For sync
over power, I have the specs, but the design isn't done yet.


On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:

A question for Forrest mostly. Have you come up with a timing product for
the 450m AP yet? If not, have you got a timeline for release?

Sam

--
--
Sam Lambie
Taosnet Wireless Tech.
575-758-7598 Office
www.Taosnet.com

Re: [AFMUG] Packetflux & 450M Timing

[Matt]

> It’s a lot of power compared to 450i, right?

Aw, I didn't think of that...

Re: [AFMUG] OT: Something beautiful happened on Election Night

[Chuck McCown]

I have made some good choices in life, but the best thing I ever did was marry 
the girl I married and gave her total control over the size of the family.  
(I would have probably had a stroke if I had known from the outset that we 
would end up with 8 kids) 

Congrats.

From: Ben Royer 
Sent: Monday, November 14, 2016 11:17 AM
To: af@afmug.com 
Subject: [AFMUG] OT: Something beautiful happened on Election Night

My love and I welcomed our newest family member into the world, our daughter 
Isabelle!




Thank you,
Ben Royer, Operations Manager
Royell Communications, Inc.
217-965-3699 www.royell.net

Re: [AFMUG] Packetflux & 450M Timing

[Ken Hohhof]

It’s a lot of power compared to 450i, right?

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sam Lambie
Sent: Monday, November 14, 2016 12:41 PM
To: af@afmug.com
Subject: Re: [AFMUG] Packetflux & 450M Timing

 

Yeah, I am looking for Sync over Power if possible.

 

On Mon, Nov 14, 2016 at 11:30 AM, Forrest Christian (List Account) 
mailto:li...@packetflux.com> > wrote:

All of the currently shipping syncbox product line are compatible.  For sync 
over power, I have the specs, but the design isn't done yet. 

 

On Nov 14, 2016 5:40 PM, "Sam Lambie" mailto:samtaos...@gmail.com> > wrote:

A question for Forrest mostly. Have you come up with a timing product for the 
450m AP yet? If not, have you got a timeline for release?

Sam



-- 

-- 
Sam Lambie
Taosnet Wireless Tech.
575-758-7598   Office
www.Taosnet.com  




-- 

-- 
Sam Lambie
Taosnet Wireless Tech.
575-758-7598 Office
www.Taosnet.com  

Re: [AFMUG] OT: Something beautiful happened on Election Night

[Jaime Solorza]

Awesome... God Bless

On Nov 14, 2016 11:33 AM, "Jerry Head"  wrote:

> Congratulations!
>
> On 11/14/2016 12:17 PM, Ben Royer wrote:
>
> My love and I welcomed our newest family member into the world, our
> daughter Isabelle!
> �
> [image: Isabelle]
> �
> �
> Thank you,
> Ben Royer, Operations Manager
> Royell Communications, Inc.
> 217-965-3699 www.royell.net
>
>
>

Re: [AFMUG] Packetflux & 450M Timing

[Sam Lambie]

Yeah, I am looking for Sync over Power if possible.

On Mon, Nov 14, 2016 at 11:30 AM, Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> All of the currently shipping syncbox product line are compatible.  For
> sync over power, I have the specs, but the design isn't done yet.
>
> On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>
>> A question for Forrest mostly. Have you come up with a timing product for
>> the 450m AP yet? If not, have you got a timeline for release?
>>
>> Sam
>>
>> --
>> --
>> *Sam Lambie*
>> Taosnet Wireless Tech.
>> 575-758-7598 Office
>> www.Taosnet.com 
>>
>


-- 
-- 
*Sam Lambie*
Taosnet Wireless Tech.
575-758-7598 Office
www.Taosnet.com 

Re: [AFMUG] Packetflux & 450M Timing

[Matt]

Shouldn't the sync over power for the 450M be the same as PMP450i?

How is the 1u sync injector coming?


On Mon, Nov 14, 2016 at 12:30 PM, Forrest Christian (List Account)
 wrote:
> All of the currently shipping syncbox product line are compatible.  For sync
> over power, I have the specs, but the design isn't done yet.
>
>
> On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:
>>
>> A question for Forrest mostly. Have you come up with a timing product for
>> the 450m AP yet? If not, have you got a timeline for release?
>>
>> Sam
>>
>> --
>> --
>> Sam Lambie
>> Taosnet Wireless Tech.
>> 575-758-7598 Office
>> www.Taosnet.com

Re: [AFMUG] OT: Something beautiful happened on Election Night

[Jerry Head]

Congratulations!

On 11/14/2016 12:17 PM, Ben Royer wrote:
My love and I welcomed our newest family member into the world, our 
daughter Isabelle!

Isabelle
Thank you,
Ben Royer, Operations Manager
Royell Communications, Inc.
217-965-3699 www.royell.net

Re: [AFMUG] Packetflux & 450M Timing

[Forrest Christian (List Account)]

All of the currently shipping syncbox product line are compatible.  For
sync over power, I have the specs, but the design isn't done yet.

On Nov 14, 2016 5:40 PM, "Sam Lambie"  wrote:

> A question for Forrest mostly. Have you come up with a timing product for
> the 450m AP yet? If not, have you got a timeline for release?
>
> Sam
>
> --
> --
> *Sam Lambie*
> Taosnet Wireless Tech.
> 575-758-7598 Office
> www.Taosnet.com 
>

Re: [AFMUG] OT: Something beautiful happened on Election Night

[Hardy, Tim]

Congratulations!  What a beautiful family.

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ben Royer
Sent: Monday, November 14, 2016 1:18 PM
To: af@afmug.com
Subject: [AFMUG] OT: Something beautiful happened on Election Night

My love and I welcomed our newest family member into the world, our daughter 
Isabelle!

[Isabelle]


Thank you,
Ben Royer, Operations Manager
Royell Communications, Inc.
217-965-3699 www.royell.net

[AFMUG] OT: Something beautiful happened on Election Night

[Ben Royer]

My love and I welcomed our newest family member into the world, our daughter 
Isabelle!




Thank you,
Ben Royer, Operations Manager
Royell Communications, Inc.
217-965-3699 www.royell.net

Re: [AFMUG] Trango Security Issue

[Adam Moffett]

LOL

-- Original Message --
From: "Ken Hohhof" 
To: af@afmug.com
Sent: 11/14/2016 12:22:43 PM
Subject: Re: [AFMUG] Trango Security Issue

I had a friend who kept a spare car key in his glove compartment in 
case he locked himself out of his car.






From: Af [mailto:af-boun...@afmug.com] On Behalf Of Simon Westlake
Sent: Monday, November 14, 2016 11:04 AM
To:af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



I wouldn't recommend panic anyway (unless your management 
infrastructure is not properly secured, in which case, I would be 
panicking about a lot more than a Trango backdoor.) As long as your 
infrastructure is properly locked down and secured, most of these types 
of issues are largely irrelevant in general, as the avenue of attack is 
close to zero.


Most of my statements on this thread are philosophical. If someone said 
to me, I'm designing a device, and I need a way to reset the password 
if a user forgets it, would I recommend this approach? Definitely not. 
If the question is (assuming all ISPs are properly securing their 
infrastructure) - do I think this is going to be a massive security 
risk? Probably not. But I think it is important to talk about proper 
approaches, especially since Trango has posted in this thread looking 
for feedback.


On 11/14/2016 10:58 AM, Adam Moffett wrote:

I can see both sides of this.  Simon and Paul make correct and salient 
arguments about having a back door, but like Ken I'm not panicking 
about it.






-- Original Message --

From: "Ken Hohhof" 

To: af@afmug.com

Sent: 11/14/2016 11:13:39 AM

Subject: Re: [AFMUG] Trango Security Issue



Just last week someone was dealing with a whole Mikrotik network from 
a WISP they bought and the fired ex admin had changed all the 
passwords.  So it’s not just people too lazy to keep track of 
passwords.  There are all sorts of scenarios.  I remember once I 
couldn’t get into a Ubiquiti backhaul, after trying every typo I 
could think of I finally figured out that I had changed the username 
from ubnt to admon instead of admin.  And we generally disable the 
reset button due to problems with spontaneous false resets.




I remember actually remember leaving Trango radios at trango/trango 
for quite awhile because I was so scared of mistyping the new 
password and having to send a climber 200 feet up with a laptop.  
(obviously you should change the password while the radios are still 
on the ground)






From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Monday, November 14, 2016 9:58 AM
To:af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



Agree 110% …



It does suck re: having to climb a tower to reset a password but 
would also think that folks might suddenly be inclined to keep better 
track of passwords after having to do so a couple of times ;)






On Nov 14, 2016, at 10:52 AM, Simon Westlake  
wrote:




You may not be the only one to make that assumption, but I find it 
hard to throw my hands up and say 'Oh well' to a hard coded, fixed 
password root account that is publicly accessible on any kind of 
device.




On 11/14/2016 9:44 AM, Ken Hohhof wrote:

I think in some cases this means climbing the tower with a laptop 
and a serial cable though.




Am I the only one who assumes everything has one or more backdoors, 
including my car?  There’s the one the manufacturer knows about, 
the one the NSA put there, the one the software engineer put there 
and didn’t tell his boss about, the one the Chinese chip maker put 
there, the one Fancy Bear put there …






From: Af [mailto:af-boun...@afmug.com] On Behalf Of Simon Westlake
Sent: Monday, November 14, 2016 9:11 AM
To: af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



There's no reason for it to be secret, either. If it exists purely 
to assist customers who forgot their password, then there is no 
reason to both disclose it, and offer the user the ability to turn 
it off. As long as there is still a physical reset method, then any 
fallout from forgetting a password ends up on the customer, if they 
disabled the ability for it to be reset.


Let's just imagine right now that someone has already built a bot 
that is going out, scanning for Trango radios, and modifying the 
running code on them. You can argue that some fault lies with the 
operator for not properly securing his/her network, but the root 
cause of the problem is an insecure, root account, hard coded into 
a radio, with a fixed password, that cannot be disabled.


On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher and this 
blows up badly on the vendor in my opinion….   makes you wonder 
what else they are doing in their software that they are not 
telling you about - just an example and not suggesting there’s 
more in this case







On Nov 13, 2016, at 5:51 PM, Ken Hohhof  wrote:



Well, it’s not a secret backdoor if you disclose it.



“You ever flashy thinged me?”

“No.”

Re: [AFMUG] Trango Security Issue

[Ken Hohhof]

I had a friend who kept a spare car key in his glove compartment in case he 
locked himself out of his car.

 

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Simon Westlake
Sent: Monday, November 14, 2016 11:04 AM
To: af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue

 

I wouldn't recommend panic anyway (unless your management infrastructure is not 
properly secured, in which case, I would be panicking about a lot more than a 
Trango backdoor.) As long as your infrastructure is properly locked down and 
secured, most of these types of issues are largely irrelevant in general, as 
the avenue of attack is close to zero.

Most of my statements on this thread are philosophical. If someone said to me, 
I'm designing a device, and I need a way to reset the password if a user 
forgets it, would I recommend this approach? Definitely not. If the question is 
(assuming all ISPs are properly securing their infrastructure) - do I think 
this is going to be a massive security risk? Probably not. But I think it is 
important to talk about proper approaches, especially since Trango has posted 
in this thread looking for feedback.

On 11/14/2016 10:58 AM, Adam Moffett wrote:

I can see both sides of this.  Simon and Paul make correct and salient 
arguments about having a back door, but like Ken I'm not panicking about it.

 

 

-- Original Message --

From: "Ken Hohhof" mailto:af...@kwisp.com> >

To: af@afmug.com  

Sent: 11/14/2016 11:13:39 AM

Subject: Re: [AFMUG] Trango Security Issue

 

Just last week someone was dealing with a whole Mikrotik network from a WISP 
they bought and the fired ex admin had changed all the passwords.  So it’s not 
just people too lazy to keep track of passwords.  There are all sorts of 
scenarios.  I remember once I couldn’t get into a Ubiquiti backhaul, after 
trying every typo I could think of I finally figured out that I had changed the 
username from ubnt to admon instead of admin.  And we generally disable the 
reset button due to problems with spontaneous false resets.

 

I remember actually remember leaving Trango radios at trango/trango for quite 
awhile because I was so scared of mistyping the new password and having to send 
a climber 200 feet up with a laptop.  (obviously you should change the password 
while the radios are still on the ground)

 

 

From: Af [mailto:af-boun...@afmug.com  ] On Behalf 
Of Paul Stewart
Sent: Monday, November 14, 2016 9:58 AM
To: af@afmug.com  
Subject: Re: [AFMUG] Trango Security Issue

 

Agree 110% … 

 

It does suck re: having to climb a tower to reset a password but would also 
think that folks might suddenly be inclined to keep better track of passwords 
after having to do so a couple of times ;)

 

 

On Nov 14, 2016, at 10:52 AM, Simon Westlake mailto:simon@sonar.software> > wrote:

 

You may not be the only one to make that assumption, but I find it hard to 
throw my hands up and say 'Oh well' to a hard coded, fixed password root 
account that is publicly accessible on any kind of device.




On 11/14/2016 9:44 AM, Ken Hohhof wrote:

I think in some cases this means climbing the tower with a laptop and a serial 
cable though.

 

Am I the only one who assumes everything has one or more backdoors, including 
my car?  There’s the one the manufacturer knows about, the one the NSA put 
there, the one the software engineer put there and didn’t tell his boss about, 
the one the Chinese chip maker put there, the one Fancy Bear put there …

 

 

From: Af [  mailto:af-boun...@afmug.com] On Behalf 
Of Simon Westlake
Sent: Monday, November 14, 2016 9:11 AM
To:   af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue

 

There's no reason for it to be secret, either. If it exists purely to assist 
customers who forgot their password, then there is no reason to both disclose 
it, and offer the user the ability to turn it off. As long as there is still a 
physical reset method, then any fallout from forgetting a password ends up on 
the customer, if they disabled the ability for it to be reset.

Let's just imagine right now that someone has already built a bot that is going 
out, scanning for Trango radios, and modifying the running code on them. You 
can argue that some fault lies with the operator for not properly securing 
his/her network, but the root cause of the problem is an insecure, root 
account, hard coded into a radio, with a fixed password, that cannot be 
disabled.

On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher and this blows up 
badly on the vendor in my opinion….   makes you wonder what else they are doing 
in their software that they are not telling you about - just an example and not 
suggesting there’s more in this case  

 

 

On Nov 13, 2016, at 5:51 PM, Ken Hohhof <  
af...@kwisp.com> wrote:

 

Well, 

Re: [AFMUG] Trango Security Issue

[Adam Moffett]

Well said.



-- Original Message --
From: "Simon Westlake" 
To: af@afmug.com
Sent: 11/14/2016 12:03:35 PM
Subject: Re: [AFMUG] Trango Security Issue

I wouldn't recommend panic anyway (unless your management 
infrastructure is not properly secured, in which case, I would be 
panicking about a lot more than a Trango backdoor.) As long as your 
infrastructure is properly locked down and secured, most of these types 
of issues are largely irrelevant in general, as the avenue of attack is 
close to zero.


Most of my statements on this thread are philosophical. If someone said 
to me, I'm designing a device, and I need a way to reset the password 
if a user forgets it, would I recommend this approach? Definitely not. 
If the question is (assuming all ISPs are properly securing their 
infrastructure) - do I think this is going to be a massive security 
risk? Probably not. But I think it is important to talk about proper 
approaches, especially since Trango has posted in this thread looking 
for feedback.


On 11/14/2016 10:58 AM, Adam Moffett wrote:
I can see both sides of this.  Simon and Paul make correct and salient 
arguments about having a back door, but like Ken I'm not panicking 
about it.



-- Original Message --
From: "Ken Hohhof" 
To: af@afmug.com
Sent: 11/14/2016 11:13:39 AM
Subject: Re: [AFMUG] Trango Security Issue

Just last week someone was dealing with a whole Mikrotik network from 
a WISP they bought and the fired ex admin had changed all the 
passwords.  So it’s not just people too lazy to keep track of 
passwords.  There are all sorts of scenarios.  I remember once I 
couldn’t get into a Ubiquiti backhaul, after trying every typo I 
could think of I finally figured out that I had changed the username 
from ubnt to admon instead of admin.  And we generally disable the 
reset button due to problems with spontaneous false resets.




I remember actually remember leaving Trango radios at trango/trango 
for quite awhile because I was so scared of mistyping the new 
password and having to send a climber 200 feet up with a laptop.  
(obviously you should change the password while the radios are still 
on the ground)






From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Monday, November 14, 2016 9:58 AM
To:af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



Agree 110% …



It does suck re: having to climb a tower to reset a password but 
would also think that folks might suddenly be inclined to keep better 
track of passwords after having to do so a couple of times ;)






On Nov 14, 2016, at 10:52 AM, Simon Westlake  
wrote:




You may not be the only one to make that assumption, but I find it 
hard to throw my hands up and say 'Oh well' to a hard coded, fixed 
password root account that is publicly accessible on any kind of 
device.



On 11/14/2016 9:44 AM, Ken Hohhof wrote:

I think in some cases this means climbing the tower with a laptop 
and a serial cable though.




Am I the only one who assumes everything has one or more backdoors, 
including my car?  There’s the one the manufacturer knows about, 
the one the NSA put there, the one the software engineer put there 
and didn’t tell his boss about, the one the Chinese chip maker put 
there, the one Fancy Bear put there …






From: Af [mailto:af-boun...@afmug.com] On Behalf Of Simon Westlake
Sent: Monday, November 14, 2016 9:11 AM
To: af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



There's no reason for it to be secret, either. If it exists purely 
to assist customers who forgot their password, then there is no 
reason to both disclose it, and offer the user the ability to turn 
it off. As long as there is still a physical reset method, then any 
fallout from forgetting a password ends up on the customer, if they 
disabled the ability for it to be reset.


Let's just imagine right now that someone has already built a bot 
that is going out, scanning for Trango radios, and modifying the 
running code on them. You can argue that some fault lies with the 
operator for not properly securing his/her network, but the root 
cause of the problem is an insecure, root account, hard coded into 
a radio, with a fixed password, that cannot be disabled.


On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher and this 
blows up badly on the vendor in my opinion….   makes you wonder 
what else they are doing in their software that they are not 
telling you about - just an example and not suggesting there’s 
more in this case







On Nov 13, 2016, at 5:51 PM, Ken Hohhof  wrote:



Well, it’s not a secret backdoor if you disclose it.



“You ever flashy thinged me?”

“No.”

“I ain’t playing with you, K, you ever flashy thinged me”?

“No.”



From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Sunday, November 13, 2016 3:56 PM
To: af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



Different people deploy them different ways 

Re: [AFMUG] Trango Security Issue

[Simon Westlake]

I wouldn't recommend panic anyway (unless your management infrastructure 
is not properly secured, in which case, I would be panicking about a lot 
more than a Trango backdoor.) As long as your infrastructure is properly 
locked down and secured, most of these types of issues are largely 
irrelevant in general, as the avenue of attack is close to zero.


Most of my statements on this thread are philosophical. If someone said 
to me, I'm designing a device, and I need a way to reset the password if 
a user forgets it, would I recommend this approach? Definitely not. If 
the question is (assuming all ISPs are properly securing their 
infrastructure) - do I think this is going to be a massive security 
risk? Probably not. But I think it is important to talk about proper 
approaches, especially since Trango has posted in this thread looking 
for feedback.


On 11/14/2016 10:58 AM, Adam Moffett wrote:
I can see both sides of this.  Simon and Paul make correct and salient 
arguments about having a back door, but like Ken I'm not panicking 
about it.

-- Original Message --
From: "Ken Hohhof" mailto:af...@kwisp.com>>
To: af@afmug.com 
Sent: 11/14/2016 11:13:39 AM
Subject: Re: [AFMUG] Trango Security Issue


Just last week someone was dealing with a whole Mikrotik network from 
a WISP they bought and the fired ex admin had changed all the 
passwords.  So it’s not just people too lazy to keep track of 
passwords.  There are all sorts of scenarios.  I remember once I 
couldn’t get into a Ubiquiti backhaul, after trying every typo I 
could think of I finally figured out that I had changed the username 
from ubnt to admon instead of admin.  And we generally disable the 
reset button due to problems with spontaneous false resets.


I remember actually remember leaving Trango radios at trango/trango 
for quite awhile because I was so scared of mistyping the new 
password and having to send a climber 200 feet up with a laptop.  
(obviously you should change the password while the radios are still 
on the ground)


*From:*Af [mailto:af-boun...@afmug.com ] 
*On Behalf Of *Paul Stewart

*Sent:* Monday, November 14, 2016 9:58 AM
*To:* af@afmug.com 
*Subject:* Re: [AFMUG] Trango Security Issue

Agree 110% …

It does suck re: having to climb a tower to reset a password but 
would also think that folks might suddenly be inclined to keep better 
track of passwords after having to do so a couple of times ;)


On Nov 14, 2016, at 10:52 AM, Simon Westlake
mailto:simon@sonar.software>> wrote:

You may not be the only one to make that assumption, but I find
it hard to throw my hands up and say 'Oh well' to a hard coded,
fixed password root account that is publicly accessible on any
kind of device.

On 11/14/2016 9:44 AM, Ken Hohhof wrote:

I think in some cases this means climbing the tower with a
laptop and a serial cable though.

Am I the only one who assumes everything has one or more
backdoors, including my car?  There’s the one the
manufacturer knows about, the one the NSA put there, the one
the software engineer put there and didn’t tell his boss
about, the one the Chinese chip maker put there, the one
Fancy Bear put there …

*From:*Af [mailto:af-boun...@afmug.com]*On Behalf Of*Simon
Westlake
*Sent:*Monday, November 14, 2016 9:11 AM
*To:*af@afmug.com 
*Subject:*Re: [AFMUG] Trango Security Issue

There's no reason for it to be secret, either. If it exists
purely to assist customers who forgot their password, then
there is no reason to both disclose it, and offer the user
the ability to turn it off. As long as there is still a
physical reset method, then any fallout from forgetting a
password ends up on the customer, if they disabled the
ability for it to be reset.

Let's just imagine right now that someone has already built a
bot that is going out, scanning for Trango radios, and
modifying the running code on them. You can argue that some
fault lies with the operator for not properly securing
his/her network, but the root cause of the problem is an
insecure, root account, hard coded into a radio, with a fixed
password, that cannot be disabled.

On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher
and this blows up badly on the vendor in my opinion….  
makes you wonder what else they are doing in their

software that they are not telling you about - just an
example and not suggesting there’s more in this case

On Nov 13, 2016, at 5:51 PM, Ken Hohhof
mailto:af...@kwisp.com>> wrote:

Well, it’s not a secret backdoor if you disclose 

Re: [AFMUG] Trango Security Issue

[Adam Moffett]

I can see both sides of this.  Simon and Paul make correct and salient 
arguments about having a back door, but like Ken I'm not panicking about 
it.



-- Original Message --
From: "Ken Hohhof" 
To: af@afmug.com
Sent: 11/14/2016 11:13:39 AM
Subject: Re: [AFMUG] Trango Security Issue

Just last week someone was dealing with a whole Mikrotik network from a 
WISP they bought and the fired ex admin had changed all the passwords.  
So it’s not just people too lazy to keep track of passwords.  There are 
all sorts of scenarios.  I remember once I couldn’t get into a Ubiquiti 
backhaul, after trying every typo I could think of I finally figured 
out that I had changed the username from ubnt to admon instead of 
admin.  And we generally disable the reset button due to problems with 
spontaneous false resets.




I remember actually remember leaving Trango radios at trango/trango for 
quite awhile because I was so scared of mistyping the new password and 
having to send a climber 200 feet up with a laptop.  (obviously you 
should change the password while the radios are still on the ground)






From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Monday, November 14, 2016 9:58 AM
To:af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



Agree 110% …



It does suck re: having to climb a tower to reset a password but would 
also think that folks might suddenly be inclined to keep better track 
of passwords after having to do so a couple of times ;)






On Nov 14, 2016, at 10:52 AM, Simon Westlake  
wrote:




You may not be the only one to make that assumption, but I find it 
hard to throw my hands up and say 'Oh well' to a hard coded, fixed 
password root account that is publicly accessible on any kind of 
device.



On 11/14/2016 9:44 AM, Ken Hohhof wrote:

I think in some cases this means climbing the tower with a laptop and 
a serial cable though.




Am I the only one who assumes everything has one or more backdoors, 
including my car?  There’s the one the manufacturer knows about, the 
one the NSA put there, the one the software engineer put there and 
didn’t tell his boss about, the one the Chinese chip maker put there, 
the one Fancy Bear put there …






From: Af [mailto:af-boun...@afmug.com] On Behalf Of Simon Westlake
Sent: Monday, November 14, 2016 9:11 AM
To: af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



There's no reason for it to be secret, either. If it exists purely to 
assist customers who forgot their password, then there is no reason 
to both disclose it, and offer the user the ability to turn it off. 
As long as there is still a physical reset method, then any fallout 
from forgetting a password ends up on the customer, if they disabled 
the ability for it to be reset.


Let's just imagine right now that someone has already built a bot 
that is going out, scanning for Trango radios, and modifying the 
running code on them. You can argue that some fault lies with the 
operator for not properly securing his/her network, but the root 
cause of the problem is an insecure, root account, hard coded into a 
radio, with a fixed password, that cannot be disabled.


On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher and this 
blows up badly on the vendor in my opinion….   makes you wonder what 
else they are doing in their software that they are not telling you 
about - just an example and not suggesting there’s more in this case







On Nov 13, 2016, at 5:51 PM, Ken Hohhof  wrote:



Well, it’s not a secret backdoor if you disclose it.



“You ever flashy thinged me?”

“No.”

“I ain’t playing with you, K, you ever flashy thinged me”?

“No.”



From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Sunday, November 13, 2016 3:56 PM
To: af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue



Different people deploy them different ways … good or bad …



The biggest problem I have with this is when a vendor doesn’t 
disclose this information and that a customer cannot choose to 
remove this option if the vendor insists on putting it in place.






On Nov 13, 2016, at 4:35 PM, George Skorup  
wrote:




I don't exactly see the problem, especially with a PTP radio that 
should only be accessible from within your network and possibly 
only from management subnets/VLANs, too. If it's a public facing 
piece of equipment like a router, then sure, I agree.


On 11/13/2016 3:07 PM, Paul Stewart wrote:

Totally disagree with this… we would never let a vendor into our 
network if there was a possibility of this.  It puts our network 
at risk from their stupidity ….




We aggressively look at this when new products are coming into 
the network - realizing that sometimes there’s no way to detect 
it but it’s a question we ask, tests that we run, and hope that 
our confidence in this being possible is low.






On Nov 13, 2016, at 11:59 AM, Ken Hohhof  
wrote:




Yep.  There are legitimate needs f

Re: [AFMUG] ubnt devices intermittantly stop responding to pings

[Bill Prince]

The one I have answers to qwertyasdf


bp


On 11/14/2016 7:09 AM, Jeremy wrote:
So is there a new Trango firmware that changes it to something more 
secure (like p@$$word)?


On Mon, Nov 14, 2016 at 7:54 AM, Jay Weekley 
mailto:par...@cyberbroadband.net>> wrote:


Yeah, I think we have a radio that is doing that as well.  Power
Code reports it down but we log into it just fine.

Jeremy wrote:

I have seen M series do this under heavy load.  I usually take
it as an indicator that it is time for an upgrade. Is it an AP
or a BH?  Are there more than 30 clients on it?  If it is a
backhaul, how much bandwidth is it pushing at peak time?  Is
it at peak time when the pings start dropping?

On Mon, Nov 14, 2016 at 1:46 AM, TJ Trout mailto:t...@voltbb.com> >> wrote:

Yes, Yes.

Sometimes the radios reboot from watchdog when the host
they are
testing against has not been down :(

On Mon, Nov 14, 2016 at 12:21 AM, Timothy Steele
mailto:timothy.pct...@gmail.com>
>> wrote:

Are you can the latest firmware? Do you have ping watchdog
running inside the radios firmware ?


On Mon, Nov 14, 2016, 2:21 AM TJ Trout mailto:t...@voltbb.com>
>> wrote:

I did a little searching on the forum and I can't
see to
find anyone who has ran into this issue, I'm
noticing that
many of my ubnt devices will randomly stop
responding to
pings but the web ui and radio keep passing traffic
normally? within an hour the radio will start
responding
to pings again like it never even happened... No power
cycling or any intervention required.

[AFMUG] Packetflux & 450M Timing

[Sam Lambie]

A question for Forrest mostly. Have you come up with a timing product for
the 450m AP yet? If not, have you got a timeline for release?

Sam

-- 
-- 
*Sam Lambie*
Taosnet Wireless Tech.
575-758-7598 Office
www.Taosnet.com 

Re: [AFMUG] Trango Security Issue

[Ken Hohhof]

Just last week someone was dealing with a whole Mikrotik network from a WISP 
they bought and the fired ex admin had changed all the passwords.  So it’s not 
just people too lazy to keep track of passwords.  There are all sorts of 
scenarios.  I remember once I couldn’t get into a Ubiquiti backhaul, after 
trying every typo I could think of I finally figured out that I had changed the 
username from ubnt to admon instead of admin.  And we generally disable the 
reset button due to problems with spontaneous false resets.

 

I remember actually remember leaving Trango radios at trango/trango for quite 
awhile because I was so scared of mistyping the new password and having to send 
a climber 200 feet up with a laptop.  (obviously you should change the password 
while the radios are still on the ground)

 

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Paul Stewart
Sent: Monday, November 14, 2016 9:58 AM
To: af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue

 

Agree 110% … 

 

It does suck re: having to climb a tower to reset a password but would also 
think that folks might suddenly be inclined to keep better track of passwords 
after having to do so a couple of times ;)

 

 

On Nov 14, 2016, at 10:52 AM, Simon Westlake mailto:simon@sonar.software> > wrote:

 

You may not be the only one to make that assumption, but I find it hard to 
throw my hands up and say 'Oh well' to a hard coded, fixed password root 
account that is publicly accessible on any kind of device.



On 11/14/2016 9:44 AM, Ken Hohhof wrote:

I think in some cases this means climbing the tower with a laptop and a serial 
cable though.

 

Am I the only one who assumes everything has one or more backdoors, including 
my car?  There’s the one the manufacturer knows about, the one the NSA put 
there, the one the software engineer put there and didn’t tell his boss about, 
the one the Chinese chip maker put there, the one Fancy Bear put there …

 

 

From: Af [  mailto:af-boun...@afmug.com] On Behalf 
Of Simon Westlake
Sent: Monday, November 14, 2016 9:11 AM
To:   af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue

 

There's no reason for it to be secret, either. If it exists purely to assist 
customers who forgot their password, then there is no reason to both disclose 
it, and offer the user the ability to turn it off. As long as there is still a 
physical reset method, then any fallout from forgetting a password ends up on 
the customer, if they disabled the ability for it to be reset.

Let's just imagine right now that someone has already built a bot that is going 
out, scanning for Trango radios, and modifying the running code on them. You 
can argue that some fault lies with the operator for not properly securing 
his/her network, but the root cause of the problem is an insecure, root 
account, hard coded into a radio, with a fixed password, that cannot be 
disabled.

On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher and this blows up 
badly on the vendor in my opinion….   makes you wonder what else they are doing 
in their software that they are not telling you about - just an example and not 
suggesting there’s more in this case  

 

 

On Nov 13, 2016, at 5:51 PM, Ken Hohhof <  
af...@kwisp.com> wrote:

 

Well, it’s not a secret backdoor if you disclose it.

 

“You ever flashy thinged me?”

“No.”

“I ain’t playing with you, K, you ever flashy thinged me”?

“No.”

 

From: Af [  mailto:af-boun...@afmug.com] On Behalf 
Of Paul Stewart
Sent: Sunday, November 13, 2016 3:56 PM
To:   af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue

 

Different people deploy them different ways … good or bad …

 

The biggest problem I have with this is when a vendor doesn’t disclose this 
information and that a customer cannot choose to remove this option if the 
vendor insists on putting it in place.  

 

 

On Nov 13, 2016, at 4:35 PM, George Skorup <  
geo...@cbcast.com> wrote:

 

I don't exactly see the problem, especially with a PTP radio that should only 
be accessible from within your network and possibly only from management 
subnets/VLANs, too. If it's a public facing piece of equipment like a router, 
then sure, I agree.

On 11/13/2016 3:07 PM, Paul Stewart wrote:

Totally disagree with this… we would never let a vendor into our network if 
there was a possibility of this.  It puts our network at risk from their 
stupidity …. 

 

We aggressively look at this when new products are coming into the network - 
realizing that sometimes there’s no way to detect it but it’s a question we 
ask, tests that we run, and hope that our confidence in this being possible is 
low.

 

 

On Nov 13, 2016, at 11:59 AM, Ken Hohhof <  
af...@kwisp.com> wrote:

 

Yep.  There are legitimate needs for the f

Re: [AFMUG] Trango Security Issue

[Simon Westlake]

And let's also acknowledge that you don't need to offer complete root 
access to a device to do a password reset. There could easily be a 
feature where you can reset the password through a web interface by 
entering a hashed version of the MAC address as an authentication 
string, or some other mechanism that doesn't expose the entire internals 
of the device to anyone.


On 11/14/2016 9:57 AM, Paul Stewart wrote:

Agree 110% …

It does suck re: having to climb a tower to reset a password but would 
also think that folks might suddenly be inclined to keep better track 
of passwords after having to do so a couple of times ;)



On Nov 14, 2016, at 10:52 AM, Simon Westlake > wrote:


You may not be the only one to make that assumption, but I find it 
hard to throw my hands up and say 'Oh well' to a hard coded, fixed 
password root account that is publicly accessible on any kind of device.


On 11/14/2016 9:44 AM, Ken Hohhof wrote:
I think in some cases this means climbing the tower with a laptop 
and a serial cable though.
Am I the only one who assumes everything has one or more backdoors, 
including my car?  There’s the one the manufacturer knows about, the 
one the NSA put there, the one the software engineer put there and 
didn’t tell his boss about, the one the Chinese chip maker put 
there, the one Fancy Bear put there …

*From:*Af [mailto:af-boun...@afmug.com]*On Behalf Of*Simon Westlake
*Sent:*Monday, November 14, 2016 9:11 AM
*To:*af@afmug.com
*Subject:*Re: [AFMUG] Trango Security Issue

There's no reason for it to be secret, either. If it exists purely 
to assist customers who forgot their password, then there is no 
reason to both disclose it, and offer the user the ability to turn 
it off. As long as there is still a physical reset method, then any 
fallout from forgetting a password ends up on the customer, if they 
disabled the ability for it to be reset.


Let's just imagine right now that someone has already built a bot 
that is going out, scanning for Trango radios, and modifying the 
running code on them. You can argue that some fault lies with the 
operator for not properly securing his/her network, but the root 
cause of the problem is an insecure, root account, hard coded into a 
radio, with a fixed password, that cannot be disabled.


On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher and
this blows up badly on the vendor in my opinion….   makes you
wonder what else they are doing in their software that they are
not telling you about - just an example and not suggesting
there’s more in this case

On Nov 13, 2016, at 5:51 PM, Ken Hohhof mailto:af...@kwisp.com>> wrote:
Well, it’s not a secret backdoor if you disclose it.
“You ever flashy thinged me?”
“No.”
“I ain’t playing with you, K, you ever flashy thinged me”?
“No.”
*From:*Af [mailto:af-boun...@afmug.com]*On Behalf Of*Paul
Stewart
*Sent:*Sunday, November 13, 2016 3:56 PM
*To:*af@afmug.com 
*Subject:*Re: [AFMUG] Trango Security Issue
Different people deploy them different ways … good or bad …
The biggest problem I have with this is when a vendor
doesn’t disclose this information and that a customer cannot
choose to remove this option if the vendor insists on
putting it in place.

On Nov 13, 2016, at 4:35 PM, George Skorup
mailto:geo...@cbcast.com>> wrote:

I don't exactly see the problem, especially with a PTP
radio that should only be accessible from within your
network and possibly only from management subnets/VLANs,
too. If it's a public facing piece of equipment like a
router, then sure, I agree.

On 11/13/2016 3:07 PM, Paul Stewart wrote:

Totally disagree with this… we would never let a
vendor into our network if there was a possibility
of this.  It puts our network at risk from their
stupidity ….
We aggressively look at this when new products are
coming into the network - realizing that sometimes
there’s no way to detect it but it’s a question we
ask, tests that we run, and hope that our confidence
in this being possible is low.

On Nov 13, 2016, at 11:59 AM, Ken Hohhof
mailto:af...@kwisp.com>> wrote:
Yep. There are legitimate needs for the factory
to have a backdoor



--
Simon Westlake
Skype: Simon_Sonar
Email:simon@sonar.software 
Phone: (702) 447-1247
---
Sonar Software Inc
The future of ISP billing and OSS
https://sonar.software 


--
Simon Westlake
Skype: Simon_Sonar
Email:simon@sonar.sof

Re: [AFMUG] Trango Security Issue

[Paul Stewart]

Agree 110% … 

It does suck re: having to climb a tower to reset a password but would also 
think that folks might suddenly be inclined to keep better track of passwords 
after having to do so a couple of times ;)


> On Nov 14, 2016, at 10:52 AM, Simon Westlake  wrote:
> 
> You may not be the only one to make that assumption, but I find it hard to 
> throw my hands up and say 'Oh well' to a hard coded, fixed password root 
> account that is publicly accessible on any kind of device.
> 
> On 11/14/2016 9:44 AM, Ken Hohhof wrote:
>> I think in some cases this means climbing the tower with a laptop and a 
>> serial cable though.
>>  
>> Am I the only one who assumes everything has one or more backdoors, 
>> including my car?  There’s the one the manufacturer knows about, the one the 
>> NSA put there, the one the software engineer put there and didn’t tell his 
>> boss about, the one the Chinese chip maker put there, the one Fancy Bear put 
>> there …
>>  
>>   <>
>> From: Af [mailto:af-boun...@afmug.com ] On 
>> Behalf Of Simon Westlake
>> Sent: Monday, November 14, 2016 9:11 AM
>> To: af@afmug.com 
>> Subject: Re: [AFMUG] Trango Security Issue
>>  
>> There's no reason for it to be secret, either. If it exists purely to assist 
>> customers who forgot their password, then there is no reason to both 
>> disclose it, and offer the user the ability to turn it off. As long as there 
>> is still a physical reset method, then any fallout from forgetting a 
>> password ends up on the customer, if they disabled the ability for it to be 
>> reset.
>> 
>> Let's just imagine right now that someone has already built a bot that is 
>> going out, scanning for Trango radios, and modifying the running code on 
>> them. You can argue that some fault lies with the operator for not properly 
>> securing his/her network, but the root cause of the problem is an insecure, 
>> root account, hard coded into a radio, with a fixed password, that cannot be 
>> disabled.
>> 
>> On 11/13/2016 5:12 PM, Paul Stewart wrote:
>> True and now it’s been disclosed by a security researcher and this blows up 
>> badly on the vendor in my opinion….   makes you wonder what else they are 
>> doing in their software that they are not telling you about - just an 
>> example and not suggesting there’s more in this case  
>>  
>>  
>> On Nov 13, 2016, at 5:51 PM, Ken Hohhof > > wrote:
>>  
>> Well, it’s not a secret backdoor if you disclose it.
>>  
>> “You ever flashy thinged me?”
>> “No.”
>> “I ain’t playing with you, K, you ever flashy thinged me”?
>> “No.”
>>  
>> From: Af [mailto:af-boun...@afmug.com ] On 
>> Behalf Of Paul Stewart
>> Sent: Sunday, November 13, 2016 3:56 PM
>> To: af@afmug.com 
>> Subject: Re: [AFMUG] Trango Security Issue
>>  
>> Different people deploy them different ways … good or bad …
>>  
>> The biggest problem I have with this is when a vendor doesn’t disclose this 
>> information and that a customer cannot choose to remove this option if the 
>> vendor insists on putting it in place.  
>>  
>>  
>> On Nov 13, 2016, at 4:35 PM, George Skorup > > wrote:
>>  
>> I don't exactly see the problem, especially with a PTP radio that should 
>> only be accessible from within your network and possibly only from 
>> management subnets/VLANs, too. If it's a public facing piece of equipment 
>> like a router, then sure, I agree.
>> 
>> On 11/13/2016 3:07 PM, Paul Stewart wrote:
>> Totally disagree with this… we would never let a vendor into our network if 
>> there was a possibility of this.  It puts our network at risk from their 
>> stupidity …. 
>>  
>> We aggressively look at this when new products are coming into the network - 
>> realizing that sometimes there’s no way to detect it but it’s a question we 
>> ask, tests that we run, and hope that our confidence in this being possible 
>> is low.
>>  
>>  
>> On Nov 13, 2016, at 11:59 AM, Ken Hohhof > > wrote:
>>  
>> Yep.  There are legitimate needs for the factory to have a backdoor
>>  
>> 
>> 
>> -- 
>> Simon Westlake
>> Skype: Simon_Sonar
>> Email: simon@sonar.software 
>> Phone: (702) 447-1247
>> ---
>> Sonar Software Inc
>> The future of ISP billing and OSS
>> https://sonar.software 
> -- 
> Simon Westlake
> Skype: Simon_Sonar
> Email: simon@sonar.software 
> Phone: (702) 447-1247
> ---
> Sonar Software Inc
> The future of ISP billing and OSS
> https://sonar.software 

Re: [AFMUG] Trango Security Issue

[Simon Westlake]

You may not be the only one to make that assumption, but I find it hard 
to throw my hands up and say 'Oh well' to a hard coded, fixed password 
root account that is publicly accessible on any kind of device.


On 11/14/2016 9:44 AM, Ken Hohhof wrote:


I think in some cases this means climbing the tower with a laptop and 
a serial cable though.


Am I the only one who assumes everything has one or more backdoors, 
including my car?  There’s the one the manufacturer knows about, the 
one the NSA put there, the one the software engineer put there and 
didn’t tell his boss about, the one the Chinese chip maker put there, 
the one Fancy Bear put there …


*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Simon Westlake
*Sent:* Monday, November 14, 2016 9:11 AM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] Trango Security Issue

There's no reason for it to be secret, either. If it exists purely to 
assist customers who forgot their password, then there is no reason to 
both disclose it, and offer the user the ability to turn it off. As 
long as there is still a physical reset method, then any fallout from 
forgetting a password ends up on the customer, if they disabled the 
ability for it to be reset.


Let's just imagine right now that someone has already built a bot that 
is going out, scanning for Trango radios, and modifying the running 
code on them. You can argue that some fault lies with the operator for 
not properly securing his/her network, but the root cause of the 
problem is an insecure, root account, hard coded into a radio, with a 
fixed password, that cannot be disabled.


On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher and this
blows up badly on the vendor in my opinion….   makes you wonder
what else they are doing in their software that they are not
telling you about - just an example and not suggesting there’s
more in this case

On Nov 13, 2016, at 5:51 PM, Ken Hohhof mailto:af...@kwisp.com>> wrote:

Well, it’s not a secret backdoor if you disclose it.

“You ever flashy thinged me?”

“No.”

“I ain’t playing with you, K, you ever flashy thinged me”?

“No.”

*From:*Af [mailto:af-boun...@afmug.com]*On Behalf Of*Paul Stewart
*Sent:*Sunday, November 13, 2016 3:56 PM
*To:*af@afmug.com 
*Subject:*Re: [AFMUG] Trango Security Issue

Different people deploy them different ways … good or bad …

The biggest problem I have with this is when a vendor doesn’t
disclose this information and that a customer cannot choose to
remove this option if the vendor insists on putting it in place.

On Nov 13, 2016, at 4:35 PM, George Skorup
mailto:geo...@cbcast.com>> wrote:

I don't exactly see the problem, especially with a PTP
radio that should only be accessible from within your
network and possibly only from management subnets/VLANs,
too. If it's a public facing piece of equipment like a
router, then sure, I agree.

On 11/13/2016 3:07 PM, Paul Stewart wrote:

Totally disagree with this… we would never let a
vendor into our network if there was a possibility of
this.  It puts our network at risk from their stupidity ….

We aggressively look at this when new products are
coming into the network - realizing that sometimes
there’s no way to detect it but it’s a question we
ask, tests that we run, and hope that our confidence
in this being possible is low.

On Nov 13, 2016, at 11:59 AM, Ken Hohhof
mailto:af...@kwisp.com>> wrote:

Yep. There are legitimate needs for the factory to
have a backdoor



--
Simon Westlake
Skype: Simon_Sonar
Email:simon@sonar.software 
Phone: (702) 447-1247
---
Sonar Software Inc
The future of ISP billing and OSS
https://sonar.software


--
Simon Westlake
Skype: Simon_Sonar
Email: simon@sonar.software
Phone: (702) 447-1247
---
Sonar Software Inc
The future of ISP billing and OSS
https://sonar.software

Re: [AFMUG] Trango Security Issue

[Ken Hohhof]

I think in some cases this means climbing the tower with a laptop and a serial 
cable though.

 

Am I the only one who assumes everything has one or more backdoors, including 
my car?  There’s the one the manufacturer knows about, the one the NSA put 
there, the one the software engineer put there and didn’t tell his boss about, 
the one the Chinese chip maker put there, the one Fancy Bear put there …

 

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Simon Westlake
Sent: Monday, November 14, 2016 9:11 AM
To: af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue

 

There's no reason for it to be secret, either. If it exists purely to assist 
customers who forgot their password, then there is no reason to both disclose 
it, and offer the user the ability to turn it off. As long as there is still a 
physical reset method, then any fallout from forgetting a password ends up on 
the customer, if they disabled the ability for it to be reset.

Let's just imagine right now that someone has already built a bot that is going 
out, scanning for Trango radios, and modifying the running code on them. You 
can argue that some fault lies with the operator for not properly securing 
his/her network, but the root cause of the problem is an insecure, root 
account, hard coded into a radio, with a fixed password, that cannot be 
disabled.

On 11/13/2016 5:12 PM, Paul Stewart wrote:

True and now it’s been disclosed by a security researcher and this blows up 
badly on the vendor in my opinion….   makes you wonder what else they are doing 
in their software that they are not telling you about - just an example and not 
suggesting there’s more in this case  

 

 

On Nov 13, 2016, at 5:51 PM, Ken Hohhof mailto:af...@kwisp.com> > wrote:

 

Well, it’s not a secret backdoor if you disclose it.

 

“You ever flashy thinged me?”

“No.”

“I ain’t playing with you, K, you ever flashy thinged me”?

“No.”

 

From: Af [  mailto:af-boun...@afmug.com] On Behalf 
Of Paul Stewart
Sent: Sunday, November 13, 2016 3:56 PM
To:   af@afmug.com
Subject: Re: [AFMUG] Trango Security Issue

 

Different people deploy them different ways … good or bad …

 

The biggest problem I have with this is when a vendor doesn’t disclose this 
information and that a customer cannot choose to remove this option if the 
vendor insists on putting it in place.  

 

 

On Nov 13, 2016, at 4:35 PM, George Skorup <  
geo...@cbcast.com> wrote:

 

I don't exactly see the problem, especially with a PTP radio that should only 
be accessible from within your network and possibly only from management 
subnets/VLANs, too. If it's a public facing piece of equipment like a router, 
then sure, I agree.

On 11/13/2016 3:07 PM, Paul Stewart wrote:

Totally disagree with this… we would never let a vendor into our network if 
there was a possibility of this.  It puts our network at risk from their 
stupidity …. 

 

We aggressively look at this when new products are coming into the network - 
realizing that sometimes there’s no way to detect it but it’s a question we 
ask, tests that we run, and hope that our confidence in this being possible is 
low.

 

 

On Nov 13, 2016, at 11:59 AM, Ken Hohhof <  
af...@kwisp.com> wrote:

 

Yep.  There are legitimate needs for the factory to have a backdoor

 





-- 
Simon Westlake
Skype: Simon_Sonar
Email: simon@sonar.software  
Phone: (702) 447-1247
---
Sonar Software Inc
The future of ISP billing and OSS
https://sonar.software

Re: [AFMUG] ubnt devices intermittantly stop responding to pings

[Jay Weekley]

I was thinking I had some catching up to do.

Jeremy wrote:

bah...wrong thread.

On Mon, Nov 14, 2016 at 8:09 AM, Jeremy > wrote:


So is there a new Trango firmware that changes it to something
more secure (like p@$$word)?

On Mon, Nov 14, 2016 at 7:54 AM, Jay Weekley
mailto:par...@cyberbroadband.net>> wrote:

Yeah, I think we have a radio that is doing that as well. 
Power Code reports it down but we log into it just fine.


Jeremy wrote:

I have seen M series do this under heavy load.  I usually
take it as an indicator that it is time for an upgrade. Is
it an AP or a BH?  Are there more than 30 clients on it? 
If it is a backhaul, how much bandwidth is it pushing at

peak time?  Is it at peak time when the pings start dropping?

On Mon, Nov 14, 2016 at 1:46 AM, TJ Trout mailto:t...@voltbb.com> >> wrote:

Yes, Yes.

Sometimes the radios reboot from watchdog when the
host they are
testing against has not been down :(

On Mon, Nov 14, 2016 at 12:21 AM, Timothy Steele
mailto:timothy.pct...@gmail.com>
>> wrote:

Are you can the latest firmware? Do you have ping
watchdog
running inside the radios firmware ?


On Mon, Nov 14, 2016, 2:21 AM TJ Trout
mailto:t...@voltbb.com>
>> wrote:

I did a little searching on the forum and I
can't see to
find anyone who has ran into this issue, I'm
noticing that
many of my ubnt devices will randomly stop
responding to
pings but the web ui and radio keep passing
traffic
normally? within an hour the radio will start
responding
to pings again like it never even happened...
No power
cycling or any intervention required.

Re: [AFMUG] Trango Security Issue

[Simon Westlake]

There's no reason for it to be secret, either. If it exists purely to 
assist customers who forgot their password, then there is no reason to 
both disclose it, and offer the user the ability to turn it off. As long 
as there is still a physical reset method, then any fallout from 
forgetting a password ends up on the customer, if they disabled the 
ability for it to be reset.


Let's just imagine right now that someone has already built a bot that 
is going out, scanning for Trango radios, and modifying the running code 
on them. You can argue that some fault lies with the operator for not 
properly securing his/her network, but the root cause of the problem is 
an insecure, root account, hard coded into a radio, with a fixed 
password, that cannot be disabled.


On 11/13/2016 5:12 PM, Paul Stewart wrote:
True and now it’s been disclosed by a security researcher and this 
blows up badly on the vendor in my opinion….   makes you wonder what 
else they are doing in their software that they are not telling you 
about - just an example and not suggesting there’s more in this case



On Nov 13, 2016, at 5:51 PM, Ken Hohhof > wrote:


Well, it’s not a secret backdoor if you disclose it.
“You ever flashy thinged me?”
“No.”
“I ain’t playing with you, K, you ever flashy thinged me”?
“No.”
*From:*Af [mailto:af-boun...@afmug.com]*On Behalf Of*Paul Stewart
*Sent:*Sunday, November 13, 2016 3:56 PM
*To:*af@afmug.com 
*Subject:*Re: [AFMUG] Trango Security Issue
Different people deploy them different ways … good or bad …
The biggest problem I have with this is when a vendor doesn’t 
disclose this information and that a customer cannot choose to remove 
this option if the vendor insists on putting it in place.
On Nov 13, 2016, at 4:35 PM, George Skorup > wrote:


I don't exactly see the problem, especially with a PTP radio that 
should only be accessible from within your network and possibly only 
from management subnets/VLANs, too. If it's a public facing piece of 
equipment like a router, then sure, I agree.


On 11/13/2016 3:07 PM, Paul Stewart wrote:
Totally disagree with this… we would never let a vendor into our 
network if there was a possibility of this.  It puts our network at 
risk from their stupidity ….
We aggressively look at this when new products are coming into the 
network - realizing that sometimes there’s no way to detect it but 
it’s a question we ask, tests that we run, and hope that our 
confidence in this being possible is low.
On Nov 13, 2016, at 11:59 AM, Ken Hohhof > wrote:

Yep. There are legitimate needs for the factory to have a backdoor




--
Simon Westlake
Skype: Simon_Sonar
Email: simon@sonar.software
Phone: (702) 447-1247
---
Sonar Software Inc
The future of ISP billing and OSS
https://sonar.software

Re: [AFMUG] ubnt devices intermittantly stop responding to pings

[Jeremy]

bah...wrong thread.

On Mon, Nov 14, 2016 at 8:09 AM, Jeremy  wrote:

> So is there a new Trango firmware that changes it to something more secure
> (like p@$$word)?
>
> On Mon, Nov 14, 2016 at 7:54 AM, Jay Weekley 
> wrote:
>
>> Yeah, I think we have a radio that is doing that as well.  Power Code
>> reports it down but we log into it just fine.
>>
>> Jeremy wrote:
>>
>>> I have seen M series do this under heavy load.  I usually take it as an
>>> indicator that it is time for an upgrade. Is it an AP or a BH?  Are there
>>> more than 30 clients on it?  If it is a backhaul, how much bandwidth is it
>>> pushing at peak time?  Is it at peak time when the pings start dropping?
>>>
>>> On Mon, Nov 14, 2016 at 1:46 AM, TJ Trout >> t...@voltbb.com>> wrote:
>>>
>>> Yes, Yes.
>>>
>>> Sometimes the radios reboot from watchdog when the host they are
>>> testing against has not been down :(
>>>
>>> On Mon, Nov 14, 2016 at 12:21 AM, Timothy Steele
>>> mailto:timothy.pct...@gmail.com>> wrote:
>>>
>>> Are you can the latest firmware? Do you have ping watchdog
>>> running inside the radios firmware ?
>>>
>>>
>>> On Mon, Nov 14, 2016, 2:21 AM TJ Trout >> > wrote:
>>>
>>> I did a little searching on the forum and I can't see to
>>> find anyone who has ran into this issue, I'm noticing that
>>> many of my ubnt devices will randomly stop responding to
>>> pings but the web ui and radio keep passing traffic
>>> normally? within an hour the radio will start responding
>>> to pings again like it never even happened... No power
>>> cycling or any intervention required.
>>>
>>>
>>>
>>>
>>>
>>
>

Re: [AFMUG] ubnt devices intermittantly stop responding to pings

[Jeremy]

So is there a new Trango firmware that changes it to something more secure
(like p@$$word)?

On Mon, Nov 14, 2016 at 7:54 AM, Jay Weekley 
wrote:

> Yeah, I think we have a radio that is doing that as well.  Power Code
> reports it down but we log into it just fine.
>
> Jeremy wrote:
>
>> I have seen M series do this under heavy load.  I usually take it as an
>> indicator that it is time for an upgrade. Is it an AP or a BH?  Are there
>> more than 30 clients on it?  If it is a backhaul, how much bandwidth is it
>> pushing at peak time?  Is it at peak time when the pings start dropping?
>>
>> On Mon, Nov 14, 2016 at 1:46 AM, TJ Trout > t...@voltbb.com>> wrote:
>>
>> Yes, Yes.
>>
>> Sometimes the radios reboot from watchdog when the host they are
>> testing against has not been down :(
>>
>> On Mon, Nov 14, 2016 at 12:21 AM, Timothy Steele
>> mailto:timothy.pct...@gmail.com>> wrote:
>>
>> Are you can the latest firmware? Do you have ping watchdog
>> running inside the radios firmware ?
>>
>>
>> On Mon, Nov 14, 2016, 2:21 AM TJ Trout > > wrote:
>>
>> I did a little searching on the forum and I can't see to
>> find anyone who has ran into this issue, I'm noticing that
>> many of my ubnt devices will randomly stop responding to
>> pings but the web ui and radio keep passing traffic
>> normally? within an hour the radio will start responding
>> to pings again like it never even happened... No power
>> cycling or any intervention required.
>>
>>
>>
>>
>>
>

Re: [AFMUG] ubnt devices intermittantly stop responding to pings

[Jay Weekley]

Yeah, I think we have a radio that is doing that as well.  Power Code 
reports it down but we log into it just fine.


Jeremy wrote:
I have seen M series do this under heavy load.  I usually take it as 
an indicator that it is time for an upgrade. Is it an AP or a BH?  Are 
there more than 30 clients on it?  If it is a backhaul, how much 
bandwidth is it pushing at peak time?  Is it at peak time when the 
pings start dropping?


On Mon, Nov 14, 2016 at 1:46 AM, TJ Trout > wrote:


Yes, Yes.

Sometimes the radios reboot from watchdog when the host they are
testing against has not been down :(

On Mon, Nov 14, 2016 at 12:21 AM, Timothy Steele
mailto:timothy.pct...@gmail.com>> wrote:

Are you can the latest firmware? Do you have ping watchdog
running inside the radios firmware ?


On Mon, Nov 14, 2016, 2:21 AM TJ Trout mailto:t...@voltbb.com>> wrote:

I did a little searching on the forum and I can't see to
find anyone who has ran into this issue, I'm noticing that
many of my ubnt devices will randomly stop responding to
pings but the web ui and radio keep passing traffic
normally? within an hour the radio will start responding
to pings again like it never even happened... No power
cycling or any intervention required.

Re: [AFMUG] ubnt devices intermittantly stop responding to pings

[Jeremy]

I have seen M series do this under heavy load.  I usually take it as an
indicator that it is time for an upgrade.  Is it an AP or a BH?  Are there
more than 30 clients on it?  If it is a backhaul, how much bandwidth is it
pushing at peak time?  Is it at peak time when the pings start dropping?

On Mon, Nov 14, 2016 at 1:46 AM, TJ Trout  wrote:

> Yes, Yes.
>
> Sometimes the radios reboot from watchdog when the host they are testing
> against has not been down :(
>
> On Mon, Nov 14, 2016 at 12:21 AM, Timothy Steele  > wrote:
>
>> Are you can the latest firmware? Do you have ping watchdog running inside
>> the radios firmware ?
>>
>> On Mon, Nov 14, 2016, 2:21 AM TJ Trout  wrote:
>>
>>> I did a little searching on the forum and I can't see to find anyone who
>>> has ran into this issue, I'm noticing that many of my ubnt devices will
>>> randomly stop responding to pings but the web ui and radio keep passing
>>> traffic normally? within an hour the radio will start responding to pings
>>> again like it never even happened... No power cycling or any intervention
>>> required.
>>>
>>>
>>>
>

Re: [AFMUG] Site monitor relay temp

[Forrest Christian (List Account)]

There was a bug we fixed in relation to this.I need to look at my
revision notes to determine when this took place,  and verify that the
updated software made it to the Web page.

Unfortunately my connectivity where I an for most of this week apparently
blocks VPN access for me and as such I don't have access to this at this
data point.

On Nov 13, 2016 7:55 PM, "TJ Trout"  wrote:

> I just updated a site monitor and now it won't turn the relay on with
> temp, my "relay on above" is set to 450 and my current temp reading is 550
> , I was able to manually turn the relay on is there something on the binary
> page that needs to be set? Or is this function broken on the lastest
> firmware?
>

Re: [AFMUG] ubnt devices intermittantly stop responding to pings

[TJ Trout]

Yes, Yes.

Sometimes the radios reboot from watchdog when the host they are testing
against has not been down :(

On Mon, Nov 14, 2016 at 12:21 AM, Timothy Steele 
wrote:

> Are you can the latest firmware? Do you have ping watchdog running inside
> the radios firmware ?
>
> On Mon, Nov 14, 2016, 2:21 AM TJ Trout  wrote:
>
>> I did a little searching on the forum and I can't see to find anyone who
>> has ran into this issue, I'm noticing that many of my ubnt devices will
>> randomly stop responding to pings but the web ui and radio keep passing
>> traffic normally? within an hour the radio will start responding to pings
>> again like it never even happened... No power cycling or any intervention
>> required.
>>
>>
>>

Re: [AFMUG] ubnt devices intermittantly stop responding to pings

[Timothy Steele]

Are you can the latest firmware? Do you have ping watchdog running inside
the radios firmware ?

On Mon, Nov 14, 2016, 2:21 AM TJ Trout  wrote:

> I did a little searching on the forum and I can't see to find anyone who
> has ran into this issue, I'm noticing that many of my ubnt devices will
> randomly stop responding to pings but the web ui and radio keep passing
> traffic normally? within an hour the radio will start responding to pings
> again like it never even happened... No power cycling or any intervention
> required.
>
>
>