RIP Packet Format Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30 pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?RIP routing is broken between two routersWhy is RIP not scalable?Why we can not ping to multicast address 224.0.0.9 of RIPRouters are not learning routes when using RIPHow does OSPF understand its directly connected networks if you're configuring interfaces?How do you define cost in Quagga for BGP and RIP?Does RIP stores information about entire AS?Why is RIP sending classless updates?Clarifications about RIP and OSPFthe difference between RIP and OSPF
Why isn't everyone flabbergasted about Bran's "gift"?
How can I wire a 9-position switch so that each position turns on one more LED than the one before?
Why doesn't the university give past final exams' answers?
What is a 'Key' in computer science?
How long can a nation maintain a technological edge over the rest of the world?
Has a Nobel Peace laureate ever been accused of war crimes?
Raising a bilingual kid. When should we introduce the majority language?
How was Lagrange appointed professor of mathematics so early?
What is ls Largest Number Formed by only moving two sticks in 508?
Why is water being consumed when my shutoff valve is closed?
When I export an AI 300x60 art board it saves with bigger dimensions
/bin/ls sorts differently than just ls
`FindRoot [ ]`::jsing: Encountered a singular Jacobian at a point...WHY
Why I cannot instantiate a class whose constructor is private in a friend class?
Processing ADC conversion result: DMA vs Processor Registers
What was Apollo 13's "Little Jolt" after MECO?
TV series episode where humans nuke aliens before decrypting their message that states they come in peace
What's parked in Mil Moscow helicopter plant?
What is the evidence that custom checks in Northern Ireland are going to result in violence?
"Working on a knee"
Can gravitational waves pass through a black hole?
France's Public Holidays' Puzzle
What is the term for extremely loose Latin word order?
What is the numbering system used for the DSN dishes?
RIP Packet Format
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30 pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?RIP routing is broken between two routersWhy is RIP not scalable?Why we can not ping to multicast address 224.0.0.9 of RIPRouters are not learning routes when using RIPHow does OSPF understand its directly connected networks if you're configuring interfaces?How do you define cost in Quagga for BGP and RIP?Does RIP stores information about entire AS?Why is RIP sending classless updates?Clarifications about RIP and OSPFthe difference between RIP and OSPF
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
New contributor
add a comment |
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
New contributor
You should use the verbose output (-vv
) to get more information with the full protocol decode.
– Ron Maupin♦
8 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
8 hours ago
add a comment |
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
New contributor
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
New contributor
New contributor
New contributor
asked 8 hours ago
BatBat
1133
1133
New contributor
New contributor
You should use the verbose output (-vv
) to get more information with the full protocol decode.
– Ron Maupin♦
8 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
8 hours ago
add a comment |
You should use the verbose output (-vv
) to get more information with the full protocol decode.
– Ron Maupin♦
8 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
8 hours ago
You should use the verbose output (
-vv
) to get more information with the full protocol decode.– Ron Maupin♦
8 hours ago
You should use the verbose output (
-vv
) to get more information with the full protocol decode.– Ron Maupin♦
8 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
8 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
8 hours ago
add a comment |
3 Answers
3
active
oldest
votes
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
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
8 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 0x001c.
– Ron Trunk
8 hours ago
add a comment |
Given how simple RIP v1 is, this is pretty easy to do by eye from Figure 1 in the RFC 1058:
- 5 longs from
45c0
is the IP header - 4 shorts from
0208
(the italic portion) is the UDP header - The rest from
0201
(the bold portion) is the RIP body
01:00:00.000000 IP 128.238.62.2.route > 255.255.255.255.route: RIPv1, Response, length: 44
0x0000: 45c0 0048 0000 0000 0211 f8f5 80ee 3e02 E..H..........>.
0x0010: ffff ffff 0208 0208 0034 b9a0 0201 0000 .........4......
0x0020: 0002 0000 80ee 3f00 0000 0000 0000 0000 ......?.........
0x0030: 0000 0001 0002 0000 80ee 4000 0000 0000 ..........@.....
0x0040: 0000 0000 0000 0002 ........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
The portion of the datagram from address family identifier through
metric may appear up to 25 times.
We have:
command=02 version=01 mbz=0000
family=0002 mbz=0000 addr=80ee3f00 mbz=00000000 mbz=00000000 metric=00000001
family=0002 mbz=0000 adda=80ee4000 mbz=00000000 mbz=00000000 metric=00000002
But if you have more complex packets ...
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
add a comment |
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
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "496"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Bat is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f58674%2frip-packet-format%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
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.
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
8 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 0x001c.
– Ron Trunk
8 hours ago
add a comment |
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
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
8 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 0x001c.
– Ron Trunk
8 hours ago
add a comment |
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.
edited 3 hours ago
answered 8 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
8 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 0x001c.
– Ron Trunk
8 hours ago
add a comment |
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
8 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 0x001c.
– Ron Trunk
8 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
8 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
8 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 0x001c.
– Ron Trunk
8 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 0x001c.
– Ron Trunk
8 hours ago
add a comment |
Given how simple RIP v1 is, this is pretty easy to do by eye from Figure 1 in the RFC 1058:
- 5 longs from
45c0
is the IP header - 4 shorts from
0208
(the italic portion) is the UDP header - The rest from
0201
(the bold portion) is the RIP body
01:00:00.000000 IP 128.238.62.2.route > 255.255.255.255.route: RIPv1, Response, length: 44
0x0000: 45c0 0048 0000 0000 0211 f8f5 80ee 3e02 E..H..........>.
0x0010: ffff ffff 0208 0208 0034 b9a0 0201 0000 .........4......
0x0020: 0002 0000 80ee 3f00 0000 0000 0000 0000 ......?.........
0x0030: 0000 0001 0002 0000 80ee 4000 0000 0000 ..........@.....
0x0040: 0000 0000 0000 0002 ........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
The portion of the datagram from address family identifier through
metric may appear up to 25 times.
We have:
command=02 version=01 mbz=0000
family=0002 mbz=0000 addr=80ee3f00 mbz=00000000 mbz=00000000 metric=00000001
family=0002 mbz=0000 adda=80ee4000 mbz=00000000 mbz=00000000 metric=00000002
But if you have more complex packets ...
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
add a comment |
Given how simple RIP v1 is, this is pretty easy to do by eye from Figure 1 in the RFC 1058:
- 5 longs from
45c0
is the IP header - 4 shorts from
0208
(the italic portion) is the UDP header - The rest from
0201
(the bold portion) is the RIP body
01:00:00.000000 IP 128.238.62.2.route > 255.255.255.255.route: RIPv1, Response, length: 44
0x0000: 45c0 0048 0000 0000 0211 f8f5 80ee 3e02 E..H..........>.
0x0010: ffff ffff 0208 0208 0034 b9a0 0201 0000 .........4......
0x0020: 0002 0000 80ee 3f00 0000 0000 0000 0000 ......?.........
0x0030: 0000 0001 0002 0000 80ee 4000 0000 0000 ..........@.....
0x0040: 0000 0000 0000 0002 ........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
The portion of the datagram from address family identifier through
metric may appear up to 25 times.
We have:
command=02 version=01 mbz=0000
family=0002 mbz=0000 addr=80ee3f00 mbz=00000000 mbz=00000000 metric=00000001
family=0002 mbz=0000 adda=80ee4000 mbz=00000000 mbz=00000000 metric=00000002
But if you have more complex packets ...
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
add a comment |
Given how simple RIP v1 is, this is pretty easy to do by eye from Figure 1 in the RFC 1058:
- 5 longs from
45c0
is the IP header - 4 shorts from
0208
(the italic portion) is the UDP header - The rest from
0201
(the bold portion) is the RIP body
01:00:00.000000 IP 128.238.62.2.route > 255.255.255.255.route: RIPv1, Response, length: 44
0x0000: 45c0 0048 0000 0000 0211 f8f5 80ee 3e02 E..H..........>.
0x0010: ffff ffff 0208 0208 0034 b9a0 0201 0000 .........4......
0x0020: 0002 0000 80ee 3f00 0000 0000 0000 0000 ......?.........
0x0030: 0000 0001 0002 0000 80ee 4000 0000 0000 ..........@.....
0x0040: 0000 0000 0000 0002 ........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
The portion of the datagram from address family identifier through
metric may appear up to 25 times.
We have:
command=02 version=01 mbz=0000
family=0002 mbz=0000 addr=80ee3f00 mbz=00000000 mbz=00000000 metric=00000001
family=0002 mbz=0000 adda=80ee4000 mbz=00000000 mbz=00000000 metric=00000002
But if you have more complex packets ...
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
Given how simple RIP v1 is, this is pretty easy to do by eye from Figure 1 in the RFC 1058:
- 5 longs from
45c0
is the IP header - 4 shorts from
0208
(the italic portion) is the UDP header - The rest from
0201
(the bold portion) is the RIP body
01:00:00.000000 IP 128.238.62.2.route > 255.255.255.255.route: RIPv1, Response, length: 44
0x0000: 45c0 0048 0000 0000 0211 f8f5 80ee 3e02 E..H..........>.
0x0010: ffff ffff 0208 0208 0034 b9a0 0201 0000 .........4......
0x0020: 0002 0000 80ee 3f00 0000 0000 0000 0000 ......?.........
0x0030: 0000 0001 0002 0000 80ee 4000 0000 0000 ..........@.....
0x0040: 0000 0000 0000 0002 ........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
The portion of the datagram from address family identifier through
metric may appear up to 25 times.
We have:
command=02 version=01 mbz=0000
family=0002 mbz=0000 addr=80ee3f00 mbz=00000000 mbz=00000000 metric=00000001
family=0002 mbz=0000 adda=80ee4000 mbz=00000000 mbz=00000000 metric=00000002
But if you have more complex packets ...
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
edited 1 hour ago
answered 4 hours ago
jonathanjojonathanjo
12.4k1938
12.4k1938
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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 8 hours ago
serverAdmin123serverAdmin123
39517
39517
add a comment |
add a comment |
Bat is a new contributor. Be nice, and check out our Code of Conduct.
Bat is a new contributor. Be nice, and check out our Code of Conduct.
Bat is a new contributor. Be nice, and check out our Code of Conduct.
Bat is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f58674%2frip-packet-format%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You should use the verbose output (
-vv
) to get more information with the full protocol decode.– Ron Maupin♦
8 hours ago
I don't have further access to the system. Is it possible to decode via only this packet? @RonMaupin
– Bat
8 hours ago