RabbitMq Shovel does not restart

[Frederik Gheysels]

We have a project where we run rabbitmq on vessels (oil tankers) sailing around the world.  The software that we run on those vessels needs to send and receive messages to the shore.  

We're using RabbitMQ on the vessel with the Shovel plugin which transfers those messages from the vessel to an Azure ServiceBus in the cloud.

Since those vessels are using sattelite connections, we're faced with shaky/bad network connections, so sometimes it happens that the Shovel is not able to connect to the Azure ServiceBus for quite some time.   When that happens, the shovel suddenly stops working and is stuck in a 'starting' state.

To deal with this, we have a service which runs on the vessel and periodically checks the state of the shovels.   If the state of the shovel is not 'running', then we restart the shovel by sending a HTTP request as described here: https://www.rabbitmq.com/shovel-dynamic.html#restarting

Unfortunately, this doesn't seem to work.   It looks like the shovel does not restart when the current state is 'starting', so that means that messages keep on piling up.

Is there a way to deal with this ?  Can we restart a shovel when the current state is 'starting' ? Are there other ways to solve this ?

If we restart the rabbitmq container itself, then the shovels are established again, but we actually rather not restart the rabbitmq container.

[Karl Nilsson]

Can you share any log files covering one of these events? Also RabbitMQ version is essential info. 

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/15c0a231-527e-41de-bb9a-68d5b0152fc1n%40googlegroups.com.

--

Karl Nilsson

[M K]

We cannot suggest anything without logs. You can always force restart all Shovels by restarting the plugin on the node that hosts them.

[Frederik Gheysels]

We're using RabbitMQ 3.8.8, running in a container in a k3s setup.

I have put some logs in attachment.

As you can see in the logs, the connection between rabbitmq & servicebus gets detached after some time; probably because there are no messages that must be transferred.  I think that can be normal behavior, but then there's also a crash-report in the logs.  After some time, the connection is brought up again.  I'd assume that, if there are no messages to be transferrerd, the connection is closed gracefully without a crash report.

Then, it sometimes happens that the shovel gets stuck in a 'starting' state.  It doesn't get terminated nor does it get in the running state.   

[fastapp_usr@eath-fastapp ~]$ curl -u MQAdmin:redacted http://localhost:30680/api/shovels/%2f/

[

{

  "node":"rabbit@rabbitmq-0",

  "timestamp":"2021-03-11 15:55:39",

  "name":"cloud2vessel", 

  "vhost":"/",

  "type":"dynamic",

  "state":"running",

  "src_uri":

  "amqps://cloud2vessel.consume:redacted.servicebus.windows.net:5671/?sasl=plain",

  "src_protocol":"amqp10",

  "dest_protocol":"amqp091",

  "dest_uri":"amqp://localhost",

  "src_address":

  "tovessels\\subscriptions\\9829801-eath",

  "dest_queue":"datasync-fromcloud"

},

{

  "node":"rabbit@rabbitmq-0",

  "timestamp":"2021-03-12 9:58:44",

  "name":"vessel2cloud",

  "vhost":"/",

  "type":"dynamic",

  "state":"starting"

}

]

When I get into the logs around that time, I can see this:

2021-03-12 09:56:44.970 [error] <0.23513.2> Supervisor {<0.23513.2>,amqp10_client_connection_sup} had child connection started with amqp10_client_connection:start_link(<0.23513.2>, #{address

 => "fast-acc-we-datasyncbus.servicebus.windows.net",hostname => <<"fast-acc-we-datasync...">>,...}) at <0.23514.2> exit with reason reached_max_restart_intensity in context shutdown

2021-03-12 09:56:44.971 [info] <0.23494.2> closing AMQP connection <0.23494.2> (127.0.0.1:59543 -> 127.0.0.1:5672 - Shovel vessel2cloud, vhost: '/', user: 'MQAdmin')

2021-03-12 09:58:44.977 [info] <0.24480.2> accepting AMQP connection <0.24480.2> (127.0.0.1:50499 -> 127.0.0.1:5672)

