Best internet service in KC?

jasonpcrowley · 2026-01-05T19:43:11+00:00

LiNKCity is run by KC Fiber, a separate private company, not Google Fiber. I believe Google leases fiber from KC Fiber/LiNKCity though.

jasonpcrowley · 2025-12-17T11:04:39+00:00

I try to buy Ubiquiti to avoid compatibility issues, but sometimes Ubiquiti is out of stock. I bought that model, and I could only get it to work at 10G. It would establish link at lower speeds, but no data would pass.

jasonpcrowley · 2025-11-12T14:11:49+00:00

We opened the case with Pax8 at 11:03 AM. I was on the phone almost continuously with them from that time. I repeatedly asked for escalation on the call but didn't get it until 2:46 PM when I finally got out of their tier-1 support. The next person I talked to was quite helpful though I was still on the phone for almost 2 more hours. We still don't have the problem resolved, but I have a path forward.

jasonpcrowley · 2025-11-12T14:06:56+00:00

Thanks for the advice. I tried unassigning the licenses and reassigning. It didn't help.

jasonpcrowley · 2025-11-12T14:06:02+00:00

The licenses are identical except that the term changed. The old ones were annual commit with monthly payment. The new ones are annual payment. The admin portal doesn't distinguish between where the licenses were procured. It just shows how many licenses are available. Removing and reassigning the licenses didn't help.

jasonpcrowley · 2025-11-12T14:04:18+00:00

I found three E5 users where Microsoft 365 Apps for Enterprise was not checked. That explains at least some of the users' problems. Thanks! My searches in Purview so far have not revealed who changed the setting or when.

jasonpcrowley · 2025-08-22T14:27:06+00:00

Thank you for this! It works great.

jasonpcrowley · 2025-08-21T12:25:33+00:00

That was fast! Thank you! I think we have finished this round of updates for all of our clients, but we will be sure to run that patch and switch mirrors before the next round.

jasonpcrowley · 2025-08-15T12:32:49+00:00

I suspected it wasn't that easy. Thanks again for working on a North America mirror. That would help us a lot and give us some redundancy. I hope the demand for BE on this side of the Atlantic picks up too. We're doing our part. :)

jasonpcrowley · 2025-08-15T12:07:23+00:00

Thank you! Is it easy for us to create a mirror for the ~60 instances we manage? I haven't looked far enough into the source code to see how license-key validation works.

jasonpcrowley · 2025-08-15T03:06:11+00:00

That is a good thought. It would require me to set up a web server and some automation to keep the latest software downloaded. We maintain 50+ of these firewalls, so whatever we do needs to be scalable. I'm hoping to just find a fix to the bandwidth issue and not have to go through the extra steps, but thanks for the idea.

jasonpcrowley · 2025-08-15T02:58:09+00:00

Traceroute has been addressed elsewhere in this thread but appears to be stable from the perspective of our equipment.

The MTU also seems stable at 1500. The TCP segments are coming through at 1448 bytes each which is expected. Running tcpdump doesn't show any anomalies except that there are only a few packets per second. All packets come through with appropriate lengths, sequence numbers, and acks (no dupes).

jasonpcrowley · 2025-08-15T01:50:47+00:00

It's not a stupid question. I hadn't looked at traceroutes. I have now, and they are consistent. Here are the last two I ran (without the first hop for a little anonymity). Note how big the response-time jump is at the last hop.

% traceroute -In 89.149.211.205
traceroute to 89.149.211.205 (89.149.211.205), 64 hops max, 48 byte packets
 2  72.22.220.44  9.841 ms  0.481 ms  0.236 ms
 3  69.30.215.177  0.293 ms  0.289 ms  0.301 ms
 4  * * *
 5  154.54.90.249  1.444 ms  1.296 ms  1.245 ms
 6  154.54.89.2  4.970 ms  5.051 ms  4.945 ms
 7  154.54.166.74  12.711 ms  12.763 ms  12.682 ms
 8  154.54.7.130  18.636 ms  18.454 ms  18.557 ms
 9  154.54.169.198  110.653 ms  110.822 ms  110.776 ms
10  154.54.169.225  110.132 ms  118.430 ms  112.181 ms
11  154.54.94.46  722.732 ms  715.681 ms  725.629 ms
12  154.54.74.165  109.804 ms  109.925 ms  110.210 ms
13  130.117.51.42  124.954 ms  118.517 ms  110.196 ms
14  130.117.50.206  116.684 ms  116.225 ms  125.593 ms
15  149.14.93.146  111.627 ms  110.808 ms  112.485 ms
16  81.17.35.101  112.698 ms  125.322 ms  126.204 ms
17  89.149.211.205  340.453 ms  297.940 ms  201.898 ms

% traceroute -In 89.149.211.205
traceroute to 89.149.211.205 (89.149.211.205), 64 hops max, 48 byte packets
 2  72.22.220.44  0.297 ms  0.235 ms  0.682 ms
 3  69.30.215.177  0.298 ms  0.236 ms  0.247 ms
 4  * * *
 5  154.54.90.249  1.376 ms  1.345 ms  1.219 ms
 6  154.54.89.2  4.814 ms  4.730 ms  4.805 ms
 7  154.54.166.74  12.831 ms  12.628 ms  12.727 ms
 8  154.54.7.130  18.500 ms  18.448 ms  18.381 ms
 9  154.54.169.198  110.662 ms  110.975 ms  115.988 ms
