The situation is, I wanna establish a QUIC connection based on quic-go from local to ECS server. The related tests using localhost are done both on local and remote device. That is:
#local: .$QUIC-GO-PATH/example/client/main -insecure -keylog ssl.log -qlog trial.log -v https://127.0.0.1:6121/demo/tile
#local: .$QUIC-GO-PATH/example/main -qlog -tcp -v
These tests are completed.
Now is the problem,when I start local-remote connection an error occurred:
#remote: .$QUIC-GO-PATH/example/main -qlog -tcp -v
#local: .$QUIC-GO-PATH/example/client/main -insecure -keylog ssl.log -qlog trial.log -v https://$REMOTE_IPADDR:6121/demo/tile
timeout: no recent network activity
When I go through a wireshark examination, it seems like the CRYPTO handshake never finishes:
Wireshark
Also client Qlog file atteched here:
Qlog file
Codes are all the same with https://github.com/lucas-clemente/quic-go
Help!
This problem has been solved.
Code $QUIC-GO-PATH/example/main.go has binded the port as a default onto 127.0.0.1:6121, which led to the problem that the server cannot get reached by client outside, just get this on server running:
-bind 0.0.0.0:6121
Related
I'm trying to connect to the Liquid exchange's Stream API with pusher. Documentation here
I have constructed a function that is in line with the Pusher library's documentation. Link to that here
My current code looks like this:
require 'pusher-client'
channels_client = PusherClient::Socket.new('LIQUID', {
ws_host: 'tap.liquid.com'
})
and running that gives me an error message of:
D, [2019-08-20Txx:xx:xx.xxxxxx #xxxxx] DEBUG -- : Binding
pusher:connection_established to pusher_global_channel
D, [2019-08-20Txx:xx:xx.xxxxxx #xxxxx] DEBUG -- : Binding
pusher:connection_disconnected to pusher_global_channel
D, [2019-08-20Txx:xx:xx.xxxxxx #xxxxx] DEBUG -- : Binding pusher:error
to pusher_global_channel
D, [2019-08-20Txx:xx:xx.xxxxxx #xxxxx] DEBUG -- : Binding pusher:ping
to pusher_global_channel
If I try to run this after the first command:
channels_client.connect
...it refuses to connect.
C:/Ruby26-x64/lib/ruby/gems/2.6.0/gems/pusher-client-0.6.2/lib/pusher-client/websocket.rb:17:in
`initialize': No connection could be made because the target machine
actively refused it. - connect(2) for "tap.liquid.com" port 80
(Errno::ECONNREFUSED)
The error comes from tcpsocket.new (Ruby https://ruby-doc.org/stdlib-2.5.1/libdoc/socket/rdoc/TCPSocket.html) in websocket line 17: https://github.com/pusher-community/pusher-websocket-ruby/blob/master/lib/pusher-client/websocket.rb
ws_host tap.liquid.com 80 seems to be invalid, https://pusher.com/docs/channels/library_auth_reference/pusher-websockets-protocol
I have tried using a secure connection, at least in the browser and got a 404 for ws and invalid request, which is good in this case, for https (https://tap.liquid.com/).
You need to configure ssl in the client configuration, but the pusher-client gem as well as one other I have found are pretty old. Maybe it is wise to switch to a more up-to-date library like https://github.com/pusher/pusher-http-ruby/blob/master/README.md
The example contains an option for activated SSL.
I'm working on OSX 10.10.5 and installed RabbitMQ using the tarball.
Running it via the script :
bash sbin/rabbitmq-server
The first time it ran, but after a restart, it is giving out this error :
ERROR: epmd error for host x1-6-20-0c-c8-19-6b-bd: timeout (timed out)
sbin/rabbitmqctl status returns this :
Status of node 'rabbit#x1-6-20-0c-c8-19-6b-bd' ...
Error: unable to connect to node 'rabbit#x1-6-20-0c-c8-19-6b-bd': nodedown
DIAGNOSTICS
===========
attempted to contact: ['rabbit#x1-6-20-0c-c8-19-6b-bd']
rabbit#x1-6-20-0c-c8-19-6b-bd:
* unable to connect to epmd (port 4369) on x1-6-20-0c-c8-19-6b-bd: timeout (timed out)
current node details:
- node name: 'rabbitmq-cli-25#x1-6-20-0c-c8-19-6b-bd'
- home dir: /Users/mohit
- cookie hash: FOxL2w3eJGpNkenIS5ebSw==
Please help me resolve this, thanks!
Update : Interestingly it works when i switch back to my personal network from the office network. Possibly something to do with port / network firewall?
Add a configuration file:
/etc/rabbitmq/rabbitmq-env.conf
Add a line as below:
NODENAME=rabbit#localhost
I try to download from a specific url using the command wget on the server Debian 6 as follows:
# wget http://ftp.ruby-lang.org/pub/ruby/2.1/ruby-2.1.2.tar.gz
the result:
--2016-05-25 16: 39: 15-- http://ftp.ruby-lang.org/pub/ruby/2.1/ruby-2.1.2.tar.gz
Resolving ftp.ruby-lang.org ... 221.186.184.75
Connecting to ftp.ruby-lang.org | 221.186.184.75 |: 80 ... failed: Connection timed out.
however, if I access the url using the browser, it can be accessed with a normal ...
I know why I do not use alternative via the browser earlier.
I just want to understand the intent of the problem, which is a new thing for me ..
so, why did this happen? iptables influence or proxy or other things I really do not understand.
someone might help in solving this problem.
Thanks in advance...
I'm experiencing an unresponsive socket in with my Puma setup after random time. Up to this point I don't have a clue what's causing the issue. I was hoping somebody over here can help we with some answers or point me in the right direction. I'm having the following setup:
I'm using the official docker ruby-2.2.3-slim image together with the latest puma release 2.15.3, I've also installed Nginx as a reverse proxy. But I'm already sure Nginx isn't the problem over here because and I've tried to verify if the socket was working using this script. And the socket wasn't working, I got a timeout over there as well so I could ignore Nginx.
This is a testing environment so the server isn't experiencing any extreme load, I've also check memory consumption it has still several GB's of free space so that couldn't be the issue either.
What triggered me to look at the puma socket was the error message I got in my Nginx error logging:
upstream timed out (110: Connection timed out) while reading response header from upstream
Also I couldn't find anything in the logs of puma indicating what is going wrong, over here are my puma setup:
threads 0, 16
app_dir = ENV.fetch('APP_HOME')
environment ENV['RAILS_ENV']
daemonize
bind "unix://#{app_dir}/sockets/puma.sock"
stdout_redirect "#{app_dir}/log/puma.stdout.log", "#{app_dir}/log/puma.stderr.log", true
pidfile "#{app_dir}/pids/puma.pid"
state_path "#{app_dir}/pids/puma.state"
activate_control_app
on_worker_boot do
require 'active_record'
ActiveRecord::Base.connection.disconnect! rescue ActiveRecord::ConnectionNotEstablished
ActiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[ENV['RAILS_ENV']])
end
And this it the output in my puma state file:
---
pid: 43
config: !ruby/object:Puma::Configuration
cli_options:
conf:
options:
:min_threads: 0
:max_threads: 16
:quiet: false
:debug: false
:binds:
- unix:///APP/sockets/puma.sock
:workers: 1
:daemon: true
:mode: :http
:before_fork: []
:worker_timeout: 60
:worker_boot_timeout: 60
:worker_shutdown_timeout: 30
:environment: staging
:redirect_stdout: "/APP/log/puma.stdout.log"
:redirect_stderr: "/APP/log/puma.stderr.log"
:redirect_append: true
:pidfile: "/APP/pids/puma.pid"
:state: "/APP/pids/puma.state"
:control_url: unix:///tmp/puma-status-1449260516541-37
:config_file: config/puma.rb
:control_url_temp: "/tmp/puma-status-1449260516541-37"
:control_auth_token: cda8879717be7a645ea323d931b88d4b
:tag: APP
The application itself is a Rails app on the latest version 4.2.5, it's deployed on GCE (Google Container Engine).
If somebody could give me some pointer's on how to debug this any further would be very much appreciated. Because now I don't see any output anywhere which could help me any further.
EDIT
I replaced the unix socket with tcp connection to Puma with the same result, still hangs after x time
I'd start with:
How many requests get processed successfully per instance of puma?
Make sure you log the beginning and end of each request with the thread id of the thread executing it, what do you see?
Not knowing more about your application, I'd say it's likely the threads get stuck doing some long/blocking calls without timeouts or spinning on some computation until the whole thread pool gets depleted.
We'll see.
I finally found out why my application was behaving the way it was.
After trying to use a tcp connection and switching to Unicorn I start looking into other possible sources.
That's when I thought maybe my connection to Google Cloud SQL could be the problem. Once I read the faq of Cloud SQL, they mentioned that you have to tweak you Compute instances to ensure they keep open your DB connection. So I performed the next steps they recommend and that solved the problem for me, I added them just in case:
# Display the current tcp_keepalive_time value.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
$ echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
# Apply the change.
$ sudo /sbin/sysctl --load=/etc/sysctl.conf
# Display the tcp_keepalive_time value to verify the change was applied.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
when i run from windows-7 with cygwin to connect CFEngine bersion 3.4.2
cf-agent -Bs 217.64.173.210
Challenge response from server 217.64.173.210/217.64.173.210 was incorrect!
I: Made in version 'not specified' of '/var/cfengine/inputs/update.cf' near line 47
!! Authentication dialogue with 217.64.173.210 failed
Challenge response from server 217.64.173.210/217.64.173.210 was incorrect!
I: Made in version 'not specified' of '/var/cfengine/inputs/update.cf' near line
and in /var/cfengine/inputs/update.cf on line 47 is
47 : perms => m("600"),
on cgwin in folder keys
/var/cfengine/ppkeys
localhost.pub
localhost.priv
root-MD5=b8825ba0a0e7017e34b15766d3b3ac58 (which is also at CFEngine Server Side shared ky)
on Cf-Engine Server Side
/var/cfengine/ppkeys/
localhost.priv
localhost.pub
root-MD5=b8825ba0a0e7017e34b15766d3b3ac58
With Regards
Sandeep
Did you also get the server to trust the client's key? like so:
cf-key -t root-MD5=b8825ba0a0e7017e34b15766d3b3ac58
(on the server)
Also, try restarting cf-serverd in verbose mode with the -v switch on the server, and watch what error messages you get on that end.