Project

General

Profile

Actions

Bug #4798

open

fake_trx send TRXC responses from wrong source address

Added by laforge over 3 years ago. Updated almost 3 years ago.

Status:
Feedback
Priority:
Low
Assignee:
Category:
TRX Toolkit
Target version:
-
Start date:
10/11/2020
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

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.


Files

fake_trx_wrong_source.png View fake_trx_wrong_source.png 18.7 KB laforge, 10/11/2020 03:58 PM
fake_trx_wrong_source.pcap fake_trx_wrong_source.pcap 4.11 KB laforge, 10/11/2020 03:58 PM
Actions #1

Updated by lynxis over 3 years ago

  • 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

Actions #2

Updated by laforge about 3 years ago

  • 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

Actions #3

Updated by fixeria almost 3 years ago

  • Status changed from New to Feedback

laforge wrote:

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.

I had a quick look, and to be honest I have no idea how the UDPLink implementation is supposed to affect the source address for outgoing datagrams. If you don't specify the exact TRXC/TRXD bind address, then '0.0.0.0' is used by default, so it's actually the kernel picking '127.0.0.1' and not fake_trx.py itself.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)