rohc

no ping with remote server

Asked by said lokhat

hi,
i have setup a scenario :
- 2 VM with centos 6.3
- rohc 1.6
- iprohc0.6
followed the instructions on wiki : http://rohc-lib.org/wiki/doku.php?id=iprohc-run
both vm are in same network :
- server: 192.168.1.100
- client : 192.168.1.99
everything works fine : connection, ping, i see traces in log

now , i move the server VM to a remote public location with public IP : x.x.x.x
the client remains same (behind a ADSL modem)
i reconnect : link is connected , ping between client and x.x.x.x works
no firewall is activated
but i cannot ping the tunnel : 192.168.42.1 from client
ping just freeze : no response.

what can be the problem?

server log :

Jun 21 07:16:40 ROHC iprohc_server[2196]: server is now ready to accept requests from clients
Jun 21 07:16:40 ROHC iprohc_server[2196]: Initializing routing thread
Jun 21 07:16:40 ROHC iprohc_server[2196]: Initializing routing thread
Jun 21 07:17:07 ROHC iprohc_server[2196]: new connection from y.y.y.y:60449
Jun 21 07:17:08 ROHC iprohc_server[2196]: TLS handshake succeeded
Jun 21 07:17:09 ROHC iprohc_server[2196]: [y.y.y.y] Connection asked, negotating parameters
Jun 21 07:17:09 ROHC iprohc_server[2196]: [y.y.y.y] Connection asked, negotating parameters (proto version 1, asked packing : 0)
Jun 21 07:17:09 ROHC iprohc_server[2196]: [y.y.y.y] Connection started by client
please define a callback for compressor traces
[rohc_comp.c:1101 rohc_comp_set_wlsb_window_width()] width of W-LSB sliding window set to 4
[rohc_comp.c:1158 rohc_comp_set_periodic_refreshes()] IR timeout for context periodic refreshes set to 1700
[rohc_comp.c:1160 rohc_comp_set_periodic_refreshes()] FO timeout for context periodic refreshes set to 700
[rohc_comp.c:1584 rohc_comp_add_rtp_port()] port 1234 added to the UDP port list for RTP traffic
[rohc_comp.c:1584 rohc_comp_add_rtp_port()] port 36780 added to the UDP port list for RTP traffic
[rohc_comp.c:1584 rohc_comp_add_rtp_port()] port 33238 added to the UDP port list for RTP traffic
[rohc_comp.c:1584 rohc_comp_add_rtp_port()] port 5020 added to the UDP port list for RTP traffic
[rohc_comp.c:1584 rohc_comp_add_rtp_port()] port 5002 added to the UDP port list for RTP traffic
[rohc_comp.c:2962 c_create_contexts()] create enough room for 16 contexts (MAX_CID = 15)

on client, ip -4 address show :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.1.99/24 brd 192.168.1.255 scope global eth0
8: iprohc: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    inet 192.168.42.11/24 scope global iprohc

Question information

Language:
English Edit question
Status:
Answered
For:
rohc Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Didier Barvaux (didier-barvaux) said : 		#1

Hello,

Is there any NAT gateway between the client and the server? If yes, that's probably the cause of the problem. The control channel (TCP/3126) goes well through NAT gateways, but the data channel (IP protocol 142) doesn't.

If there is no NAT gateway, please capture traffic:
 - on client (on the tunnel interface),
 - on client (on network interface below the tunnel interface),
 - on server (on the tunnel interface),
 - on server (on network interface below the tunnel interface).

It should help you figuring if some IP packets with protocol 142 (data) are lost, and where.

Regards,
Didier

Revision history for this message
said lokhat (mslokhat) said : 		#2

Hi,

yes, there is a NAT gateway at client side.
it's a common setup with ADSL modem :
- ADSL modem with public IP address obtained dynamically from provider
- local Lan : 192.168.1.0/24

so is it possible to make iprohc (+rohc-lib) works in this kind of setup?

Rgds

Revision history for this message
Didier Barvaux (didier-barvaux) said : 		#3

Hello,

> so is it possible to make iprohc (+rohc-lib) works in this kind of setup?

It depends on your NAT gateway. Perform the network capture as I described in my previous message. Check whether IP packets with protocol 142 go through the NAT gateway or not.

If IP/142 packets are blocked, the IP/ROHC tunnel could be improved to support IP/UDP as transport layer in addition to IP/142. This change should be fairly easy.

Regards,
Didier

Revision history for this message
said lokhat (mslokhat) said : 		#4

Hi,

no, the packets do not go through the gateway

is it possible for you to make the necessary changes and make it work under this kind of architecture?
i think it's the most common setup .

if there are any fee, is it possible for you to send me (in private) your fee for this work?

Thansk in advance

Revision history for this message
robert kessler (rkessler) said : 		#5

Good Day,

Was just wondering if the code was ever modified to suit change as mentioned above.

If there is a fee, please PM me the charges.

Thank you

Can you help with this problem?

Provide an answer of your own, or ask said lokhat for more information if necessary.

To post a message you must log in.