2021-03-12 09:58:44.985 [info] <0.24480.2> Connection <0.24480.2> (127.0.0.1:50499 -> 127.0.0.1:5672) has a client-provided name: Shovel vessel2cloud

2021-03-12 09:58:44.986 [info] <0.24480.2> connection <0.24480.2> (127.0.0.1:50499 -> 127.0.0.1:5672 - Shovel vessel2cloud): user 'MQAdmin' authenticated and granted access to vhost '/'

2021-03-12 10:00:01.656 [error] <0.24477.2> ** Generic server <0.24477.2> terminating 

** Last message in was {'EXIT',<0.24474.2>,shutdown}

** When Server state == {state,amqp_network_connection,{state,#Port<0.13627>,<<"client 127.0.0.1:50499 -> 127.0.0.1:5672">>,10,<0.24483.2>,131072,<0.24476.2>,undefined,false},<0.24482.2>,{am

qp_params_network,<<"MQAdmin">>,{encrypted,<<"UJyOo0PClUgiPn07T9dliqRQXXBxt+ocuCeMZ7dLpPtnb26rJHZEmIYWy7SBWQr7aVHbEBtWTwVpGCHoGmjLyO1MG2EST9gStAhGrFoXYUs=">>},<<"/">>,"localhost",5672,2047,0

,10,60000,none,[#Fun<amqp_uri.11.12217282>,#Fun<amqp_uri.11.12217282>],[{<<"connection_name">>,longstr,<<"Shovel vessel2cloud">>}],[]},2047,[{<<"capabilities">>,table,[{<<"publisher_confirms

">>,bool,true},{<<"exchange_exchange_bindings">>,bool,true},{<<"basic.nack">>,bool,true},{<<"consumer_cancel_notify">>,bool,true},{<<"connection.blocked">>,bool,true},{<<"consumer_priorities

">>,bool,true},{<<"authentication_failure_close">>,bool,true},{<<"per_consumer_qos">>,bool,true},{<<"direct_reply_to">>,bool,true}]},{<<"cluster_name">>,longstr,<<"rab...@rabbitmq-0.rabbitmq

.fast.svc.cluster.local">>},{<<"copyright">>,longstr,<<"Copyright (c) 2007-2020 VMware, Inc. or its affiliates.">>},{<<"information">>,longstr,<<"Licensed under the MPL 2.0. Website: https:/

/rabbitmq.com">>},{<<"platform">>,longstr,<<"Erlang/OTP 23.1">>},{<<"product">>,longstr,<<"RabbitMQ">>},{<<"version">>,longstr,<<"3.8.8">>}],none,false}

** Reason for termination ==

** "stopping because dependent process <0.24474.2> died: shutdown"

2021-03-12 10:00:01.656 [error] <0.24477.2> CRASH REPORT Process <0.24477.2> with 0 neighbours exited with reason: "stopping because dependent process <0.24474.2> died: shutdown" in gen_serv

er:handle_common_reply/8 line 796

2021-03-12 10:00:01.657 [error] <0.24475.2> Supervisor {<0.24475.2>,amqp_connection_sup} had child connection started with amqp_gen_connection:start_link(<0.24476.2>, {amqp_params_network,<<

"MQAdmin">>,{encrypted,<<"UJyOo0PClUgiPn07T9dliqRQXXBxt+ocuCeMZ7dLpPtnb26rJ...">>},...}) at <0.24477.2> exit with reason "stopping because dependent process <0.24474.2> died: shutdown" in co

ntext child_terminated

2021-03-12 10:00:01.657 [error] <0.24475.2> Supervisor {<0.24475.2>,amqp_connection_sup} had child connection started with amqp_gen_connection:start_link(<0.24476.2>, {amqp_params_network,<<

"MQAdmin">>,{encrypted,<<"UJyOo0PClUgiPn07T9dliqRQXXBxt+ocuCeMZ7dLpPtnb26rJ...">>},...}) at <0.24477.2> exit with reason reached_max_restart_intensity in context shutdown

2021-03-12 10:00:01.658 [warning] <0.24480.2> closing AMQP connection <0.24480.2> (127.0.0.1:50499 -> 127.0.0.1:5672 - Shovel vessel2cloud, vhost: '/', user: 'MQAdmin'):

client unexpectedly closed TCP connection

2021-03-12 10:00:01.668 [info] <0.24620.2> accepting AMQP connection <0.24620.2> (127.0.0.1:39413 -> 127.0.0.1:5672)

2021-03-12 10:00:01.676 [info] <0.24620.2> Connection <0.24620.2> (127.0.0.1:39413 -> 127.0.0.1:5672) has a client-provided name: Shovel vessel2cloud

2021-03-12 10:00:01.677 [info] <0.24620.2> connection <0.24620.2> (127.0.0.1:39413 -> 127.0.0.1:5672 - Shovel vessel2cloud): user 'MQAdmin' authenticated and granted access to vhost '/'

2021-03-12 10:00:55.562 [error] <0.24499.2> Supervisor {<0.24499.2>,amqp10_client_connection_sup} had child reader started with amqp10_client_frame_reader:start_link(<0.24499.2>, #{address =

> "fast-acc-we-datasyncbus.servicebus.windows.net",hostname => <<"fast-acc-we-datasync...">>,...}) at undefined exit with reason etimedout in context start_error

2021-03-12 10:00:55.562 [error] <0.24501.2> CRASH REPORT Process <0.24501.2> with 0 neighbours exited with reason: etimedout in gen_statem:init_result/8 line 806

2021-03-12 10:03:06.634 [error] <0.24709.2> Supervisor {<0.24709.2>,amqp10_client_connection_sup} had child reader started with amqp10_client_frame_reader:start_link(<0.24709.2>, #{address =

> "fast-acc-we-datasyncbus.servicebus.windows.net",hostname => <<"fast-acc-we-datasync...">>,...}) at undefined exit with reason etimedout in context start_error

2021-03-12 10:03:06.634 [error] <0.24711.2> CRASH REPORT Process <0.24711.2> with 0 neighbours exited with reason: etimedout in gen_statem:init_result/8 line 806

2021-03-12 10:03:06.634 [error] <0.24612.2> Shovel 'vessel2cloud' could not connect to destination

2021-03-12 10:03:06.636 [error] <0.24611.2> Supervisor {<0.24611.2>,rabbit_shovel_dyn_worker_sup} had child {<<"/">>,<<"vessel2cloud">>} started with rabbit_shovel_worker:start_link(dynamic,

 {<<"/">>,<<"vessel2cloud">>}, [{<<"ack-mode">>,<<"on-confirm">>},{<<"dest-address">>,<<"fromvessels">>},{<<"dest-protocol">>,<<"...">>},...]) at <0.24612.2> exit with reason {shutdown,norma

l} in context child_terminated

We thought to create a service which restarts the shovel when this occurs, but we're unable to restart the shovel in that case.  (We perform a DELETE request to api/shovels/vhost/{hostname}/{shovelname}/restart but the shovel doesn't restart)