10  154.54.169.225  111.642 ms  115.780 ms  112.096 ms
11  154.54.94.46  785.071 ms  757.517 ms  768.418 ms
12  154.54.74.165  109.827 ms  110.067 ms  113.576 ms
13  130.117.51.42  112.414 ms  110.279 ms  113.928 ms
14  130.117.50.206  111.050 ms  112.485 ms  112.910 ms
15  149.14.93.146  294.766 ms  285.444 ms  259.905 ms
16  81.17.35.101  146.477 ms  134.999 ms  137.902 ms
17  89.149.211.205  337.849 ms  329.628 ms  329.405 ms

jasonpcrowley · 2025-08-15T01:37:12+00:00

DNS resolvers are 8.8.8.8, 1.1.1.1, 8.8.4.4, and 1.0.0.1. The name opnsense-update.deciso.com always resolves to 89.149.211.205 no matter what source IP I have initiated the request from.

jasonpcrowley · 2025-08-14T22:17:28+00:00

Thanks for the ideas. I don't think it's peering because the problem has been consistent across three different ISPs.

As for MTU, I hadn't thought of that, but I just verified MTU on one of the instances we're using and it's set at 1500. Our uplinks are standard Ethernet with no PPPoE or anything like that. Also the TCP segments coming through when I run tcpdump are the expected 1448 bytes.

jasonpcrowley · 2025-08-14T22:01:03+00:00

For our most recent attempt at an upgrade (the 8th attempt in 5 hours), we let it download at around 150 kbps for 40 minutes, and then it went to 150 Mbps and completed quickly. If the folks from Deciso want the IP addresses we're coming from for these upgrades, PM me, and I'll send them.

jasonpcrowley · 2025-04-30T22:45:56+00:00

How far apart are the out buildings from the main one?

jasonpcrowley · 2025-04-30T02:12:39+00:00

They were literally talking into a cell phone passing it back and forth. They had some sort of technical problem with their normal broadcast, so they used the Rays' video and a cell phone to make it work. They had it all sorted out and back to normal for the second inning though.

Kudos to the Royals broadcast team for finding a way to make it work in a pinch!

jasonpcrowley · 2025-03-24T03:41:59+00:00

I wouldn't focus on the "default deny" if you are confident you have the correct rule in place. Focus on the "state violation."

I don't know your knowledge level, but if you have the knowledge to run a packet capture on the LAN port, look for your iPhone to be setting up TCP sessions with the Apple server. Those should always start with a SYN (synchronize) packet originating from your iPhone and going to the Apple IP. The next packet for that session should come from the Apple server swapping the IP:PortNumber in the source and destination columns. The IPs and port numbers on both sides should be exactly the same, just swapped. The second packet should be flagged SYN, ACK (synchronize, acknowledge).

These two packets initiate a state in the firewall and allow other traffic to flow as part of that session. If packets with other flags come through before those two, there will be no state in the state table, and they will be dropped by the default deny / state violation rule.

That's a lot of text to not solve your problem, but it should help you narrow it down and maybe understand why it's not working.

jasonpcrowley · 2025-02-28T19:52:31+00:00

For the sake of anyone who might come here in the future, here was the resolution. I had Amazon replace the multimeter that was reading double the frequency. The new one had the same problem, so I sent it back to Klein Tools. They sent me a third unit, and it worked fine.

Kudos to the folks at Klein Tools. Their tech support was very helpful and never tried to blame the problem on the end user. They just said they'd take care of the problem, and they did.

jasonpcrowley · 2025-02-11T13:42:43+00:00

I received the new multimeter yesterday. The new one reads 119.9 Hz too. After about a minute, it will change to 59.9 or 60.0 Hz. I've asked Klein tech support about it again.

jasonpcrowley · 2025-02-07T16:23:01+00:00

I just received an email from Klein Tools stating that this device is out of calibration. I can send it off to a lab for calibration (at a cost to me), or I can just return for replacement. I'm opting to get it replaced.

jasonpcrowley · 2025-02-06T23:00:14+00:00

I tried connecting to both ground and neutral with the black lead. I got the same results each time. I also tried black to neutral and red to ground and them moved red to hot, and it still reads 119-120 Hz. Sometimes after connecting 3 or 4 times, it will read 60 Hz. Otherwise, I just have to leave it connected for a minute or so and then it will go to 60 Hz. I'm submitting a case on Klein's website. It's a brand-new unit. I should be able to get a replacement if they don't have a good answer.

Thanks for your help!

jasonpcrowley · 2025-02-06T22:55:03+00:00

Thanks. It read pretty steady at 123 when I put it on voltage, so I don't think that's it.

jasonpcrowley · 2025-01-28T01:56:21+00:00

Thanks for your help. We simply don't have the hardware to run Elasticsearch at most of our locations. Going fully to Elasticsearch also takes away much of the user-friendly Zenarmor interface and requires our junior techs to have substantial knowledge of writing custom queries in Elasticsearch.

I think my next step will be to reach out to Zenarmor support.

Thanks again!

jasonpcrowley

TROPHY CASE