I doubt it's a bug of FakeTRX. You can use ctrl_cmd.py to send as many FAKE_* TRXC commands as you wish, and they all will be confirmed. Moreover, if that was a problem of FakeTRX, OsmoBTS wouldn't work reliable, but it does.
I guess the problem is somewhere in our TTCN-3 implementation of the TRXC interface. If you add some logging to IPL4_to_TRXC_RecvFrom() and f_TRXC_transceive(), and then call the last one several times, you will see that the first command is confirmed in the most cases, but then ~4/5 times the following ones fail due to timeout.
An example of three subsequent successful commands:
TC_ho_rach(7)@DELL: Tx TRXC: { cmd := { verb := "FAKE_RSSI", params := { "-54", "0" } } }
TC_ho_rach(7)@DELL: Rx TRXC message: "RSP FAKE_RSSI 0 -54 0" & char(0, 0, 0, 0)
TC_ho_rach(7)@DELL: Warning: dec_TrxcMessage(): Data remained at the end of the stream after successful decoding: '00'O
TC_ho_rach(7)@DELL: Tx TRXC: { cmd := { verb := "FAKE_RSSI", params := { "-55", "0" } } }
TC_ho_rach(7)@DELL: Rx TRXC message: "RSP FAKE_RSSI 0 -55 0" & char(0, 0, 0, 0)
TC_ho_rach(7)@DELL: Warning: dec_TrxcMessage(): Data remained at the end of the stream after successful decoding: '00'O
TC_ho_rach(7)@DELL: Tx TRXC: { cmd := { verb := "FAKE_RSSI", params := { "-56", "0" } } }
TC_ho_rach(7)@DELL: Rx TRXC message: "RSP FAKE_RSSI 0 -56 0" & char(0, 0, 0, 0)
TC_ho_rach(7)@DELL: Warning: dec_TrxcMessage(): Data remained at the end of the stream after successful decoding: '00'O
An example of failed command:
TC_ho_rach(7)@DELL: Tx TRXC: { cmd := { verb := "FAKE_RSSI", params := { "-57", "0" } } }
MTC@DELL: dec_TrxcMessage(): Stream before decoding: "RSP FAKE_RSSI 0 -57 0" & char(0, 0, 0, 0)
...
MTC@DELL: dec_TrxcMessage(): Decoded @TRXC_Types.TrxcMessage: { rsp := { verb := "FAKE_RSSI", status := 0, params := { "-57", "0" } } }
MTC@DELL: Warning: dec_TrxcMessage(): Data remained at the end of the stream after successful decoding: '00'O
