Dtjytyk

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?

It's a RIPv1 packet. You're looking at the full IP packet. RIP starts at 0x001c.

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

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