Project

General

Profile

Actions

Bug #2413

closed

osmo-gsm-tester: smpp: ESME traffic not logged in nitb pcap file

Added by pespin over 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Low
Assignee:
Target version:
-
Start date:
07/31/2017
Due date:
% Done:

0%

Spec Reference:

Description

We need to make sure this information is stored correctly in order to debug SMPP issues more easily.

After a quick check, I couldn't find why this conn is not in the pcap file. The filter applied to tcpdump seems to be OK, it filters for same host which is used by the ESME to connect, but there's not TCP connection port=2775 to it on the pcap file.

Test checked which contains the issue (other may probably too): smpp/esme_ms_sms_storeforward.py


Related issues

Related to OsmoNITB - Bug #2414: SMSC: deliverSM message with no user_message_referenceNew07/31/2017

Actions
Related to OsmoNITB - Bug #2429: SMSC: deiverSM message with bad user_message_referenceClosedpablo08/10/2017

Actions
Actions #1

Updated by pespin over 6 years ago

  • Assignee set to 55360
Actions #2

Updated by pespin over 6 years ago

  • Description updated (diff)
Actions #3

Updated by pespin over 6 years ago

  • Related to Bug #2414: SMSC: deliverSM message with no user_message_reference added
Actions #4

Updated by pespin over 6 years ago

It seems the traffic can be sniffed through "lo" interface with "tcpdump -n -vv -i lo tcp and port 2775". However, it doesn't appear on the interface osmo-nitb is listening to (eth1:0, osmo-nitb listens on 10.42.42.2), or in the main one (eth1, 10.42.42.1):

~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0d:b9:35:3a:41 brd ff:ff:ff:ff:ff:ff
    inet 10.42.42.1/24 brd 10.42.42.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet 10.42.42.2/24 brd 10.42.42.255 scope global secondary eth1:0
       valid_lft forever preferred_lft forever
    inet 10.42.42.3/24 brd 10.42.42.255 scope global secondary eth1:1
       valid_lft forever preferred_lft forever
    inet 10.42.42.4/24 brd 10.42.42.255 scope global secondary eth1:2
       valid_lft forever preferred_lft forever
    inet 10.42.42.5/24 brd 10.42.42.255 scope global secondary eth1:3
       valid_lft forever preferred_lft forever
    inet 10.42.42.6/24 brd 10.42.42.255 scope global secondary eth1:4
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:b9ff:fe35:3a41/64 scope link
       valid_lft forever preferred_lft forever
11:58:26.032946 IP (tos 0x0, ttl 64, id 13046, offset 0, flags [DF], proto TCP (6), length 60)
    10.42.42.1.46654 > 10.42.42.2.2775: Flags [S], cksum 0x6885 (incorrect -> 0xcf10), seq 1934627237, win 43690, options [mss 65495,sackOK,TS val 40444755 ecr 0,nop,wscale 10], length 0
11:58:26.033013 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    10.42.42.2.2775 > 10.42.42.1.46654: Flags [S.], cksum 0x6885 (incorrect -> 0xb0b6), seq 1266789643, ack 1934627238, win 43690, options [mss 65495,sackOK,TS val 40444755 ecr 40444755,nop,wscale 10], length 0
11:58:26.033070 IP (tos 0x0, ttl 64, id 13047, offset 0, flags [DF], proto TCP (6), length 52)
    10.42.42.1.46654 > 10.42.42.2.2775: Flags [.], cksum 0x687d (incorrect -> 0x8429), seq 1, ack 1, win 43, options [nop,nop,TS val 40444755 ecr 40444755], length 0

Not sure if we can modify the routing to have it show up in the osmo-nitb interface instead of going through lo.

Actions #5

Updated by pespin over 6 years ago

  • Related to Bug #2429: SMSC: deiverSM message with bad user_message_reference added
Actions #6

Updated by pespin over 6 years ago

osmo-nitb is only listening on 10.42.42.2:2775

# netstat -l -n -t -p
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
...
tcp        0      0 10.42.42.2:2775         0.0.0.0:*               LISTEN      11367/osmo-nitb
...

And here's the actual ESME<->NITB connection:

tcp        0      0 10.42.42.1:46953        10.42.42.2:2775         ESTABLISHED 11352/python3

Actions #7

Updated by pespin over 6 years ago

Looks like the "local" routing table sets the conn to be used locally, for any conn going from the master iface (10.42.42.1, eth1) to the secondary ones (10.42.42.2, eth1:*):

# ip route show table local
local 10.3.0.17 dev tun0  proto kernel  scope host  src 10.3.0.17
broadcast 10.9.25.0 dev eth0  proto kernel  scope link  src 10.9.25.101
local 10.9.25.101 dev eth0  proto kernel  scope host  src 10.9.25.101
broadcast 10.9.25.255 dev eth0  proto kernel  scope link  src 10.9.25.101
broadcast 10.42.42.0 dev eth1  proto kernel  scope link  src 10.42.42.1
local 10.42.42.1 dev eth1  proto kernel  scope host  src 10.42.42.1
local 10.42.42.2 dev eth1  proto kernel  scope host  src 10.42.42.1
local 10.42.42.3 dev eth1  proto kernel  scope host  src 10.42.42.1
local 10.42.42.4 dev eth1  proto kernel  scope host  src 10.42.42.1
local 10.42.42.5 dev eth1  proto kernel  scope host  src 10.42.42.1
local 10.42.42.6 dev eth1  proto kernel  scope host  src 10.42.42.1
broadcast 10.42.42.255 dev eth1  proto kernel  scope link  src 10.42.42.1
broadcast 10.64.1.0 dev eth2  proto kernel  scope link  src 10.64.1.1
local 10.64.1.1 dev eth2  proto kernel  scope host  src 10.64.1.1
broadcast 10.64.1.255 dev eth2  proto kernel  scope link  src 10.64.1.1
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
broadcast 192.168.1.0 dev eth2  proto kernel  scope link  src 192.168.1.200
local 192.168.1.200 dev eth2  proto kernel  scope host  src 192.168.1.200
broadcast 192.168.1.255 dev eth2  proto kernel  scope link  src 192.168.1.200

# ip route get 10.42.42.2
local 10.42.42.2 dev lo  src 10.42.42.1
    cache <local>
Actions #8

Updated by pespin over 6 years ago

  • Assignee changed from 55360 to pespin
Actions #9

Updated by pespin over 6 years ago

This is starting to become annoying as I see the same issue appears for traffic in MSC pcap file, and I think the same may happen with some osmo-bts-trx / osmo-trx traffic.

I think it basically happens on any connection which is started with the main eth address (10.42.42.1), basically that one is selected automatically by kernel/routing when no speciifc bind() is done before connect() is called.

We should change the network setup/config inside the host + document it in order to be able to record all traffic using the specific interface with the specific IP address.

Actions #10

Updated by laforge over 6 years ago

  • Priority changed from Normal to Low
Actions #11

Updated by pespin over 6 years ago

  • Status changed from New to Resolved

Fixed by recording on "any" interface and relying on filtering based on IP. See https://gerrit.osmocom.org/#/c/4937/

Actions #12

Updated by laforge about 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)