Op vrijdag 12 maart 2021 om 03:01:43 UTC+1 schreef michael....@gmail.com:

[Frederik Gheysels]

Restarting he shovel plugin might be something that we can try, as we're currently restarting the comple rabbitmq node when this issue arises.

How can we restart the shovel plugin ?  Is this possible via an API call for instance ?

Op vrijdag 12 maart 2021 om 03:01:43 UTC+1 schreef michael....@gmail.com:

We cannot suggest anything without logs. You can always force restart all Shovels by restarting the plugin on the node that hosts them.

[Frederik Gheysels]

Some additional information:

The shovel endpoint that connects to Azure Service Bus uses AMQP 1.0; the part that connects to RabbitMQ uses AMQP 0.9.1.

As can be seen in my previous message, we have defined 2 shovels:  cloud2vessel and vessel2cloud.  It looks like the vessel2cloud shovel is the one that is failing most.  This shovel has RabbitMQ as the source, and Azure ServiceBus as the destination.

Op vrijdag 12 maart 2021 om 13:40:55 UTC+1 schreef Frederik Gheysels:

[kjnilsson]

Hi,

I replied last week but for some strange reason the account I used had some policy not to allow it so my messages got auto-removed :)

Anyhow from the error logs I can see that there is a crash when the source (Azure) closes the connection and the amqp 1.0 client is shutting down. This is most likely harmless but I will raise an issue to handle this better.

