CDP, bad checksum?

RouterOS Forwarding Protocols
1

I noticed in WireShark analyzer that RB133 with RouterOS 3.23 sends CDP packets with incorrect checksum. Is it by design or just a bug? Could be a bug in WireShark 1.0.7. parser too…
I think it is easy to replicate this situation; I noticed checksum problem when I was looking for something else.
Packet detail, notice line with “Checksum: 0x4333 [incorrect, should be 0xadc8]”.

No. Time Source Destination Protocol Info
58 43.927069 Routerbo_22:d3:2a CDP/VTP/DTP/PAgP/UDLD CDP Device
ID: MikroTik

Frame 58 (83 bytes on wire, 83 bytes captured)
Arrival Time: Apr 27, 2009 22:31:53.682448000
[Time delta from previous captured frame: 0.000311000 seconds]
[Time delta from previous displayed frame: 0.000311000 seconds]
[Time since reference or first frame: 43.927069000 seconds]
Frame Number: 58
Frame Length: 83 bytes
Capture Length: 83 bytes
[Frame is marked: False]
[Protocols in frame: eth:llc:cdp:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.chec
ksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
IEEE 802.3 Ethernet
Destination: CDP/VTP/DTP/PAgP/UDLD (01:00:0c:cc:cc:cc)
Address: CDP/VTP/DTP/PAgP/UDLD (01:00:0c:cc:cc:cc)
… …1 … … … … = IG bit: Group address (multicast/broadca
st)
… ..0. … … … … = LG bit: Globally unique address (factory
default)
Source: Routerbo_22:d3:2a (00:0c:42:22:d3:2a)
Address: Routerbo_22:d3:2a (00:0c:42:22:d3:2a)
… …0 … … … … = IG bit: Individual address (unicast)
… ..0. … … … … = LG bit: Globally unique address (factory
default)
Length: 69
Logical-Link Control
DSAP: SNAP (0xaa)
IG Bit: Individual
SSAP: SNAP (0xaa)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
… ..11 = Frame type: Unnumbered frame (0x03)
Organization Code: Cisco (0x00000c)
PID: CDP (0x2000)
Cisco Discovery Protocol
Version: 1
TTL: 120 seconds
Checksum: 0x4333 [incorrect, should be 0xadc8]
[Good: False]
[Bad : True]
Device ID: MikroTik
Type: Device ID (0x0001)
Length: 12
Device ID: MikroTik
Addresses
Type: Addresses (0x0002)
Length: 17
Number of addresses: 1
IP address: 192.168.222.134
Protocol type: NLPID
Protocol length: 1
Protocol: IP
Address length: 4
IP address: 192.168.222.134
Capabilities
Type: Capabilities (0x0004)
Length: 8
Capabilities: 0x00000001
… … … … … … … …1 = Is a Router
… … … … … … … ..0. = Not a Transparent Bridge
… … … … … … … .0.. = Not a Source Route Bridge
… … … … … … … 0… = Not a Switch
… … … … … … …0 … = Not a Host
… … … … … … ..0. … = Not IGMP capable
… … … … … … .0.. … = Not a Repeater
Software Version
Type: Software version (0x0005)
Length: 8
Software Version: 3.23
Platform: MikroTik
Type: Platform (0x0006)
Length: 12
Platform: MikroTik

2

Packet dump, checksum is at position 0x0018

0000 01 00 0c cc cc cc 00 0c 42 22 d3 2a 00 45 aa aa …B".*.E..
0010 03 00 00 0c 20 00 01 78 43 33 00 01 00 0c 4d 69 … ..xC3…Mi
0020 6b 72 6f 54 69 6b 00 02 00 11 00 00 00 01 01 01 kroTik…
0030 cc 00 04 c0 a8 de 86 00 04 00 08 00 00 00 01 00 …
0040 05 00 08 33 2e 32 33 00 06 00 0c 4d 69 6b 72 6f …3.23…Mikro
0050 54 69 6b Tik

3

only RB133 CDP packets? all other are shown with good checksum? or maybe ‘Offload Checksum’ option enabled on your NIC…

4

I have only RB133 here, I don’t know about other Mikrotik versions or hardware, I guess it could be RouterOS general issue.

I believe this packet was sent from Mikrotik board; why it should be related to my NIC checksum offload? Why other packets have correct checksum?? No, this issue has nothing to do with packet checksum offload; I know about this problem.

5

If packet is captured on the same board where packet was generated then it may show incorrect checksum. it is not a bug, packets are captured before correct checksum is generated.

6

If the packet is captured at different PC as generated, is it a problem? Only CPD packets from Mikrotik board has this checksum problem. I think it is really easy to replicate, just start RouterOS and connect to the same network a PC with WireShark capturing traffic on the LAN.

7

I installed RouterOS 3.23 in VMware server. At first, it seemed that there is no problem at x86 platform, CDP packets had correct checksum. RouterOS was in fresh installed state, no IP address was assigned to the network interfaces, and no IP address information was in CDP packet. When I added IP address to the Ethernet interface, WireShark start to mark CDP packets with red color as checksum was incorrect.

I can repeat the same scenario on RB133, when no IP address is in CDP packet, checksum is correct. When address is added, checksum in CDP packet is incorrect.

More questions? CDP packets from VMware machine attached, one example of packet with correct checksum and other with incorrect checksum.
CDP_RouterOS_VMw.zip (260 Bytes)

8

I’ve been playing with cdp-tools and RouterOS 4.6, and I’ve tried several combinations of CDP packets. I ended up with the following:

  • The CDP checksum only seems to be valid when the System ID of the box is 4 bytes in length (the default is mkt1)
  • RouterOS doesn’t seem to recognize CDP version 2, which is the default for Cisco (actually, Cisco will also send version 1 packets when it receives a version 1 packet on the interface).

Would this be an implementation option or a bug of some sort? Are there any specs available for MNDP?