This is the output of the three way handshake of a TCP connection:
23:40:36.011400 IP 10.1.1.11.44733 > 73.5.9.44.80: Flags [S], seq 106492654, win 64240, optio0
23:40:36.013994 IP 73.5.9.44.80 > 10.1.1.11.44733: Flags [S.], seq 712839050, ack 106492655, 0
23:40:36.014026 IP 10.1.1.11.44733 > 73.5.9.44.80: Flags [.], ack 1, win 502, options [nop,no0
Inside the brackets are the flags for each packet: [S] [S.] [.]
The man page for tcpdump describes these values:
The general format of a TCP protocol line is:
src > dst: Flags [tcpflags], seq data-seqno, ack ackno, win window,
urg urgent, options [opts], length len
Src and dst are the source and destination IP addresses and ports.
Tcpflags are some combination of S (SYN), F (FIN), P (PUSH), R (RST),
U (URG), W (ECN CWR), E (ECN-Echo) or '.' (ACK), or 'none' if no flags
are set
Why is the ACK flag represented by a period (.) instead of an A?
Some googling lead me to this:
https://github.com/the-tcpdump-group/tcpdump/issues/319
Which implies the reason for not using an A is described here:
http://article.gmane.org/gmane.network.tcpdump.devel/6383
But this link has been giving me a 522 error =/
I configured Artemis to redeliver faild messages like this (broker.xml):
<address-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<!-- with -1 only the global-max-size is in use for limiting -->
<max-size-bytes>-1</max-size-bytes>
<message-counter-history-day-limit>10</message-counter-history-day-limit>
<address-full-policy>PAGE</address-full-policy>
<auto-create-queues>true</auto-create-queues>
<auto-create-addresses>true</auto-create-addresses>
<auto-create-jms-queues>true</auto-create-jms-queues>
<auto-create-jms-topics>true</auto-create-jms-topics>`enter code here`
<max-delivery-attempts>3</max-delivery-attempts>
<redelivery-delay>30000</redelivery-delay>
<max-redelivery-delay>30000</max-redelivery-delay>
</address-setting>
[...]
<address-setting match="email">
<redelivery-delay-multiplier>3</redelivery-delay-multiplier>
<redelivery-delay>60000</redelivery-delay>
<max-redelivery-delay>86400000</max-redelivery-delay>
</address-setting>
[...]
<addresses>
<address name="email">
<anycast>
<queue name="email" />
</anycast>
</address>
</addresses>
I use Springboot as sender and receiver. After sending a message to the queue it appears in artemis' queue and the receiver is called. The processing fails. But instead of putting the message back to the queue and try to redeliver it, this happens:
09:57:37,672 WARN [org.apache.activemq.artemis.core.server] AMQ222149: Message Reference[53]:RELIABLE:CoreMessage[messageID=53,durable=true,userID=null,priority=4, timestamp=Mon Jan 29 09:57:37 UTC 2018,expiration=0, durable=
true, address=email,properties=TypedProperties[__HDR_dlqDeliveryFailureCause=java.lang.Throwable: Delivery[1] exceeds redelivery policy limit:RedeliveryPolicy {destination = null, collisionAvoidanceFactor = 0.15, maximumRedeli
veries = 0, maximumRedeliveryDelay = -1, initialRedeliveryDelay = 1000, useCollisionAvoidance = false, useExponentialBackOff = false, backOffMultiplier = 5.0, redeliveryDelay = 1000, preDispatchCheck = true}, cause:null,__HDR_
BROKER_IN_TIME=1517219857591,interaction_id=b0b5cb2c618f4605a11ad599dfd7f54b,_AMQ_ROUTING_TYPE=1,__HDR_ARRIVAL=0,__HDR_GROUP_SEQUENCE=0,__HDR_COMMAND_ID=36,__HDR_MARSHALL_PROP=[0000 0001 000E 696E 7465 7261 6374 696F 6E5F 6964
0900 2062 3062 3563 6232 6336 3138 6634 3630 3561 3131 6164 3539 3964 6664 3766 3534 62),__HDR_PRODUCER_ID=[0000 003D 7B01 0029 4944 3A64 652D 6164 6E2D 6266 786A 6E63 322D 3532 3232 ... 37 3231 3934 3238 3032 362D 313A 3100
0000 0000 0000 0100 0000 0000 0000 09),_AMQ_DUPL_ID=ID:de-adn-bfxjnc2-52228-1517219428026-1:1:9:1:3,__HDR_MESSAGE_ID=[0000 0050 6E00 017B 0100 2949 443A 6465 2D61 646E 2D62 6678 6A6E 6332 2D35 ... 0000 0000 0001 0000 0000 0
000 0009 0000 0000 0000 0003 0000 0000 0000 0000),__HDR_DROPPABLE=false]]#693556289 has reached maximum delivery attempts, sending it to Dead Letter Address DLQ from email
It looks to me as if my configuration is completely ignored.
Can anybody tell me, what is wron in my configuration?
I used usbmon to analyse usb packets, and implement it in webusb however I wasn't able to find a solution for this. This is what Sane send to usb :
S Co:1:074:0 s 02 01 0000 0081 0000 0
C Co:1:074:0 0 0
S Co:1:074:0 s 02 01 0000 0002 0000 0
C Co:1:074:0 0 0
Which is similar to a controlTransferOut() command, with requestType=Standard, recipient: 'endpoint', request: 1, index: 0x00, value:129
The 'value' here is very tricky since all other parameters should be correct according to documentation, however sending value:129 should send something like :
S Co:1:074:0 s 02 01 0081 0000 0000 0
However what I got instead is :
Uncaught (in promise) DOMException: The specified endpoint number is out of range.
While value is an unsigned short, which is max 0xffff ! So obviously value should be 0, and next nibble 0x0081. My question is how to trigger a Control Output (Co) with value in second nibble ?
The code is something like this :
navigator.usb.requestDevice({ filters: [{ vendorId: 0x1083}] })
.then(selectedDevice => {
device = selectedDevice;
return device.open(); // Begin a session.
})
.then(() => device.selectConfiguration(1))
.then(() => device.claimInterface(0))
.then(() => device.controlTransferOut({
requestType: 'standard',
recipient: 'endpoint',
request: 0x00,
value: 129,
index: 0x00}))
All other combinations are sent with response "Stall" for example (class, interface : 21 - vendor, device : 40 ...etc).
Device description and Endpoint descriptor are available here
Thank you
Just found it, request should be :
device.controlTransferOut({
requestType: 'standard',
recipient: 'endpoint',
request: 1,
value: 0,
index: 129})
This give :
S Co:1:075:0 s 02 01 0000 0081 0000 0
C Co:1:075:0 0 0
Which is exactly what I need.
I was flooded with a primitive json body for fcm:
Body = mochijson2:encode([ {<<"operation">>, <<"create">>},{<<"notification_key_name">>, <<"console group">>},{<<"registration_ids">>, [<<"02aa6XXXX3c9b6d">>,<<"APA91bGtaXXXXXXXXXXXXoi4UH8vIdZk1X67A_9izpSFSHV3BXxdIwG">>]}]).
And send POST-request to create group according to documentation:
httpc:request(post, {Url, [{"Authorization", KeyApi}, {"project_id", ProjectId}], "application/json", Body},[{timeout, 5000}], []).
But I got error BadJsonFormat:
{ok,{{"HTTP/1.1",400,"Bad Request"},
[{"cache-control","private, max-age=0"},
{"date","Fri, 10 Mar 2017 16:19:37 GMT"},
{"accept-ranges","none"},
{"server","GSE"},
{"vary","Accept-Encoding"},
{"content-length","25"},
{"content-type","application/json; charset=UTF-8"},
{"expires","Fri, 10 Mar 2017 16:19:37 GMT"},
{"x-content-type-options","nosniff"},
{"x-frame-options","SAMEORIGIN"},
{"x-xss-protection","1; mode=block"},
{"alt-svc","quic=\":443\"; ma=2592000; v=\"36,35,34\""}],
"{\"error\":\"BadJsonFormat\"}"}}
But mochijson2:decode(Body) works fine, and it looks like properly formed json, but I get the error BadJsonFormat anyway.
What was wrong? How can I fix this?
The function mochijson2:encode doesn't return a string or a binary, but an iolist:
1> Body = mochijson2:encode([ {<<"operation">>, <<"create">>},{<<"notification_key_name">>, <<"console group">>},{<<"registration_ids">>, [<<"02aa6XXXX3c9b6d">>,<<"APA91bGtaXXXXXXXXXXXXoi4UH8vIdZk1X67A_9izpSFSHV3BXxdIwG">>]}]).
[123,
[34,<<"operation">>,34],
58,
[34,<<"create">>,34],
44,
[34,<<"notification_key_name">>,34],
58,
[34,<<"console group">>,34],
44,
[34,<<"registration_ids">>,34],
58,
[91,
[34,<<"02aa6XXXX3c9b6d">>,34],
44,
[34,<<"APA91bGtaXXXXXXXXXXXXoi4UH8vIdZk1X67A_9izpSF"...>>,
34],
93],
125]
There is nothing wrong with that, by itself. Using iolists instead of strings or binaries means that you don't have to create an expensive flat data structure, that you would just write to a file or a socket, after which you'd throw it away. Function like file:write_file and gen_tcp:send handle iolists just as well as strings or binaries.
However, httpc:request doesn't!
Let's test that by starting a server on port 1111 with netcat in a shell:
$ nc -l 1111
And then make a request from the Erlang shell:
3> httpc:request(post, {"http://127.0.0.1:1111", [], "application/json", Body},[{timeout, 5000}], []).
The netcat server shows this output:
POST / HTTP/1.1
content-type: application/json
content-length: 13
te:
host: 127.0.0.1:1111
connection: keep-alive
{"operation":"create",....
Note that the content-length is 13 instead of 159! httpc:request is able to send the iolist, but it uses the function length instead of iolist_size to generate the content-length header, and as a result the server only considers the first 13 bytes of the JSON object, which is not valid JSON by itself.
The solution is to pass iolist_to_binary(Body) to httpc:request instead of just Body.
Can somebody explain the SR/RR parts of this tcpdump output?
Example: tcpdump -n udp -x port 5091 and less 129 -T rtcp
16:58:15.034159 IP 1.2.3.4.5091 > 10.2.3.4.45041: sr #3665059093.56 3025985984 1003p 160480b 3l 1012s 12j #23811.54+1.80 sdes 12
16:58:23.753766 IP 1.2.3.4.5091 > 10.2.3.4.45041: rr 5l 1446s 24j #23820.57+1.49 bye 8
Thanks!
I found the information here
I believe the values (e.g. packet loss) will be seen as "missing" if 0.
Adding -vvv for further verbose and you get something along the lines of:
sr 608743728 #3665062971.29 3057007839 124p 19840b 458089647 2l 135s 7j #0.00+0.00 sdes 12 608743728
Which will be
rtcp_type;ssrc_sender;ntp_timestamp_reference;media_timestamp_reference;num_packets_sent;num_bytes_sent;ssrc_source;packet_loss;ext_last_seq_recieved;jitter;some_ts;no_bytes_of_source_desc;ssrc_sender