The second issue when your shovel is stuck in the starting state is a TCP connect timeout (etimedout) - the erlang tcp connect function doesn't set a timeout so this timeout comes from the underlying OS TCP stack. This is most likely due to the latency of the connection or possibly other issues. Perhaps Azure has a firewall that thinks the reconnection attempts look a bit DDOS-y and stops replying. A tcpdump capture when the shovel is in this state _may_ help getting further into as to why the TCP connect call times out.

Cheers

Karl

[kjnilsson]

Here is a link to the shovel crash part of the issue: https://github.com/rabbitmq/rabbitmq-server/issues/2893

[Frederik Gheysels]

Thanks for your response.

If the issue arises again, I'll try to get a tcpdump and post it here.

Azure might indeed think that the reconnect attempts are a bit DDOS-y.  Would increasing the reconnect-delay help this ?  (We've set this now at 10 seconds).

Op maandag 15 maart 2021 om 10:47:34 UTC+1 schreef kjnilsson:

[kjnilsson]

10s seems long enough to not seem DDOS-y but who knows :) - a tcpdump would at least tell us if any packets come back at all, if not then perhaps have a chat with Microsoft. Do the connection issues happen immediately after the link was closed by the remote?

[Frederik Gheysels]

We currently see the same situation occuring on one of our vessels.   This vessel is currently connected with a 'backup sattelite connection', so the connection to the cloud has a bad quality in terms of latency and stability.

This is the log of rabbitmq:

"redacted-datasyncbus.servicebus.windows.net",hostname => <<"redacted-datasync...">>,...}) at <0.171.13> exit with reason no function clause matching amqp10_client_connection:close_se

nt(info, {'EXIT',<0.145.13>,{outbound_link_detached,{'v1_0.error',{symbol,<<"amqp:link:detach-forced">>},...}}}, {state,2,<0.170.13>,#Ref<0.394721683.768344065.70286>,<0.179.13>,[{<0.145.13>

,#Ref<0.394721683.768344065.70285>}],...}) line 298 in context child_terminated

2021-03-15 06:13:40.998 [error] <0.170.13> Supervisor {<0.170.13>,amqp10_client_connection_sup} had child connection started with amqp10_client_connection:start_link(<0.170.13>, #{address =>

 "redacted-datasyncbus.servicebus.windows.net",hostname => <<"redacted-datasync...">>,...}) at <0.171.13> exit with reason reached_max_restart_intensity in context shutdown

2021-03-15 06:15:41.000 [info] <0.1150.13> accepting AMQP connection <0.1150.13> (127.0.0.1:60087 -> 127.0.0.1:5672)

2021-03-15 06:15:41.005 [info] <0.1150.13> Connection <0.1150.13> (127.0.0.1:60087 -> 127.0.0.1:5672) has a client-provided name: Shovel vessel2cloud

2021-03-15 06:15:41.006 [info] <0.1150.13> connection <0.1150.13> (127.0.0.1:60087 -> 127.0.0.1:5672 - Shovel vessel2cloud): user 'MQAdmin' authenticated and granted access to vhost '/'

2021-03-15 06:15:47.011 [error] <0.1167.13> Supervisor {<0.1167.13>,amqp10_client_connection_sup} had child reader started with amqp10_client_frame_reader:start_link(<0.1167.13>, #{address =

> "redacted-datasyncbus.servicebus.windows.net",hostname => <<"redacted-datasync...">>,...}) at undefined exit with reason nxdomain in context start_error

2021-03-15 06:15:47.011 [error] <0.1169.13> CRASH REPORT Process <0.1169.13> with 0 neighbours exited with reason: nxdomain in gen_statem:init_result/8 line 806

