Open Error-Gap opened 5 months ago
Thx, buffer is now increased now in both forks
Thanks @openshwprojects
I did test this and it worked so far the input buffer parsing through as expected, but then rather into further issues where the device still refused to actually send any IR codes.
Further investigation showed that the Kaseikyo variety remotes use the "sendPulseDistanceWidthFromArray" function, which would dead-end (no code) under the SpoofIrSender object.
I've managed to modify drv_ir.h and drv_ir.c so that it passes up the a reference to the "myIRsend" object to this class, which then pushed the function back down through that to the original IRsend functions from IRSend.hpp
I've compiled and tested the changes on my device and this worked to get it successfully sending codes emulating the keiseikyo denon remote.
Please see the attached patch. Assuming all compiles properly for you after applying it then this should be a functional update to fix this issue.
Cheers,
ErrorGap
(updated) drv_ir.2024-02-19.patch.gz
p.s. If there is a better way contribute updates/patches please let me know. TBH it's been quite a long time since I've poked at anyone's public code nor contributed to projects that I wasn't part of the development team etc for.
Thanks, can you just open a pull request so I can automatically merge it? It can be easily done via Github Windows client.
Done. You should see the pull request now.
Describe the bug "IR_Send_Cmd" in file driver/drv_ir.cpp uses a temporary buffer "args" for arguments that is only 20 chars (19 + a zero in the last character) This copies data in from commands but is insufficient for larger IRSend commands including those for protocols with larger names, in particular Kaseikyo which supports various vendor subtypes under protocol names names
These commands could exceed 30 characters for the arguments i.e. IRSend Kaseikyo_Mitsubishi 0x330 0x2d 1
The buffer size for the actual command textbox actually seems to be 128 characters so 20 is drastically truncating the potential input, though the likely input is less due to the command-format and protocol-names. If RAW IRSend capabilities are added, the raw strings could get even larger.
I believe that increasing the size of the "args" character array can potentially fix this, though it's worth validating that this doesn't result in a buffer overflow further down.
Firmware:
To Reproduce Steps to reproduce the behavior:
Screenshots If applicable, add screenshots to help explain your problem.
Additional context Ref: https://www.elektroda.com/rtvforum/viewtopic.php?p=20932660#20932660