Anomaly - MLAT traffic


#1

Anomaly report for PiAware feeder with a MAC address of b8:27:eb:79:e4:eb:
11% of UDP multilateration traffic sent by piaware is not reaching the FlightAware servers. This may indicate a network problem.

I’m guessing this issue may be related to a restore that is in progress and may take a few days. Should I just ignore this message until the restore completes? It seems like there should be plenty of spare bandwidth, but I really don’t have much time to spend flushing that out.

Anything specific I might check?

Edit: In case there was something awry with the RPi, I rebooted it. I don’t see the message anymore. Is there any way to determine recurrence of this condition? For example, is there a log somewhere I can check that may have reported this over the past couple days?


#2

I guess I won’t worry about it. I haven’t seen the message again since I restarted my RPi.


#3

I’m with Comcast.

I get the same message when my internet speed falls way off. It usually requires a reset of my cable modem to get things back to normal.

Thinking of switching over to AT&T U-verse.


#4

I have a 200 mbps internet connection that has been consistently good lately. I don’t think that is the issue. Steady progress on my restore seems to confirm it was not an internet connection issue with my router. But maybe there was an issue with the networking of the RPi, since I apparently have not run into the issue again since rebooting it. I suppose I should have downloaded its logs first.


#5

One other thing.

My rPi is connected to my Comcast cable modem (SMC D3GNV) via Ethernet as opposed to wifi with my router.

I’m paying for xfinity Blast.


#6

Yeah. It’s just telling you that some mlat traffic is getting dropped. That’s not fatal, the traffic goes via UDP and it’s expected that some traffic might get dropped, so long as most of it gets through mlat will still work OK.


#7

I just saw a twitter post on UDP copying a cartoon
https://twitter.com/b0rk/status/811403117673742336
– calling it the “unreliable data protocol” (if you’re on Twitter, look at SwiftOnSecurity)

It says, correctly, that when you send UDP packets they might arrive:
– out of order
– never
– but probably not corrupted

UDP packets are the first thing that get dropped on the floor when things get congested.

And it doesn’t have to be congestion where YOU are…

bob k6rtm


#8

Since three or four weeks I watch the same anomaly on my dump (location close to Hamburg/Germany), but very seldom and only at a very few military flights, especially Boeing 707 based a/c like RC-135, E-3 AWACS or KC-135 tankers.

Never before observed that phenomenon …


#9

Today I observed the MLAT-anomaly on my RasPi again and doublechecked it with a second RasPi: NO anomaly here !

So I rebooted the first RasPi, no more anomaly. Maybe it was a kind of ‘overload’ ?? Will wait some more days/weeks …