2021-03-15 06:15:47.012 [error] <0.1142.13> Shovel 'vessel2cloud' could not connect to destination

2021-03-15 06:15:47.013 [error] <0.819.0> Supervisor {<0.819.0>,rabbit_shovel_dyn_worker_sup} had child {<<"/">>,<<"vessel2cloud">>} started with rabbit_shovel_worker:start_link(dynamic, {<<

"/">>,<<"vessel2cloud">>}, [{<<"ack-mode">>,<<"on-confirm">>},{<<"dest-address">>,<<"fromvessels">>},{<<"dest-protocol">>,<<"...">>},...]) at <0.1142.13> exit with reason {shutdown,normal} i

n context child_terminated

2021-03-15 06:15:47.013 [info] <0.1150.13> closing AMQP connection <0.1150.13> (127.0.0.1:60087 -> 127.0.0.1:5672 - Shovel vessel2cloud, vhost: '/', user: 'MQAdmin')

2021-03-15 06:17:47.019 [info] <0.1342.13> accepting AMQP connection <0.1342.13> (127.0.0.1:38733 -> 127.0.0.1:5672)

2021-03-15 06:17:47.024 [info] <0.1342.13> Connection <0.1342.13> (127.0.0.1:38733 -> 127.0.0.1:5672) has a client-provided name: Shovel vessel2cloud

2021-03-15 06:17:47.025 [info] <0.1342.13> connection <0.1342.13> (127.0.0.1:38733 -> 127.0.0.1:5672 - Shovel vessel2cloud): user 'MQAdmin' authenticated and granted access to vhost '/'

2021-03-15 08:19:36.304 [warning] <0.22760.12> AMQP 1.0 connection socket was closed, connection state: 'expecting_frame_header'

2021-03-15 08:19:36.304 [error] <0.22757.12> Shovel 'cloud2vessel' in virtual host '/' decided to stop due a message from source: {inbound_conn_closed,shutdown}

2021-03-15 08:19:36.305 [info] <0.22757.12> Shovel cloud2vessel source connection closed. Reason: shutdown

2021-03-15 08:19:36.305 [error] <0.22757.12> Shovel 'cloud2vessel' in virtual host '/' is stopping, reason: {inbound_conn_closed,shutdown}

2021-03-15 08:19:36.307 [error] <0.22757.12> ** Generic server <0.22757.12> terminating

** Last message in was {amqp10_event,{connection,<0.22759.12>,{closed,shutdown}}}

