RIP Packet Format
I am trying to investigate a RIP packet. It clearly states that the packet is RIP v1. But its format does not match with the either RIP v1 or v2. Any ideas what this packet actually is?
routing packet-analysis rip
asked 5 hours ago
BatBat
1133
New contributor
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
|
I am trying to investigate a RIP packet. It clearly states that the packet is RIP v1. But its format does not match with the either RIP v1 or v2. Any ideas what this packet actually is?
routing packet-analysis rip
asked 5 hours ago
BatBat
1133
New contributor
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You should use the verbose output (-vv) to get more information with the full protocol decode.
– Ron Maupin♦
5 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
5 hours ago
|
I am trying to investigate a RIP packet. It clearly states that the packet is RIP v1. But its format does not match with the either RIP v1 or v2. Any ideas what this packet actually is?
routing packet-analysis rip
asked 5 hours ago
BatBat
1133
New contributor
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I am trying to investigate a RIP packet. It clearly states that the packet is RIP v1. But its format does not match with the either RIP v1 or v2. Any ideas what this packet actually is?
routing packet-analysis rip
routing packet-analysis rip
asked 5 hours ago
BatBat
1133
New contributor
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
BatBat
1133
New contributor
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
BatBat
1133
New contributor
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 5 hours ago
BatBat
1133
asked 5 hours ago
BatBat
1133
1133
New contributor
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Bat is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You should use the verbose output (-vv) to get more information with the full protocol decode.
– Ron Maupin♦
5 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
5 hours ago
|
You should use the verbose output (-vv) to get more information with the full protocol decode.
– Ron Maupin♦
5 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
5 hours ago
You should use the verbose output (
-vv) to get more information with the full protocol decode.– Ron Maupin♦
5 hours ago
You should use the verbose output (
-vv) to get more information with the full protocol decode.– Ron Maupin♦
5 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
5 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
5 hours ago
|
3 Answers
3
active
oldest
votes
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
answered 5 hours ago
Ron TrunkRon Trunk
40.2k33781
The problem is that IP 128.238.62.2 (80ee 3e02) appears at the end of the first line. According to the rip v1, the previous 2 bytes should be zero but they have a value of f8f5.
– Bat
5 hours ago
3
That's the source IP in the IP header. Then you have the UDP header, then you have the RIP packet starting at 0x0016.
– Ron Trunk
5 hours ago
@RonTrunk ... IP starts at 0x0, UDP starts at 0x14 (port, port, length, checksum), surely RIP starts at 0x1c with bytes 0x0201: 0x02 = Response, 0x01 = RIP1.
– jonathanjo
1 hour ago
@jonathanjo Thanks fo catching that. I edited my answer.
– Ron Trunk
57 mins ago
|
One way to solve this kind of problem is to make a PCAP file from the data (with a tool or just a programming language such as python), and then use standard tools to examine it.
Your packet analysed with tshark is:
Internet Protocol Version 4, Src: 128.238.62.2, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 72
Identification: 0x0000 (0)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 2
[Expert Info (Note/Sequence): "Time To Live" only 2]
["Time To Live" only 2]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (17)
Header checksum: 0xf8f5 [validation disabled]
[Header checksum status: Unverified]
Source: 128.238.62.2
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 520, Dst Port: 520
Source Port: 520
Destination Port: 520
Length: 52
Checksum: 0xb9a0 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 128.238.63.0, Metric: 1
Address Family: IP (2)
IP Address: 128.238.63.0
Metric: 1
IP Address: 128.238.64.0, Metric: 2
Address Family: IP (2)
IP Address: 128.238.64.0
Metric: 2
answered 1 hour ago
jonathanjojonathanjo
12.4k1938
|
This is a response header. Response means ' A message containing all or part of the sender's routing table. This message may be sent in response to a request or poll, or it may be an update message generated by the sender.'
In addition to that you can see sender ip address and subnet.
If you want to see more details you can use -vv
answered 5 hours ago
serverAdmin123serverAdmin123
39517
|
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
answered 5 hours ago
Ron TrunkRon Trunk
40.2k33781
The problem is that IP 128.238.62.2 (80ee 3e02) appears at the end of the first line. According to the rip v1, the previous 2 bytes should be zero but they have a value of f8f5.
– Bat
5 hours ago
3
That's the source IP in the IP header. Then you have the UDP header, then you have the RIP packet starting at 0x0016.
– Ron Trunk
5 hours ago
@RonTrunk ... IP starts at 0x0, UDP starts at 0x14 (port, port, length, checksum), surely RIP starts at 0x1c with bytes 0x0201: 0x02 = Response, 0x01 = RIP1.
– jonathanjo
1 hour ago
@jonathanjo Thanks fo catching that. I edited my answer.
– Ron Trunk
57 mins ago
|
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
answered 5 hours ago
Ron TrunkRon Trunk
40.2k33781
The problem is that IP 128.238.62.2 (80ee 3e02) appears at the end of the first line. According to the rip v1, the previous 2 bytes should be zero but they have a value of f8f5.
– Bat
5 hours ago
3
That's the source IP in the IP header. Then you have the UDP header, then you have the RIP packet starting at 0x0016.
– Ron Trunk
5 hours ago
@RonTrunk ... IP starts at 0x0, UDP starts at 0x14 (port, port, length, checksum), surely RIP starts at 0x1c with bytes 0x0201: 0x02 = Response, 0x01 = RIP1.
– jonathanjo
1 hour ago
@jonathanjo Thanks fo catching that. I edited my answer.
– Ron Trunk
57 mins ago
|
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
answered 5 hours ago
Ron TrunkRon Trunk
40.2k33781
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
answered 5 hours ago
Ron TrunkRon Trunk
40.2k33781
edited 58 mins ago
answered 5 hours ago
Ron TrunkRon Trunk
40.2k33781
answered 5 hours ago
Ron TrunkRon Trunk
40.2k33781
answered 5 hours ago
Ron TrunkRon Trunk
40.2k33781
40.2k33781
The problem is that IP 128.238.62.2 (80ee 3e02) appears at the end of the first line. According to the rip v1, the previous 2 bytes should be zero but they have a value of f8f5.
– Bat
5 hours ago
3
That's the source IP in the IP header. Then you have the UDP header, then you have the RIP packet starting at 0x0016.
– Ron Trunk
5 hours ago
@RonTrunk ... IP starts at 0x0, UDP starts at 0x14 (port, port, length, checksum), surely RIP starts at 0x1c with bytes 0x0201: 0x02 = Response, 0x01 = RIP1.
– jonathanjo
1 hour ago
@jonathanjo Thanks fo catching that. I edited my answer.
– Ron Trunk
57 mins ago
|
The problem is that IP 128.238.62.2 (80ee 3e02) appears at the end of the first line. According to the rip v1, the previous 2 bytes should be zero but they have a value of f8f5.
– Bat
5 hours ago
3
That's the source IP in the IP header. Then you have the UDP header, then you have the RIP packet starting at 0x0016.
– Ron Trunk
5 hours ago
@RonTrunk ... IP starts at 0x0, UDP starts at 0x14 (port, port, length, checksum), surely RIP starts at 0x1c with bytes 0x0201: 0x02 = Response, 0x01 = RIP1.
– jonathanjo
1 hour ago
@jonathanjo Thanks fo catching that. I edited my answer.
– Ron Trunk
57 mins ago
The problem is that IP 128.238.62.2 (80ee 3e02) appears at the end of the first line. According to the rip v1, the previous 2 bytes should be zero but they have a value of f8f5.
– Bat
5 hours ago
The problem is that IP 128.238.62.2 (80ee 3e02) appears at the end of the first line. According to the rip v1, the previous 2 bytes should be zero but they have a value of f8f5.
– Bat
5 hours ago
3
3
That's the source IP in the IP header. Then you have the UDP header, then you have the RIP packet starting at 0x0016.
– Ron Trunk
5 hours ago
That's the source IP in the IP header. Then you have the UDP header, then you have the RIP packet starting at 0x0016.
– Ron Trunk
5 hours ago
@RonTrunk ... IP starts at 0x0, UDP starts at 0x14 (port, port, length, checksum), surely RIP starts at 0x1c with bytes 0x0201: 0x02 = Response, 0x01 = RIP1.
– jonathanjo
1 hour ago
@RonTrunk ... IP starts at 0x0, UDP starts at 0x14 (port, port, length, checksum), surely RIP starts at 0x1c with bytes 0x0201: 0x02 = Response, 0x01 = RIP1.
– jonathanjo
1 hour ago
@jonathanjo Thanks fo catching that. I edited my answer.
– Ron Trunk
57 mins ago
@jonathanjo Thanks fo catching that. I edited my answer.
– Ron Trunk
57 mins ago
|
One way to solve this kind of problem is to make a PCAP file from the data (with a tool or just a programming language such as python), and then use standard tools to examine it.
Your packet analysed with tshark is:
Internet Protocol Version 4, Src: 128.238.62.2, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 72
Identification: 0x0000 (0)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 2
[Expert Info (Note/Sequence): "Time To Live" only 2]
["Time To Live" only 2]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (17)
Header checksum: 0xf8f5 [validation disabled]
[Header checksum status: Unverified]
Source: 128.238.62.2
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 520, Dst Port: 520
Source Port: 520
Destination Port: 520
Length: 52
Checksum: 0xb9a0 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 128.238.63.0, Metric: 1
Address Family: IP (2)
IP Address: 128.238.63.0
Metric: 1
IP Address: 128.238.64.0, Metric: 2
Address Family: IP (2)
IP Address: 128.238.64.0
Metric: 2
answered 1 hour ago
jonathanjojonathanjo
12.4k1938
|
One way to solve this kind of problem is to make a PCAP file from the data (with a tool or just a programming language such as python), and then use standard tools to examine it.
Your packet analysed with tshark is:
Internet Protocol Version 4, Src: 128.238.62.2, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 72
Identification: 0x0000 (0)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 2
[Expert Info (Note/Sequence): "Time To Live" only 2]
["Time To Live" only 2]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (17)
Header checksum: 0xf8f5 [validation disabled]
[Header checksum status: Unverified]
Source: 128.238.62.2
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 520, Dst Port: 520
Source Port: 520
Destination Port: 520
Length: 52
Checksum: 0xb9a0 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 128.238.63.0, Metric: 1
Address Family: IP (2)
IP Address: 128.238.63.0
Metric: 1
IP Address: 128.238.64.0, Metric: 2
Address Family: IP (2)
IP Address: 128.238.64.0
Metric: 2
answered 1 hour ago
jonathanjojonathanjo
12.4k1938
|
One way to solve this kind of problem is to make a PCAP file from the data (with a tool or just a programming language such as python), and then use standard tools to examine it.
Your packet analysed with tshark is:
Internet Protocol Version 4, Src: 128.238.62.2, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 72
Identification: 0x0000 (0)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 2
[Expert Info (Note/Sequence): "Time To Live" only 2]
["Time To Live" only 2]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (17)
Header checksum: 0xf8f5 [validation disabled]
[Header checksum status: Unverified]
Source: 128.238.62.2
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 520, Dst Port: 520
Source Port: 520
Destination Port: 520
Length: 52
Checksum: 0xb9a0 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 128.238.63.0, Metric: 1
Address Family: IP (2)
IP Address: 128.238.63.0
Metric: 1
IP Address: 128.238.64.0, Metric: 2
Address Family: IP (2)
IP Address: 128.238.64.0
Metric: 2
answered 1 hour ago
jonathanjojonathanjo
12.4k1938
One way to solve this kind of problem is to make a PCAP file from the data (with a tool or just a programming language such as python), and then use standard tools to examine it.
Your packet analysed with tshark is:
Internet Protocol Version 4, Src: 128.238.62.2, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 72
Identification: 0x0000 (0)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 2
[Expert Info (Note/Sequence): "Time To Live" only 2]
["Time To Live" only 2]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (17)
Header checksum: 0xf8f5 [validation disabled]
[Header checksum status: Unverified]
Source: 128.238.62.2
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 520, Dst Port: 520
Source Port: 520
Destination Port: 520
Length: 52
Checksum: 0xb9a0 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 128.238.63.0, Metric: 1
Address Family: IP (2)
IP Address: 128.238.63.0
Metric: 1
IP Address: 128.238.64.0, Metric: 2
Address Family: IP (2)
IP Address: 128.238.64.0
Metric: 2
answered 1 hour ago
jonathanjojonathanjo
12.4k1938
answered 1 hour ago
jonathanjojonathanjo
12.4k1938
answered 1 hour ago
jonathanjojonathanjo
12.4k1938
answered 1 hour ago
jonathanjojonathanjo
12.4k1938
12.4k1938
|
|
This is a response header. Response means ' A message containing all or part of the sender's routing table. This message may be sent in response to a request or poll, or it may be an update message generated by the sender.'
In addition to that you can see sender ip address and subnet.
If you want to see more details you can use -vv
answered 5 hours ago
serverAdmin123serverAdmin123
39517
|
This is a response header. Response means ' A message containing all or part of the sender's routing table. This message may be sent in response to a request or poll, or it may be an update message generated by the sender.'
In addition to that you can see sender ip address and subnet.
If you want to see more details you can use -vv
answered 5 hours ago
serverAdmin123serverAdmin123
39517
|
This is a response header. Response means ' A message containing all or part of the sender's routing table. This message may be sent in response to a request or poll, or it may be an update message generated by the sender.'
In addition to that you can see sender ip address and subnet.
If you want to see more details you can use -vv
answered 5 hours ago
serverAdmin123serverAdmin123
39517
This is a response header. Response means ' A message containing all or part of the sender's routing table. This message may be sent in response to a request or poll, or it may be an update message generated by the sender.'
In addition to that you can see sender ip address and subnet.
If you want to see more details you can use -vv
answered 5 hours ago
serverAdmin123serverAdmin123
39517
answered 5 hours ago
serverAdmin123serverAdmin123
39517
answered 5 hours ago
serverAdmin123serverAdmin123
39517
answered 5 hours ago
serverAdmin123serverAdmin123
39517
39517
|
|
You should use the verbose output (
-vv) to get more information with the full protocol decode.– Ron Maupin♦
5 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
5 hours ago