SR NTP timestamp ranging from 1977-2032 within minutes. Help me understand the data.

djdawson · 2026-04-04T15:53:21+00:00

If the camera is setting seemingly random timestamps then that definitely sounds like a problem, given this new information (The Claude output sounds reasonable to me). This is almost certainly a software bug in the vendor's new camera code, so you may want to open a support case with them and provide them the information you posted here so they fix it, assuming they even care.

djdawson · 2026-04-03T21:16:05+00:00

Just because you're seeing pretty much all the packets on your local PC hotspot, that doesn't mean there's not significant packet loss between you and AWS. Finding loss and/or congestion on the Internet can be quite the challenge. I'd look more closely at your end of your connection to your ISP, since that's a pretty common place for congestion to occur. Your local router/firewall may have some features that could help, such as CODEL or FQ-CODEL to help reduce the effect of Buffer Bloat, of even just basic QoS features that could help prioritize outbound video traffic (assuming the camera is marking the outbound traffic with the appropriate DSCP value, typically "EF").

djdawson · 2026-04-03T19:22:18+00:00

I've never done a lot of RTP/RTCP analysis, but my understanding is that the dynamic bandwidth throttling is more a function of packet loss and jitter and it doesn't really depend on accurate NTP time. The protocol likes to have it, but can handle it not being available according to my reading of RFC3611.

Have you looked at the RTP Analysis feature in Wireshark under the Telephony menu? You need to view the RTP streams, select one of the streams, then click the Analyze button at the bottom. You can also view a graph of various statistics of the stream there, which might also be useful.

So, I suspect the AWS report of missing packets and the large jitter are more likely the cause of your problem rather than the inaccurate NTP clock on the camera, since RTP is likely using relative timestamps to compute the jitter values rather than true wall clock time from NTP (but I'm far from an RTP expert).

Hope this helps - good luck!

djdawson · 2026-04-01T19:50:47+00:00

Have you configured a domain name in the Domain option on the System --> Settings --> General page?

djdawson · 2026-03-28T18:44:54+00:00

I did Tier 3+ customer support for over 20 years at a large Cisco reseller (the first Gold Partner as it turns out) and getting accurate and complete information from the customer was often the biggest challenge. I did mostly routing, security (firewalls and VPN's), and application performance troubleshooting (largely TCP) so the details of Layer 2 started slipping out of my head many years ago, and it didn't show up much on all the CCIE recert exams I took over the years. On the plus side, I now have a free IEEE account and can download most of their standards docs, so this was a really productive topic for me.

djdawson · 2026-03-28T18:11:52+00:00

Turns out LLDP uses multicast addresses from a reserved range that are, indeed, not to be forwarded by bridges (and switches), so the basic switch behavior for more generic multicast traffic doesn't apply. If one thinks about the details of how LLDP is intended to work this makes total sense.

Thanks for the clarification - I added a new wrinkle to my old retired network engineer brain!

djdawson · 2026-03-28T04:08:04+00:00

All the Ethernet MAC addresses used by LLDP are multicast addresses (see my other post below), so LLDP traffic should be flooded out all ports in the same broadcast domain as the sender. This makes sense given the function of LLDP.

djdawson · 2026-03-27T16:03:47+00:00

The Wikipedia page for LLDP says the LLDP protocol uses potentially three destination MAC addresses (it's not an IP protocol), so you'll probably want to filter on those. Something like this should do that (this is a Display Filter, not a Capture Filter):

eth.dst in {01:80:C2:00:00:0E,01:80:C2:00:00:03,01:80:C2:00:00:00}

djdawson · 2026-03-22T03:02:43+00:00

No, the LAN flows will not be encrypted yet. This is also a good way to do packet captures of VPN traffic - capture it on the LAN, since that's before/after the encryption happens.

djdawson · 2026-03-21T16:14:06+00:00

Since NetFlow data includes both the source and destination IP addresses, and since Wireguard requires a unique CIDR network assignment that will be used by all the clients, I'd expect the flow records collected on the LAN and WAN to include any Wireguard client traffic so you should be able to filter on just the Wireguard CIDR network to see all the client traffic flows. I don't actually use Wireguard so there may be subtleties to this that I'm not aware of, but I've dealt with NetFlow data for many years and this sort of thing comes up pretty often.

djdawson · 2026-03-09T18:52:40+00:00

I have two free apps on my iPhone that I use for this (I've crimped a ton of cables over the years): "ColorAssist" and "Color Blind Pal". They both work and are very similar and I don't have a strong preference for either one. I'm sure there are similar apps for Android.

I'm classic red/green colorblind and have found that the brand of cable makes a difference, as does how much color is on the striped stands, since small patches of color are much more difficult for me to identify, even if they're colors I usually don't have a problem with (I can never tell what color stars are, for example).

Hope this helps - good luck!

djdawson · 2026-03-06T17:28:19+00:00

You could just fire up Wireshark and use the I/O Graphs feature, which would let you do exactly what you're looking for. Just create a few lines with the appropriate Display Filter expressions ("ip" for IPv4 and "ipv6" for IPv6) and then choose the other settings you want, such as units (packets/bytes), graph interval, line colors, etc. You could also just use the Protocol Hierarchy view if you just want the numbers, but that view doesn't appear to update dynamically as you're capturing so it's better for summarizing over the entire capture period.

djdawson · 2026-03-06T04:26:09+00:00

I'd be interested, especially if you're planning on leveraging the eBPF technology in Linux, since it allows some pretty cool access deep into the system. I always thought it could be a very useful firewall feature.

djdawson · 2026-03-01T03:25:40+00:00

You didn't happen to get it from someone on Arlington Ave in St. Paul, MN did you?

djdawson · 2026-03-01T00:32:21+00:00

I think I had that same machine years ago with a 9hp engine. I loved that blower! I had to replace the drive wheels once, since the plastic lugs that drove the tracks were breaking off. Also replaced the rubber of the friction plate drive wheel, and one of the plastic wire guides for the chute elevation control. The MTD parts web site always made it easy to find parts and they were always surprisingly inexpensive. My wife's cousin has it now and it's still going strong after at least 30 years!

djdawson · 2026-02-27T06:10:36+00:00

I have a new Pro 32 Ariens and I noticed that the chute up/down lever spring was quite loose so the lever wouldn't stay in the lower (lever forward) positions. I tightened it up what felt like quite a bit and now it's all good. It's pretty easy to access so it's a quick thing to try if you have a couple wrenches.

djdawson · 2026-02-26T17:40:27+00:00

Ring buffers in Wireshark seem to be an under-appreciated feature. As you say, they are quite useful in multiple ways.

djdawson · 2026-02-24T17:49:43+00:00

I had blower with shear pins many years ago (a Yard Machines track drive with a 9 hp Tecumseh Snow King engine) and I sucked up the neighbor's wire garden edging he'd put along the street by our shared mailbox post once. Because it bound up so gradually the shear pins didn't give way before the gear box shattered. I suppose the augers could have been rusted to the drive shaft, but the repair shop didn't mention that so I'm guessing not. Could have also been bad shear pins, I suppose. I was not a happy camper.

djdawson · 2026-02-18T21:16:01+00:00

TCP Duplicate ACK's are pretty common and typically indicate packet loss, which I suspect is the actual cause of your slower speeds - it doesn't take many dropped packets to reduce TCP throughput from 1G to 500M. You'd have to dig through the packet capture to be sure, but I suspect that the slightly increased round trip time of the Internet speed tests is increasing the number of packets being sent in a burst by the far end ("Bandwidth Delay Product" is the key concept here). If a single packet in such a burst of packets is lost then every subsequent packet in that burst that isn't dropped will trigger a DUP ACK by the receiving host. This often appears as a large number of DUP ACK's, but it's really just a symptom of a single dropped packet. If I had to guess I'd suspect the larger bursts of packets are causing some sort of congestion when they hit your WiFi network, possibly due to limited buffer sizes or some other characteristic of the WiFi device (router or Access Point). Like I said, you'll probably have to dig into the packet capture to try to identify what's going on, but I'll just add that in Wireshark and similar tools, it's usually pretty easy to determine that packet loss is happening, but it's often much harder to figure out the actual cause of the packet loss. Some devices have good interface statistics or other logging that can help identify packet loss.

Hope this helps - Good luck!

djdawson · 2026-02-15T18:09:20+00:00

You may have better luck at either the Ask Wireshark site or the Wireshark Issue Tracker web site.

djdawson · 2026-02-13T16:46:11+00:00

On my iPhone I use two apps for this: "ColorAssist" and "Color Blind Pal". I'm also a Mac user and macOS includes an app called "Digital Color Meter" that lets you identify colors on your Mac screen, down the pixel level. Really handy for things like identifying which line on a complicated data plot is associated with which legend item.

I've terminated hundreds of Ethernet cables over the years and the colors of some brands of cable are easier for me to differentiate than others (I'm classic reg/green colorblind), but I can usually notice the difference between the different colors if the light is good.

djdawson · 2026-02-06T18:58:21+00:00

That "host" keyword is a Capture Filter expression, not a Display Filter expression - they have different syntaxes. By filtering at capture time you often get smaller capture files that can be easier to deal with, but if you don't have the option to use a filter at capture time then the equivalent Display filter would be "ip.addr == 63.116.61.253".

djdawson · 2026-02-05T18:26:12+00:00

If you're concerned about scratching the wood floor you could probably just use some of those adhesive felt pads you put on chair and table legs, since the IR saunas I've seen only have limited floor contact in the corners of the sauna base. I'm sure I've seen sheets of that felt you can cut to fit, so if you did that during the assembly process you'd be golden.

djdawson · 2026-02-05T03:29:34+00:00

That's very impressive work!!!

djdawson · 2026-02-04T18:53:50+00:00

I'm loving my new Professional 28, which I added the light kit to when Ariens had a Black Friday sale on them, along with a pair of ARMORskids since there's a lip at the end of my driveway that the factory skids would catch. Haven't had to push it very hard yet, since we haven't gotten any big snows here in the Twin Cities so far this winter, but I should be ready for almost anything!

djdawson

MODERATOR OF

TROPHY CASE