** When Server state == {state,undefined,undefined,undefined,undefined,{<<"/">>,<<"cloud2vessel">>},dynamic,#{ack_mode => on_confirm,dest => #{current => {<0.22778.12>,<0.22794.12>,<<"amqp:/

/localhost">>},dest_queue => <<"datasync-fromcloud">>,fields_fun => #Fun<rabbit_shovel_parameters.11.81699962>,module => rabbit_amqp091_shovel,props_fun => #Fun<rabbit_shovel_parameters.12.8

1699962>,resource_decl => #Fun<rabbit_shovel_parameters.10.81699962>,unacked => #{},uris => ["amqp://MQAdmin:password@localhost"]},name => <<"cloud2vessel">>,reco

nnect_delay => 120,shovel_type => dynamic,source => #{current => #{conn => <0.22759.12>,link => {link_ref,receiver,<0.22775.12>,0},session => <0.22775.12>,uri => "amqps://cloud2vessel.consum

e:lmYIdIl9aXT0CX624XiIqkNS9b5JuaoDKYeB2dxoA%2B8%3...@redacted-datasyncbus.servicebus.windows.net:5671/?sasl=plain"},delete_after => never,last_acked_tag => -1,module => rabbit_amqp10_shovel

,prefetch_count => 1000,remaining => unlimited,remaining_unacked => unlimited,source_address => <<"tovessels\\subscriptions\\9461764-esof">>,uris => ["amqps://cloud2vessel.consume:lmYIdIl9aX

T0CX624XiIqkNS9b5JuaoDKYeB2dxoA%2B8%3...@redacted-datasyncbus.servicebus.windows.net:5671/?sasl=plain"]}},undefined,undefined,undefined,undefined,undefined}

** Reason for termination == 

** {inbound_conn_closed,shutdown}

2021-03-15 08:19:36.307 [error] <0.22757.12> CRASH REPORT Process <0.22757.12> with 0 neighbours exited with reason: {inbound_conn_closed,shutdown} in gen_server2:terminate/3 line 1183

2021-03-15 08:19:36.308 [error] <0.822.0> Supervisor {<0.822.0>,rabbit_shovel_dyn_worker_sup} had child {<<"/">>,<<"cloud2vessel">>} started with rabbit_shovel_worker:start_link(dynamic, {<<

"/">>,<<"cloud2vessel">>}, [{<<"ack-mode">>,<<"on-confirm">>},{<<"dest-protocol">>,<<"amqp091">>},{<<"dest-queue">>,<<"datasy...">>},...]) at <0.22757.12> exit with reason {inbound_conn_clos

ed,shutdown} in context child_terminated

2021-03-15 08:19:36.308 [info] <0.22783.12> closing AMQP connection <0.22783.12> (127.0.0.1:44305 -> 127.0.0.1:5672 - Shovel cloud2vessel, vhost: '/', user: 'MQAdmin')

When I get the state of the shovels:

[fastapp_usr@esof-fastapp ~]$ curl -u MQAdmin:<pwd> http://localhost:30680/api/shovels/%2f/

[{"node":"rabbit@rabbitmq-0","timestamp":"2021-03-15 8:21:36","name":"cloud2vessel","vhost":"/","type":"dynamic","state":"starting"},{"node":"rabbit@rabbitmq-0","timestamp":"2021-03-15 6:17:

47","name":"vessel2cloud","vhost":"/","type":"dynamic","state":"starting"}]

This is the tcpdump output; what kind of things are of interest ?

[fastapp_usr@esof-fastapp ~]$ sudo tcpdump -v

dropped privs to tcpdump

tcpdump: listening on vethb23055ec, link-type EN10MB (Ethernet), capture size 262144 bytes

09:36:18.386536 IP (tos 0x0, ttl 64, id 42542, offset 0, flags [DF], proto TCP (6), length 1049)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [P.], cksum 0x41eb (incorrect -> 0x6ead), seq 171990188:171991197, ack 1569061680, win 589, length 1009

09:36:19.624188 IP (tos 0x0, ttl 105, id 65334, offset 0, flags [DF], proto TCP (6), length 436)

    23.96.28.38.https > 10.42.0.48.43796: Flags [P.], cksum 0xae54 (correct), seq 1:397, ack 1009, win 2048, length 396

09:36:19.624211 IP (tos 0x0, ttl 64, id 42543, offset 0, flags [DF], proto TCP (6), length 40)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [.], cksum 0x3dfa (incorrect -> 0xfda3), ack 397, win 610, length 0

09:36:20.696081 IP (tos 0x0, ttl 105, id 65335, offset 0, flags [DF], proto TCP (6), length 436)

    23.96.28.38.https > 10.42.0.48.43796: Flags [P.], cksum 0xae54 (correct), seq 1:397, ack 1009, win 2048, length 396

09:36:20.696104 IP (tos 0x0, ttl 64, id 42544, offset 0, flags [DF], proto TCP (6), length 52)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [.], cksum 0x3e06 (incorrect -> 0x1494), ack 397, win 610, options [nop,nop,sack 1 {1:397}], length 0

09:36:23.385207 IP (tos 0x0, ttl 64, id 42545, offset 0, flags [DF], proto TCP (6), length 1049)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [P.], cksum 0x41eb (incorrect -> 0x9b7c), seq 1009:2018, ack 397, win 610, length 1009

09:36:25.252313 IP (tos 0x0, ttl 64, id 42546, offset 0, flags [DF], proto TCP (6), length 1049)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [P.], cksum 0x41eb (incorrect -> 0x9b7c), seq 1009:2018, ack 397, win 610, length 1009

09:36:25.644663 IP (tos 0x0, ttl 105, id 65336, offset 0, flags [DF], proto TCP (6), length 436)

    23.96.28.38.https > 10.42.0.48.43796: Flags [P.], cksum 0xfb94 (correct), seq 397:793, ack 2018, win 2044, length 396

09:36:25.644694 IP (tos 0x0, ttl 64, id 42547, offset 0, flags [DF], proto TCP (6), length 40)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [.], cksum 0x3dfa (incorrect -> 0xf810), ack 793, win 632, length 0

09:36:25.736284 IP (tos 0x0, ttl 105, id 65337, offset 0, flags [DF], proto TCP (6), length 52)

    23.96.28.38.https > 10.42.0.48.43796: Flags [.], cksum 0xe2c9 (correct), ack 2018, win 2044, options [nop,nop,sack 1 {1009:2018}], length 0

09:36:28.385140 IP (tos 0x0, ttl 64, id 42548, offset 0, flags [DF], proto TCP (6), length 1049)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [P.], cksum 0x41eb (incorrect -> 0xb82e), seq 2018:3027, ack 793, win 632, length 1009

09:36:29.693048 IP (tos 0x0, ttl 105, id 65338, offset 0, flags [DF], proto TCP (6), length 436)

    23.96.28.38.https > 10.42.0.48.43796: Flags [P.], cksum 0xce55 (correct), seq 793:1189, ack 3027, win 2048, length 396

09:36:29.693140 IP (tos 0x0, ttl 64, id 42549, offset 0, flags [DF], proto TCP (6), length 40)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [.], cksum 0x3dfa (incorrect -> 0xf27e), ack 1189, win 653, length 0

09:36:30.682758 IP (tos 0x0, ttl 105, id 65339, offset 0, flags [DF], proto TCP (6), length 436)

    23.96.28.38.https > 10.42.0.48.43796: Flags [P.], cksum 0xce55 (correct), seq 793:1189, ack 3027, win 2048, length 396

09:36:30.682834 IP (tos 0x0, ttl 64, id 42550, offset 0, flags [DF], proto TCP (6), length 52)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [.], cksum 0x3e06 (incorrect -> 0x033f), ack 1189, win 653, options [nop,nop,sack 1 {793:1189}], length 0

09:36:33.385205 IP (tos 0x0, ttl 64, id 42551, offset 0, flags [DF], proto TCP (6), length 1049)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [P.], cksum 0x41eb (incorrect -> 0x0388), seq 3027:4036, ack 1189, win 653, length 1009

09:36:34.731838 IP (tos 0x0, ttl 105, id 65340, offset 0, flags [DF], proto TCP (6), length 436)

    23.96.28.38.https > 10.42.0.48.43796: Flags [P.], cksum 0x5a76 (correct), seq 1189:1585, ack 4036, win 2044, length 396

09:36:34.731860 IP (tos 0x0, ttl 64, id 42552, offset 0, flags [DF], proto TCP (6), length 40)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [.], cksum 0x3dfa (incorrect -> 0xeceb), ack 1585, win 675, length 0

09:36:35.722055 IP (tos 0x0, ttl 105, id 65341, offset 0, flags [DF], proto TCP (6), length 436)

    23.96.28.38.https > 10.42.0.48.43796: Flags [P.], cksum 0x5a76 (correct), seq 1189:1585, ack 4036, win 2044, length 396

09:36:35.722078 IP (tos 0x0, ttl 64, id 42553, offset 0, flags [DF], proto TCP (6), length 52)

    10.42.0.48.43796 > 23.96.28.38.https: Flags [.], cksum 0x3e06 (incorrect -> 0xfa93), ack 1585, win 675, options [nop,nop,sack 1 {1189:1585}], length 0

^C

20 packets captured

20 packets received by filter

0 packets dropped by kernel

Op maandag 15 maart 2021 om 11:08:16 UTC+1 schreef kjnilsson: