APRS-IS Invalid Packets Sent to RF

[na7q]

Lately lots of packets in my area are being gated and messed up by the igate and or servers at times. As shown in the picture the packets seem to have an added colon, making it similar to a message type packet. This causes Direwolf to send this to RF, thinking it's a message, when it's not. I've had to turn off my Internet to RF functions because of the continuous transmissions of these messed up packets.
Direwolf is filtered to only send messages. To Direwolf, these appear as messages.

[dranch]

I see your screen capture is from aprs.fi ( https://aprs.fi/?c=raw&call=HEBOWX ) but looking at that output, I wonder if they are having some parsing issues on their end. Are you hearing these packets DIRECT as well? Maybe you can send some logs from Direwolf as it's heard via RF? I would include full hex decoding so we can see the real packets.

Btw, what version of Direwolf are you running? There was a fix some time ago to resolve something similar that was released in v1.3:

commit ce9eebf
Author: WB2OSZ wb2osz@comcast.net
Date: Sat Mar 19 08:10:34 2016 -0400

Packet filtering treated telemetry metadata as messages rather than telemetry.

    modified:   CHANGES.md
    modified:   pfilter.c

--

[wb2osz]

There is an old saying, in computing, "Garbage In, Garbage Out."
In this case, a certain station is corrupting the packets. Everyone downstream just passes along what they get.

Here are a few examples where the same packet is IGated by two different stations.

2017-09-25 10:20:04 EDT: HEBOWX>APN390,WIDE2-1,qAR,W7IG:@143004z4512.89NS12345.29W_296/010g012t054r000p000P000h77b10202.WxDg
2017-09-25 10:20:04 EDT: HEBOWX>APN390,WIDE2-1,qAR,W7GC-4::@143004z4512.89NS12345.29W_296/010g012t054r000p000P000h77b10202.WxDg [Invalid message packet]

2017-09-25 10:21:39 EDT: HEBOWX>APN390,WIDE2-1,qAR,W7GC-4::>EBT074.3F [Invalid message packet]
2017-09-25 10:21:39 EDT: HEBOWX>APN390,W7SRA,WIDE2*,qAR,K7LWV:>EBT074.3F

2017-09-25 11:00:04 EDT: HEBOWX>APN390,WIDE2-1,qAR,K7JD-10:@151003z4512.89NS12345.29W_299/011g013t054r000p000P000h82b10203.WxDg
2017-09-25 11:00:04 EDT: HEBOWX>APN390,WIDE2-1,qAS,W7GC-4: :@151003z4512.89NS12345.29W_299/011g013t054r000p000P000h82b10203.WxDg [Unsupported packet

2017-09-24 14:31:13 EDT: N7HQR-9>TU0YVT,W7SRA,WIDE1*,WIDE2-1,qAR,W7BJH:3T>mfd>/"3x}%
2017-09-24 14:31:17 EDT: N7HQR-9>TU0YVT,WIDE1-1,WIDE2-1,qAR,W7GC-4: <>:3T>mfd>/"3x}% [Unsupported packet format]

2017-09-24 18:35:20 EDT: KW7I>4T3XVX,W7SRA*,WIDE2-1,qAR,K7JD-10:3[Tm*4>/'"4\}|&r&8'n||3 2017-09-24 18:35:24 EDT: KW7I>4T3XVW,W7SRA*,WIDE2-1,qAS,W7GC-4: <UI>:3[Yn4o>/'"4}|&q&;'n||3 [Unsupported packet format]

Notice that one in each pair has an extra ":" and sometimes "" after the addresses.
The station owner has been notified.

The work-around in this case would be to add an IGate client side filter, for the IS-to-RF direction, to drop any packet that has that gone thru that particular station.