¿ªÔÆÌåÓý

Third Party not inspected by filters


 

Hi,

Today i noticed that filters do not work on third party packets coming over RF.

I opened an issue on Github explaining it.


 

Hi All,

Today I decided to get my hands on it, we have some fellows who thin it is funny to gate repeater objects from IS to RF with 2 or more hops...

I came out with this . Basically, now all filters inspect thrid party payloads....
This solves my issues with the useless objects but brings another issue. Some filters that shall not apply on third party payload are applied on third party payload.

These filters are the filters working on the path: d/ v/ and u/

Still have to fiure a way out to get around it.


73
Geoffrey F4FXL - KC3FRA

?


 

¿ªÔÆÌåÓý

Fantastic work Geoffrey,? I've been trying to figure this out myself.? Ideally i just allow message
type packets from IS->RF, but you have to essentially allow all third party packets to get all
those embedded messages too.

cool,
-craig
KM6LYW

On 12/2/22 13:33, Geoffrey Merck wrote:

Hi All,

Today I decided to get my hands on it, we have some fellows who thin it is funny to gate repeater objects from IS to RF with 2 or more hops...

I came out with this . Basically, now all filters inspect thrid party payloads....
This solves my issues with the useless objects but brings another issue. Some filters that shall not apply on third party payload are applied on third party payload.

These filters are the filters working on the path: d/ v/ and u/

Still have to fiure a way out to get around it.


73
Geoffrey F4FXL - KC3FRA

?



 

Hi Craig,

Actually Direwolf is doing gating of messages to RF by the book.

The issue I have here is some fellows gating useless stuff like voice repeater objects with 2 hops or more. I do not want my 1200m HAAT Digipeater to digipeat that crap.


I dug more into it today,? it seems only the type t and budfilter filter were affected. So I reverted some of my work and fixed and I am trying another approach.

To be continued...


 

Hi All,

Just authored a Pull-Request adressing this issue.


 

Is this request going anywhere?
I want to differentiate between messages and objects within third party packets received by a mountain-top digi, which I could do using budlists if the test applied to the third party data rather than the sending igate which is the same for both, unless there is already a way to identify third party messages or objects.
Graeme VK2HFG


 

The mountain-top digis are running development version 1.7B from Nov 21.? According to 1.7 release information:?
  • Packet filtering now skips over any third party header before classifying packet types.

?
I'll have to see about updating the digi to 1.7 release.