fake_trx send TRXC responses from wrong source address
I'm starting fake_trx.py like this:
./fake_trx.py -R 127.0.0.21 -r 127.0.0.21 --trx TRX1@127.0.0.21:5700/1 --trx TRX2@127.0.0.21:5700/2 --trx TRX3@127.0.0.21:5700/3
And then osmo-bts-trx is sending TRXC commands from 127.0.0.20 to 127.0.0.21, and fake_trx.py responds. However, the response originates from 127.0.0.1 instead of the 127.0.0.21 that was configured.
Subsequently, osmo-bts-trx rejects those UDP responses as (presumably) the socket is fully connected and hence only accepts packets with correct source ip+port.
pcap file attached.
- Status changed from New to Feedback
- Assignee changed from fixeria to laforge
I'm using for my ttcn3 test cases:
../../osmocom-bb//src/target/trx_toolkit/fake_trx.py -b 127.0.0.21 -R 127.0.0.20 -r 127.0.0.22 --trx TRX1@127.0.0.20:5700/1 --trx TRX2@127.0.0.20:5700/2 --trx TRX3@127.0.0.20:5700/3
-b for the bind address
- Status changed from Feedback to New
- Assignee changed from laforge to fixeria
- Priority changed from Normal to Low
Yes, you can manually configure a bind address and thereby force it. But shouldn't it be normal for any UDP-using application to always send responses back to whoever sent the packet? That's how datagram applications work in general, at least AFAICT.
Re-assigning to fixeria