PR https://github.com/g4klx/YSFClients/pull/185 (to allow sending text messages/pictures) introduced a problem that causes wiresx commands to be also passed through (fully or partially) to reflectors unintentionally even with WiresXCommandPassthrough=0, this is a major problem for eg. when linked to a XLX reflector (with WiresXCommandPassthrough=0) as if we issue wiresx commands they are actually being replied by both local YSFGateway and remote XLX, and radio doesn't seem to recognize any reply at all, waits until timeout...
Actually there are two issues with the implementation on https://github.com/g4klx/YSFClients/pull/185, one is that the introduced check of WX_STATUS var on processWiresX() doesn't take in account that WXS_NONE is returned when processing DX, ALL and CAT thus it doesn't even try to filter these (this would be easy to fix obviously), but there is a second problem, from what I could understand actually each wiresx command is composed by multiple packets and processWiresX() is called multiple times until command is complete/validated, then the implementation fails by allowing to partially pass the first packets of the command, as m_exclude is only really set once, when the command is validated, but some packets already passed through, from what I could see for example on a command composed by 5 packets only the 4th one was actually filtered, and XLX was able to still fully recognize the wiresx command with the 4 non-filtered packets and replied it as described above. I think this is a flawed implementation and I guess to do a proper filtering (dropping all packets) of wiresx commands may not be so easy?
Unless there is a better way to do it, I'm submitting this patch that reverts the changes on #185 and applies a small change to still allow sending text messages/pictures without problems (I hope), with my change:
-> if WiresXCommandPassthrough is enabled and we are linked on wiresx capable reflector: all data is passed through to reflector (this is unchanged and always happened with or without #185 )
-> if WiresXCommandPassthrough is disabled and we are linked on wiresx capable reflector (XLX or YSF2xxx): filter all data (as done originally before #185 ), these reflectors do not support messages/pictures anyway then no problem.
-> if WiresXCommandPassthrough is disabled/enabled and we are linked on NON wiresx capable reflector: allow all data to be passed transparently to reflector, this will allow messages/pictures on these reflectors, wiresx commands will also be passed but these reflectors doesn't process/reply them anyway, think not a problem...
PR https://github.com/g4klx/YSFClients/pull/185 (to allow sending text messages/pictures) introduced a problem that causes wiresx commands to be also passed through (fully or partially) to reflectors unintentionally even with WiresXCommandPassthrough=0, this is a major problem for eg. when linked to a XLX reflector (with WiresXCommandPassthrough=0) as if we issue wiresx commands they are actually being replied by both local YSFGateway and remote XLX, and radio doesn't seem to recognize any reply at all, waits until timeout...
Actually there are two issues with the implementation on https://github.com/g4klx/YSFClients/pull/185, one is that the introduced check of WX_STATUS var on processWiresX() doesn't take in account that WXS_NONE is returned when processing DX, ALL and CAT thus it doesn't even try to filter these (this would be easy to fix obviously), but there is a second problem, from what I could understand actually each wiresx command is composed by multiple packets and processWiresX() is called multiple times until command is complete/validated, then the implementation fails by allowing to partially pass the first packets of the command, as m_exclude is only really set once, when the command is validated, but some packets already passed through, from what I could see for example on a command composed by 5 packets only the 4th one was actually filtered, and XLX was able to still fully recognize the wiresx command with the 4 non-filtered packets and replied it as described above. I think this is a flawed implementation and I guess to do a proper filtering (dropping all packets) of wiresx commands may not be so easy?
Unless there is a better way to do it, I'm submitting this patch that reverts the changes on #185 and applies a small change to still allow sending text messages/pictures without problems (I hope), with my change: -> if WiresXCommandPassthrough is enabled and we are linked on wiresx capable reflector: all data is passed through to reflector (this is unchanged and always happened with or without #185 ) -> if WiresXCommandPassthrough is disabled and we are linked on wiresx capable reflector (XLX or YSF2xxx): filter all data (as done originally before #185 ), these reflectors do not support messages/pictures anyway then no problem. -> if WiresXCommandPassthrough is disabled/enabled and we are linked on NON wiresx capable reflector: allow all data to be passed transparently to reflector, this will allow messages/pictures on these reflectors, wiresx commands will also be passed but these reflectors doesn't process/reply them anyway, think not a problem...