possible to specify fixed auto_ping port in the Crossbar.io config.json?

#1

Hi,

I hope this is not too stupid a question. First of all, let me say that the auto_ping feature in Crossbar.io/Autobahn is great and extremely helpful. We are using Crossbar/Autobahn in an IOT-like environment. At remote sites are a Autobahn/Python WAMP client/component and a firewall/modem; at our backend site is Crossbar.io.

In order to make TCP connections from the backend to a remote site, we have to open the appropriate ports on the firewall/modem. The problem is that the auto_ping/pong feature initiated by Crossbar to clients appears to use randomly available non-privileged ports - which would seem to make opening ports on the firewall to accommodate the auto_ping feature more difficult.

Are we missing something obvious? Is there some way we could be able to specify a fixed non-privileged port for the outgoing auto_ping from Crossbar, so that we don’t have to potentially open all non-privileged ports on the firewall?

Thanks very much,

Dave

0 Likes

#2

Hi Dave!

What gives you the impression that auto-pings are sent on random ports? The auto-ping is there to create traffic on existing WebSocket connections with WAMP clients - which are to the port you have configured in your Crossbar.io instance and in your application.

Do you have any data for the pings being sent using another mechanism?

Regards,

Alex

0 Likes

#3

Hi Alex,

Thanks so much for replying.

In our environment, a remote site has the Autohan/Python WAMP client/component behind a firewall/modem. The backend is where Crossbar.io is running. The remote WAMP component initiates the connection to Crossbar.io (which is configured in its config.json to listen on port 8080). Since this is therefore an “outgoing” connection from the remote site across the firewall to Crossbar.io, this seems to work fine.

Now as I understand it, Crossbar.io is the entity that initiates the auto_ping feature to check client/component connections, is that right? With the following auto_ping options configured in Crossbar.io’s config.json:

“transports”: [

{

“id”: “web”,

“type”: “web”,

“endpoint”: {

“type”: “tcp”,

“port”: 8080

},

“paths”: {

“api”: {

“type”: “websocket”,

.

.

.

“options”: {

“enable_webstatus”: false,

“max_frame_size”: 1048576,

“max_message_size”: 1048576,

“auto_fragment_size”: 65536,

“fail_by_drop”: true,

“open_handshake_timeout”: 2500,

“close_handshake_timeout”: 1000,

"auto_ping_interval": 10000,

"auto_ping_timeout": 5000,

"auto_ping_size": 4,

“compression”: {

“deflate”: {

“request_no_context_takeover”: false,

“request_max_window_bits”: 11,

“no_context_takeover”: false,

“max_window_bits”: 11,

“memory_level”: 4

}

}

}

}

}

}

],

We observe the following messages in the syslog file:

Feb 8 16:39:52 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:39:52-0500 [Router 9870] dropping connection to peer tcp4:127.0.0.1:47492 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)

Feb 8 16:52:47 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:52:47-0500 [Router 9870] dropping connection to peer tcp4:10.250.0.2:37178 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)

Feb 8 16:55:35 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:55:35-0500 [Router 9870] dropping connection to peer tcp4:127.0.0.1:47501 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)

10.250.0.2 is the address of the remote site, and the reason for my question is that I noticed the port 37178, which obviously isn’t specified anywhere, and is centrainly not an open port on the firewall/modem for Crossbar.io to be able to reach/auto_ping the remote component. What am I missing?

Also, I just noticed the messages about the localhost (127.0.0.1) auto_pings failing. Not sure what that is? We do run a couple components on the same system as Crossbar.io as well (ex. components that register RPCs for the remote components to call, etc.), but I’m not sure why they wouldn’t be able to respond to the auto_ping?

Sorry if this is confusing at all - I’m trying not to provide irrelevant data. Let me know if I need to provide more or if something isn’t clear.

Thank you again very much for your help,

Dave

0 Likes

#4

The port you see is the ephemeral client port. This is the outgoing port of the client initiated TCP connection. This is not a oprn listening port on the client.

All of tthat isnt Crossbar.io specfic, but just how TCP, well IP, works.

I recommend this book to learn about the basics: https://en.m.wikipedia.org/wiki/TCP/IP_Illustrated

Hope this helps

Cheers

Tobias

···

Am 15.02.2017 3:21 nachm. schrieb “Dave Barndt” dave....@gmail.com:

Hi Alex,

Thanks so much for replying.

In our environment, a remote site has the Autohan/Python WAMP client/component behind a firewall/modem. The backend is where Crossbar.io is running. The remote WAMP component initiates the connection to Crossbar.io (which is configured in its config.json to listen on port 8080). Since this is therefore an “outgoing” connection from the remote site across the firewall to Crossbar.io, this seems to work fine.

Now as I understand it, Crossbar.io is the entity that initiates the auto_ping feature to check client/component connections, is that right? With the following auto_ping options configured in Crossbar.io’s config.json:

“transports”: [

{

“id”: “web”,

“type”: “web”,

“endpoint”: {

“type”: “tcp”,

“port”: 8080

},

“paths”: {

“api”: {

“type”: “websocket”,

.

.

.

“options”: {

“enable_webstatus”: false,

“max_frame_size”: 1048576,

“max_message_size”: 1048576,

“auto_fragment_size”: 65536,

“fail_by_drop”: true,

“open_handshake_timeout”: 2500,

“close_handshake_timeout”: 1000,

"auto_ping_interval": 10000,

"auto_ping_timeout": 5000,

"auto_ping_size": 4,

“compression”: {

“deflate”: {

“request_no_context_takeover”: false,

“request_max_window_bits”: 11,

“no_context_takeover”: false,

“max_window_bits”: 11,

“memory_level”: 4

}

}

}

}

}

}

],

We observe the following messages in the syslog file:

Feb 8 16:39:52 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:39:52-0500 [Router 9870] dropping connection to peer tcp4:127.0.0.1:47492 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)

Feb 8 16:52:47 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:52:47-0500 [Router 9870] dropping connection to peer tcp4:10.250.0.2:37178 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)

Feb 8 16:55:35 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:55:35-0500 [Router 9870] dropping connection to peer tcp4:127.0.0.1:47501 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)

10.250.0.2 is the address of the remote site, and the reason for my question is that I noticed the port 37178, which obviously isn’t specified anywhere, and is centrainly not an open port on the firewall/modem for Crossbar.io to be able to reach/auto_ping the remote component. What am I missing?

Also, I just noticed the messages about the localhost (127.0.0.1) auto_pings failing. Not sure what that is? We do run a couple components on the same system as Crossbar.io as well (ex. components that register RPCs for the remote components to call, etc.), but I’m not sure why they wouldn’t be able to respond to the auto_ping?

Sorry if this is confusing at all - I’m trying not to provide irrelevant data. Let me know if I need to provide more or if something isn’t clear.

Thank you again very much for your help,

Dave

You received this message because you are subscribed to the Google Groups “Crossbar” group.

To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+unsubscribe@googlegroups.com.

To post to this group, send email to cross...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/5e98276b-7407-4010-b6af-7b40b1164777%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

0 Likes