I am analyzing the end of various TCP sessions and I am often observing the same pattern in case of a RST, the following being an exemplary session end (it's first sequence number, then acknowledgement number):
0890: 14:56:54.507349: <= 1997168101 1198807587 ACK,PSH - length: 00017
0891: 14:56:55.565251: <= 1997168101 1198807587 ACK,PSH - length: 00017
0892: 14:56:57.409887: => 1198807587 1997168118 ACK - length: 00000
0893: 14:57:01.096632: => 1198807587 1997168118 ACK - length: 01188
0894: 14:57:01.096645: <= 1997168118 1198808775 ACK - length: 00000
0895: 15:00:32.390242: => 1198813327 1997168118 ACK,RST - length: 00000
0896: 15:00:32.390253: <= 1997168118 1198808775 ACK - length: 00000
0897: 15:06:55.502604: <= 1997168118 1198808775 ACK,FIN - length: 00000
0898: 15:07:01.105218: <= 1997168118 1198808775 ACK,FIN - length: 00000
0899: 15:07:12.337226: <= 1997168118 1198808775 ACK,FIN - length: 00000
0900: 15:07:34.737225: <= 1997168118 1198808775 ACK,FIN - length: 00000
0901: 15:08:19.665225: <= 1997168118 1198808775 ACK,FIN - length: 00000
I am interested in the sequence number of the RST packet. I would expect 1198807587 + 1188 = 1198808775 as sequence number instead of 1198813327, i.e. there is a gap of 4552 bytes. I checked the complete session (packets 1-889) and made sure that this gap is real.
I am now wondering, what is the most likely explanation for this?
RST injection (with higher in-window sequence number)? I wouldn't think so, because the RST sender is gone completely immediately after sending the RST, so I assume it was actually himself sending the RST.
Packet loss? Seems valid to me. But I would assume that a deliberate RST by design would not cause any packet loss. Wrong assumption? What might cause a RST in case it is packet loss?
Any other explanations for the gap?
It looks like "Blind Reset Attack Using the RST Bit" that is described in RFC-5961.
But because the 'left side' is totally death after that (does not answers for those FIN-ACKs), the problem might be something else.
For example:
Vulnerability scanner that check that the target follows the recommendation of RFC-5961 (sends challenge-ACK after such RST).
Related
I am trying to use the new dcm4che release 5.22.0 and more specifically the dcmqrscp tool:
https://github.com/dcm4che/dcm4che/blob/master/dcm4che-tool/dcm4che-tool-dcmqrscp/README.md
I am starting an instance:
dcmqrscp -b DCMROUTER:435 --dicomdir /media/cdrom/DICOMDIR
But i am getting the following exception during the association request (no matter the study i am trying to send):
11:12:29,896 INFO - Accept connection Socket[addr=/127.0.0.1,port=52127,localport=4006]
11:12:29,917 DEBUG - /127.0.0.1:4006<-/127.0.0.1:52127(1): enter state: Sta2 - Transport connection open
11:12:29,937 INFO - DCMROUTER<-MAYAM(1) >> A-ASSOCIATE-RQ
11:12:29,942 DEBUG - A-ASSOCIATE-RQ[
calledAET: DCMROUTER
callingAET: MAYAM
applicationContext: 1.2.840.10008.3.1.1.1 - DICOM Application Context Name
implClassUID: 1.2.40.0.13.1.1
implVersionName: dcm4che-2.0
maxPDULength: 16384
maxOpsInvoked/maxOpsPerformed: 0/0
PresentationContext[id: 1
as: 1.2.840.10008.5.1.4.1.1.4 - MR Image Storage
ts: 1.2.840.10008.1.2 - Implicit VR Little Endian
]
PresentationContext[id: 3
as: 1.2.840.10008.5.1.4.1.1.4 - MR Image Storage
ts: 1.2.840.10008.1.2.1 - Explicit VR Little Endian
]
]
11:12:29,942 DEBUG - DCMROUTER<-MAYAM(1): enter state: Sta3 - Awaiting local A-ASSOCIATE response primitive
11:12:29,942 INFO - DCMROUTER<-MAYAM(1) << A-ASSOCIATE-AC
11:12:29,942 DEBUG - A-ASSOCIATE-AC[
calledAET: DCMROUTER
callingAET: MAYAM
applicationContext: 1.2.840.10008.3.1.1.1 - DICOM Application Context Name
implClassUID: 1.2.40.0.13.1.3
implVersionName: dcm4che-5.22.0
maxPDULength: 16378
maxOpsInvoked/maxOpsPerformed: 0/0
PresentationContext[id: 1
result: 0 - acceptance
ts: 1.2.840.10008.1.2 - Implicit VR Little Endian
]
PresentationContext[id: 3
result: 0 - acceptance
ts: 1.2.840.10008.1.2.1 - Explicit VR Little Endian
]
]
11:12:29,943 DEBUG - DCMROUTER<-MAYAM(1): enter state: Sta6 - Association established and ready for data transfer
11:12:29,947 INFO - DCMROUTER<-MAYAM(1) >> 1:C-STORE-RQ[pcid=3, prior=0
cuid=1.2.840.10008.5.1.4.1.1.4 - MR Image Storage
iuid=2.25.236888348187743071893701493905889154404.2 - ?
tsuid=1.2.840.10008.1.2.1 - Explicit VR Little Endian]
11:12:29,968 DEBUG - DCMROUTER<-MAYAM(1) >> 1:C-STORE-RQ Command:
(0000,0002) UI [1.2.840.10008.5.1.4.1.1.4] AffectedSOPClassUID
(0000,0100) US [1] CommandField
(0000,0110) US [1] MessageID
(0000,0700) US [0] Priority
(0000,0800) US [0] CommandDataSetType
(0000,1000) UI [2.25.236888348187743071893701493905889154404.2] AffectedSOPIns
11:12:29,969 DEBUG - DCMROUTER<-MAYAM(1) >> 1:C-STORE-RQ Dataset receiving...
11:12:29,969 INFO - DCMROUTER<-MAYAM(1): M-WRITE \media\cdrom\2.25.236888348187743071893701493905889154404.2
11:12:29,988 INFO - DCMROUTER<-MAYAM(1): M-RENAME \media\cdrom\2.25.236888348187743071893701493905889154404.2
11:12:30,072 INFO - M-UPDATE \media\cdrom\DICOMDIR: add STUDY Record
11:12:30,074 INFO - DCMROUTER<-MAYAM(1): M-DELETE \media\cdrom\DICOM\67EEF683\3AA0D620\7E6BFF30
11:12:30,075 INFO - DCMROUTER<-MAYAM(1): processing 1:C-STORE-RQ[pcid=3, prior=0
cuid=1.2.840.10008.5.1.4.1.1.4 - MR Image Storage
iuid=2.25.236888348187743071893701493905889154404.2 - ?
tsuid=1.2.840.10008.1.2.1 - Explicit VR Little Endian] failed. Caused by:
org.dcm4che3.net.service.DicomServiceException: org.dcm4che3.data.IncompatibleSpecificCharaterSetException: Specific Character Sets [] and [ISO_IR 100] not compatible
at org.dcm4che3.tool.dcmqrscp.DcmQRSCP$CStoreSCPImpl.store(DcmQRSCP.java:176)
at org.dcm4che3.net.service.BasicCStoreSCP.onDimseRQ(BasicCStoreSCP.java:72)
at org.dcm4che3.net.service.DicomServiceRegistry.onDimseRQ(DicomServiceRegistry.java:86)
at org.dcm4che3.net.ApplicationEntity.onDimseRQ(ApplicationEntity.java:474)
at org.dcm4che3.net.Association.onDimseRQ(Association.java:746)
at org.dcm4che3.net.PDUDecoder.decodeDIMSE(PDUDecoder.java:467)
at org.dcm4che3.net.Association.handlePDataTF(Association.java:729)
at org.dcm4che3.net.State$4.onPDataTF(State.java:103)
at org.dcm4che3.net.Association.onPDataTF(Association.java:725)
at org.dcm4che3.net.PDUDecoder.nextPDU(PDUDecoder.java:177)
at org.dcm4che3.net.Association$2.run(Association.java:562)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.dcm4che3.data.IncompatibleSpecificCharaterSetException: Specific Character Sets [] and [ISO_IR 100] not compatible
at org.dcm4che3.data.Attributes.add(Attributes.java:2103)
at org.dcm4che3.data.Attributes.addSelected(Attributes.java:2060)
at org.dcm4che3.media.RecordFactory.createRecord(RecordFactory.java:255)
at org.dcm4che3.tool.dcmqrscp.DcmQRSCP.addDicomDirRecords(DcmQRSCP.java:1087)
at org.dcm4che3.tool.dcmqrscp.DcmQRSCP$CStoreSCPImpl.store(DcmQRSCP.java:167)
... 13 more
11:12:30,083 INFO - DCMROUTER<-MAYAM(1) << 1:C-STORE-RSP[pcid=3, status=110H, errorComment=org.dcm4che3.data.IncompatibleSpecificCharaterSetException: Spec
tsuid=1.2.840.10008.1.2.1 - Explicit VR Little Endian]
11:12:30,083 DEBUG - DCMROUTER<-MAYAM(1) << 1:C-STORE-RSP Command:
(0000,0100) US [32769] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [257] CommandDataSetType
(0000,0900) US [272] Status
(0000,0902) LO [org.dcm4che3.data.IncompatibleSpecificCharaterSetException: Sp
11:12:30,088 INFO - DCMROUTER<-MAYAM(1) >> A-RELEASE-RQ
11:12:30,088 DEBUG - DCMROUTER<-MAYAM(1): enter state: Sta8 - Awaiting local A-RELEASE response primitive
11:12:30,088 INFO - DCMROUTER<-MAYAM(1) << A-RELEASE-RP
11:12:30,089 DEBUG - DCMROUTER<-MAYAM(1): enter state: Sta13 - Awaiting Transport Connection Close Indication
11:12:30,093 DEBUG - DCMROUTER<-MAYAM(1): closing Socket[addr=/127.0.0.1,port=52127,localport=4006] in 50 ms
11:12:30,142 INFO - DCMROUTER<-MAYAM(1): close Socket[addr=/127.0.0.1,port=52127,localport=4006]
11:12:30,142 DEBUG - DCMROUTER<-MAYAM(1): enter state: Sta1 - Idle
Any ideas what has changed in 5.22.0 and might cause this error?
As commented by #thanili:
It was a bug, fixed hopefully now. Please refer to github source code for more details.
Looking at source code on github, it seems the exception is recently added.
package org.dcm4che3.data;
/**
* #author Gunter Zeilinger (gunterze#protonmail.com)
* #since Mar 2020
*/
public class IncompatibleSpecificCharaterSetException extends IllegalArgumentException {
public IncompatibleSpecificCharaterSetException(String s) {
super(s);
}
}
Apparently, you need to set the supported Specific Character Sets yourself.
public void setSpecificCharacterSet(String... codes) {
ensureModifiable();
decodeStringValuesUsingSpecificCharacterSet();
setString(Tag.SpecificCharacterSet, VR.CS, codes);
}
Without it, it throws exception as here and here.
On command line as mentioned in readme:
--fs-desc-cs <code> Character Set used in File-set
Descriptor File ("ISO_IR 100" =
ISO Latin 1)
How can I have different clock constraints on signals in the same clock domain ?
In my design, I have a PLL which is configurable through APB registers.
I am also working with 2 modes (mode1 and mode2).
Depending on the mode (selectable by the user), the clock output is either 100 MHz or 70 MHz.
Because the clock come from the same PLL output, the same clock is used for the design working #100 MHz in mode 1 and #70 MHz in mode 2.
Below is the structure of the top level entity :
entity myTopLevel is
port(
I_clk : in std_logic; -- the PLL output; #100MHz or 70 MHz
I_rst : in std_logic; -- input rst
I_mode1 : in std_logic; -- when '1' : I_clk is running # 100 MHz, when '0' : 70 MHz
I_data : in std_logic_vector(15 downto 0);
O_data : out std_logic_vector(15 downto 0));
Inside the top level entity, there are 2 modules. 1 is running # 100 MHz and is under reset when I_mode1 = '0'. The other is running # 70 MHz and is under reset when I_mode1 = '1' :
INST1 : myProcessModuleMode1
port (
I_clk1 => I_clk,
I_rst1 => S_rst1, -- asserted when I_mode1 = '0'
I_data1=> I_data,
O_data1=> S_data1)
INST2 : myProcessModuleMode2
port (
I_clk2 => I_clk,
I_rst2 => S_rst2, -- asserted when I_mode2 = '0'
I_data2=> I_data,
O_data2=> S_data2)
O_data <= S_data1 when I_mode1='1' else S_data2;
However, the myProcessModuleMode2 is slower than myProcessModuleMode1. So I want to add a constraint # 70 MHz on the module2 and 100 MHz on module1. Is it possible ?
With the current version, I am constraining the clock # 100 MHz and I get (after synthesis/ Place&Route) 90 MHz with negative slack in module 2 (which is ok, I want 70 MHz) and some negatives slacks in module 1 ...
I would like to release the constraint in module 2 to get better results in module1.
Using multicycle path on module2 could be a solution with clocks #100 MHz and 50MHz and not with clocks # 100 MHz & 70 MHz.
Note : I_mode1 (the configuration mode) is considered static.
Note 2 : I_* stands for input, O_* output and S_* signal.
Regards,
However OP has not mentioned the tool and platform, I'll show the constraints in SDC format, which is widely supported (by Synopsys, Cadence, Xilinx, Intel/Altera etc.).
Each module can have its own clock constraint through its clock input.
create_clock -name CLK1 -period 10 -waveform "0 5" [get_pins myProcessModuleMode1/I_clk1]
create_clock -name CLK2 -period 14 -waveform "0 7" [get_pins myProcessModuleMode2/I_clk2]
Now Module1 and Module2 are constrained at 100MHz and ~70MHz respectively.
Since S_data1 and S_data2 are multiplexed, there is clock domain crossing there. I would define the clocks logically exclusive to avoid timing violations between different clock domains.
set_clock_groups -logically_exclusive -group CLK1 -group CLK2
First of all, sorry for my bad english.
For the entire projet, I am trying to connect a generic smartwatch (this one) to an Arduino. The purpose is to gather information (heart rate for example).
I don't know how the device communicate with the application Mistep. So I followed several steps.
At this moment, I didn't analyze the establishment of the connection at the beginning but only the value (heart rate) transmission.
Running application with HCI/BLuetooth Log on Android
I analyzed this log in Wireshark.
First of all, I have a packet sent by the smartwatch and received by the Android machine:
Bluetooth HCI ACL Packet
.... 1110 0000 0001 = Connection Handle: 0x0e01
..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0)
00.. .... .... .... = BC Flag: Point-To-Point (0)
Data Total Length: 17
[Connect in frame: 12999]
[Source BD_ADDR: d6:1c:5a:c3:05:** (d6:1c:5a:c3:05:**)]
[Source Device Name: HRW_1c5ac305**]
[Source Role: Unknown (0)]
[Destination BD_ADDR: IntelCor_95:05:** (fc:f8:ae:95:05:**)]
[Destination Device Name: VMware Virtual Platform]
[Destination Role: Unknown (0)]
[Current Mode: Unknown (-1)]
Bluetooth Attribute Protocol
Opcode: Write Command (0x52)
0... .... = Authentication Signature: False
.1.. .... = Command: True
..01 0010 = Method: Write Request (0x12)
Handle: 0x0018 (Unknown)
[UUID: Unknown (0xfff2)]
Value: 68260400110a1000bd16
Then the Android device send a packet (notification) to the smartwatch:
Edit:
Bluetooth HCI ACL Packet
.... 1110 0000 0001 = Connection Handle: 0x0e01
..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2)
00.. .... .... .... = BC Flag: Point-To-Point (0)
Data Total Length: 9
[Connect in frame: 12999]
[Source BD_ADDR: IntelCor_95:05:** (fc:f8:ae:95:05:**)]
[Source Device Name: VMware Virtual Platform]
[Source Role: Unknown (0)]
[Destination BD_ADDR: d6:1c:5a:c3:05:25 (d6:1c:5a:c3:05:**)]
[Destination Device Name: HRW_1c5ac305**]
[Destination Role: Unknown (0)]
[Current Mode: Unknown (-1)]
Bluetooth Attribute Protocol
Opcode: Handle Value Notification (0x1b)
0... .... = Authentication Signature: False
.0.. .... = Command: False
..01 1011 = Method: Handle Value Notification (0x1b)
Handle: 0x000e (Heart Rate Measurement)
[UUID: Heart Rate Measurement (0x2a37)]
Flags: 0x04, Sensor Support
000. .... = Reserved: 0x00
...0 .... = RR Interval: False
.... 0... = Energy Expended: False
.... .1.. = Sensor Support: True
.... ..0. = Sensor Contact: False
.... ...0 = Value is UINT16: False
Value: 76
This packet contains the value of heart rate (76) but it is sent by Android device to the smartwatch for notification. I guess this value has been retrieved from the handle 0x0018 value: 68260400110a1000bd16.
The problem is: I don't know how to get the value from this hexa.
Do you have an idea how to analyze the value and get the heart value ?
we have configured kannel, and the status look like
SMS: received 0 (0 queued), sent 15133 (0 queued), store size 0
SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (3.08,15.23,0.02) msg/sec
DLR: received 14232, sent 0
DLR: inbound (11.45,5.64,0.02) msg/sec, outbound (0.00,0.00,0.00) msg/sec
DLR: 980 queued, using internal storage
Box connections:
smsbox:vsmsc, IP 127.0.0.1 (0 queued), (on-line 8d 21h 38m 41s)
smsc1[smsc1] SMPP:xxxxx.xxxxx.com:2775/2775:xxxxx:SMPP (online 769120s, rcvd: sms 0 (0.00,0.00,0.00) / dlr 1 (0.00,0.00,0.00), sent: sms 1 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), failed 0, queued 0 msgs)
in the DLR inbound, it showing (11.45,5.64,0.02) msg/sec. There is 3 value inside (). What is the meaning of each?
thanks
Average for the last minute;
Average for the last 5 minutes;
Average for all of runtime.
I need to send a bunch of IP packets that I'm sure will trigger an ICMP TTL-expired error message. How exactly can I associate each error message with the packet that generated it? What field in the ICMP header is used for this?
Should I rather use some custom ID number in the original IP header, so that I can tell which error message corresponds to which packet? If so, which field is most suitable for this?
The body of ICMP TTL Expired messages must include the IP header of the original packet (which includes the source-port / destination-port) and 64 bits beyond the original header.
Based on timing and that header information, you can derive which packet triggered the TTL-expired message.
I am including a sample triggered by an NTP packet below...
See RFC 792 (Page 5) for more details.
ICMP TTL-Expired Message
Ethernet II, Src: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00), Dst: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
Destination: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
Address: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00)
Address: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 172.25.116.254 (172.25.116.254), Dst: 172.25.116.10 (172.25.116.10)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0x86d7 (34519)
Flags: 0x02 (Don't Fragment)
0.. = Reserved bit: Not Set
.1. = Don't fragment: Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xb3b1 [correct]
[Good: True]
[Bad : False]
Source: 172.25.116.254 (172.25.116.254)
Destination: 172.25.116.10 (172.25.116.10)
Internet Control Message Protocol
Type: 11 (Time-to-live exceeded)
Code: 0 (Time to live exceeded in transit)
Checksum: 0x4613 [correct]
Internet Protocol, Src: 172.25.116.10 (172.25.116.10), Dst: 172.25.0.11 (172.25.0.11)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 36
Identification: 0x0001 (1)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 0
[Expert Info (Note/Sequence): "Time To Live" only 0]
[Message: "Time To Live" only 0]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (0x11)
Header checksum: 0xee80 [correct]
[Good: True]
[Bad : False]
Source: 172.25.116.10 (172.25.116.10)
Destination: 172.25.0.11 (172.25.0.11)
User Datagram Protocol, Src Port: telindus (1728), Dst Port: ntp (123)
Source port: telindus (1728)
Destination port: ntp (123)
Length: 16
Checksum: 0xa7a1 [unchecked, not all data available]
[Good Checksum: False]
[Bad Checksum: False]