Sierra Wireless should pay you a consulting fee to help them fix this problem.
At a minimum, let you have a copy of the source code.
From: AF On Behalf Of Forrest Christian (List Account)
Sent: Thursday, January 2, 2020 7:58 PM
To: AnimalFarm Microwave Users Group
Subject: Re: [AFMUG] mass
Two years ago I sold some GPS repeaters to Delphi engineering department in
Chihuahua to test these...I got them from England and shipped directly to
them.
On Thu, Jan 2, 2020, 1:52 PM Nate Burke wrote:
> Anyone else use the Delphi Modules for vehicle tracking (and local 4G
> Hotspot)? It was
Hell, the Internet will probably be obsolete by then, replaced by quantum
entanglement, cranial implants, teleportation, and where are our flying cars?
Wasn’t Blade Runner set in 2019 Los Angeles? And didn’t Doc and Marty travel
to future 2015 in the DeLorean time machine?
From: AF On
Maybe most likely we have 4 years to forget about it.
bp
On 1/2/2020 5:30 PM, Ken Hohhof wrote:
The crucial question seems to be, do we
mark our calendars for 4 years from now, midnight Moscow time,
All of the affected modules should be able to be flashed. Whether or not
the facility is in place to do so depends a lot on the design choices
made. I purposefully have ensured that there is some way to update
firmware in the field for all of these modules, with varying levels of
pain. I'm
ePMP has had firmware updates for the GPS module in the past, so they
certainly have that capability.
On Thu, Jan 2, 2020 at 7:31 PM Ken Hohhof wrote:
> The crucial question seems to be, do we mark our calendars for 4 years
> from now, midnight Moscow time, New Years Eve 2023? So we can power
Who could think 2” was a good idea? Oh, and let’s hide a key under the welcome
mat.
From: AF On Behalf Of Mike Hammett
Sent: Thursday, January 2, 2020 7:13 PM
To: AnimalFarm Microwave Users Group
Subject: Re: [AFMUG] This Question Again
Well, they did different levels. The Louisville
The crucial question seems to be, do we mark our calendars for 4 years from
now, midnight Moscow time, New Years Eve 2023? So we can power cycle a bunch
of GPS receivers?
Or is there some kind of retroactive fix that can be applied?
Or do we have 4 years to physically replace the
Well, they did different levels. The Louisville ones were nanotrenches at
around 2" deep. Austin was maybe microtrenches at 4" and has stood the test of
time better. Then again, frost and plow trucks aren't really a thing in Texas.
-
Mike Hammett
Intelligent Computing Solutions
Yes, and it happens a lot apparently. I.E. it looked weird, but it wasn't.
On Thu, Jan 2, 2020 at 6:05 PM Mike Hammett wrote:
> Was the weird clock update from GPS PRN 29 sent about 20 minutes before
> midnight Moscow time just coincidence?
>
>
>
> -
> Mike Hammett
> Intelligent
Was the weird clock update from GPS PRN 29 sent about 20 minutes before
midnight Moscow time just coincidence?
-
Mike Hammett
Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
- Original Message -
From: "Forrest Christian (List Account)"
For us, we have only been shipping GPS+GLONASS since late in 2017 or 2018,
so this is the first GLONASS rollover for us.Remember this is still
speculation here, but I am starting to feel like this most likely will turn
out to be the underlying cause.
All of us with the issue seem to be
Its more, the things that people break due to turning it on vs doing a better
method. Just my two cents.
Dennis Burgess, Mikrotik Certified Trainer
MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE, MTCSE, HE IPv6 Sage, Cambium ePMP
Certified
Author of "Learn RouterOS- Second Edition”
Link
Most of the time you are trying to solve the issue (distributing a subnet)
incorrectly by distributing the connected routes. Not stating that you can't
do it, but 99% of the time there is a better way without the "gotchas" that
come with that..
1. Customer distributing connected routes.
I’m not sure it’s true that only Cambium products were affected. It appears to
be more a certain 3rd party GPS+GLONASS receiver module that Packetflux uses in
their latest production of Syncboxes and that Cambium apparently uses in their
latest UGPS production. Are Packetflux sync products
So why didn’t this happen four years ago? And why were only Cambium type
products affected?
> On Jan 2, 2020, at 6:13 PM, Forrest Christian (List Account)
> wrote:
>
> The answer to your question is complicated. The short answer is that not in
> the way you stated it, as there isn't good
The answer to your question is complicated. The short answer is that not
in the way you stated it, as there isn't good enough clock hardware in the
rackinjector to do this holdover, and the current electrical architecture
isn't set up to permit the generation of a clock internally. We're
So I've pieced together some facts which may actually lead to the actual
cause
1) As Caleb pointed out 21:00 is actually 0:00 in moscow time.
2) Based on the above I went digging. The GLONASS time scale is actually
based on moscow time. So the end of the year is 21:00UTC according to the
A great feature would be for the RackInjector to generate it's own
hold-over sync if it were to loose GPS. Any possibility of including
something like that in the next firmware update?
On Tue, Dec 31, 2019 at 8:45 PM Forrest Christian (List Account) <
li...@packetflux.com> wrote:
> One note is
The only reason I can think of, is that you have to be careful if you assign an
IP address like 192.168.88.1 or 169.254.1.x to an interface for maybe
administrative purposes, if that interface ever becomes active, and you don't
have a route filter, then the router will advertise that block via
i think the syncpipes are
On Thu, Jan 2, 2020 at 4:41 PM Ken Hohhof wrote:
> 450 APs do some illogical things when choosing among available sync
> sources – internal, power port, timing port. Of course on 450i/450m,
> internal is not an option. But sometimes we have to telnet to an AP and
>
450 APs do some illogical things when choosing among available sync sources –
internal, power port, timing port. Of course on 450i/450m, internal is not an
option. But sometimes we have to telnet to an AP and disable/enable internal
in order to get it to switch back to power or timing port.
Someone(or a coordinated group) probably deployed a bunch of
these things.
https://gizmodo.com/jamming-gps-signals-is-illegal-dangerous-cheap-and-e-1796778955
bp
On 1/2/2020 2:02 PM, Steve Jones wrote:
Did the root issue ever get defined?
Did the root issue ever get defined?
I still have my money on Huawei testing the Baicells botnet, building up a
set of GPS transmitters out of the Recievers and impacting the Stateside
GPS. they tested the timing pulse in a fashion that only impacts timing,
not positioning amongst a test group
NEVER redistribute connected... bad bad bad .
The sub area you can announce out the /25 or whatever it is, but keep /32s from
leaving the stub area. Your OSPF-out filters do not work inner area, i.e.
between backbone and backbone routers, only intra-area, that means area 44
(stub) it will
Yeah, those are the only two ways to do it using only OSPF:
1. Route Filters
2. OSPF non-backbone area with PPPoE network in that area and an
area-range set (to aggregate)
Jesse DuPont
Network Architect
Anyone else use the Delphi Modules for vehicle tracking (and local 4G
Hotspot)? It was just an additional $5/month on our verizon bill. The
Website we went to mycar.delphi.com just comes up with a 'Discontinued
service' message.
It seems the main page, http://delphiconnect.com/ is still
It’s not that complex, unless I’m missing something.
On Cisco routers we route the x.x.x.x/24 (or whatever netblock is assigned to
that PPPoE NAS) to Null0.
On Mikrotik we use add a route filter to chain ospf-out with matcher parameters
prefix=x.x.x.x/24 and prefix length=32, with
Correct, they were pushed to go faster because as each permit was pulled,
AT strung fiber on the pole and beat them to the punch.
Go faster Google said...so the contractor had to go more shallow. When the
roads were resurfaced, some had already been over paved to the point the
curb was even to
Good point.
On 1/2/2020 1:22 PM, Jesse DuPont wrote:
How are you getting around it doing a /32 for each PPPoE session right
now? Even if you don't do redistribute connected, but have the whole,
let's say, /24 in OSPF-Networks, there will be an entry for each /32
in all the route tables
How are you getting around it doing a /32 for each PPPoE session
right now? Even if you don't do redistribute connected, but have the
whole, let's say, /24 in OSPF-Networks, there will be an entry for
each /32 in all the route tables regardless because OSPF uses the
mask
I don't really see why... you could also just filter out the /32's if you
needed to redistribute connected routes for some other reason (like if you
have statically assigned PPPoE IPs that aren't in the main pool), which is
what I do (although I distribute the PPPoE IPs via iBGP instead of OSPF,
I was told the epoxy additive was about 30 bucks a gallon and that was
what pushed the cost overboard and that was allegedly why you don't see
much microtrenching above a certain latitude.
again, hearsay.
On 1/2/2020 1:08 PM, ch...@wbmfg.com wrote:
If I remember to look when I get back,
If you redistribute connected routes on a PPPoE server you get a route
for every /32 and that's undesirable.
My solution currently is to NOT redistribute connected and instead just
advertise the larger network which will encompass all the /32's.
I read a presentation suggesting to use an
If I remember to look when I get back, the contactor that quoted us made a
video. I think they put it up a state highway at 18”. The flow fill machine
was right behind it and then some kind of rubber cap was put in right after
that.
From: Adam Moffett
Sent: Thursday, January 2, 2020 7:42
I heard Google's microtrenches were only a few inches deep. If they got
it down to 10" then road resurfacing shouldn't be an issue. The same
source told me Google didn't use the proper backfill. The story was
that the flowable fill needs an epoxy additive when the microtrench is
above the
Don't microtrench if you can avoid it. Road resurfacing and cuts for other
utilities makes this a hassle. Google abandoned their entire microtrenched
plant in Louisville after the resurfacing projects, or aging infrastructure
repairs caused so many outages.
On Wed, Jan 1, 2020 at 12:16 PM
We have found that we had to reboot some 450AP after the event in addition to
restrating the GPS.
Internet.
Phone.
TV.
Andreas Wiatowski
CEO/Founder
Silo
1-866-727-4138, ext 600 |
andr...@silo.ca
silo.ca
From: AF on behalf of Nate Burke
Reply-To: AnimalFarm Microwave Users Group
Date:
On the west coast, seems like nothing happened.
bp
On 1/2/2020 8:26 AM, Nate Burke wrote:
I must have been one of the lucky one's, I never lost all
satellites. My EPMP 1k,2k,3k radios just reduced the number of
tracked
I must have been one of the lucky one's, I never lost all satellites.
My EPMP 1k,2k,3k radios just reduced the number of tracked satellites.
(after completely losing all satellites for about 15 min at 21:00 on
12/31) at 21:00 1/1 they all returned to normal number of satellites
tracked. I
It all started 12/31/19 at 21:00 UTC. You're saying yours all suddenly
came back on 1/1/20 at 21:00 UTC? Nice little exact 24hr window.
Oddly enough 21:00 UTC is midnight in Moscow.
On Wed, Jan 1, 2020 at 10:18 PM Nate Burke wrote:
>
> No user intervention on my part.
>
> Visible satellites
OK, within 24 hours I had power cycled all the affected GPS receivers, but it
was not my impression the problem was resolving itself without intervention. I
had 2 sites that I had failed to connect up the remote access so I had to go to
the site, but the last one was just under the 24 hour
42 matches
Mail list logo
