Strange packet: "daylight rekick", anyone?

Published: 2010-09-28. Last Updated: 2010-09-28 22:56:11 UTC
by Daniel Wesemann (Version: 1)
9 comment(s)

ISC reader Keith reports a "strange packet" on his network. He gets the following alert

9/28/2010 2:09 PM : C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET 272: Sep 28 19:09:41: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 5 times)Packet received with invalid source MAC address (45:42:55:47:3D:57) on port Po1 in vlan 24

and the following packet to go with it:

0000 3d 3d 4b 56 3d 44 45 42 55 47 3d 57 26 4c 3d 3d
0010 64 61 79 6c 69 67 68 74 20 72 65 6b 69 63 6b 21
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00

No surprise really that this packet is "illegal". When parsed into plain ASCII, it reads

==KV=DEBUG=W&L==
daylight rekick!

Has anyone seen this before and might know what sort of device could be burping out these non-IP packets directly onto the VLAN?

Keywords: packet
9 comment(s)

Comments

a two year old post on cisco forums yields little info on a similar message:

https://supportforums.cisco.com/thread/147193?tstart=0&viewcondensed

Alan

Sep 29th 2010
1 decade ago

Yep that mac showed up there.

==KV=DEBUG=W&L== is that related to KV Ladder Building software for PCL?

You may have something interesting...

drStrangeP0rk

Sep 29th 2010
1 decade ago

Sorry PLC?

drStrangeP0rk

Sep 29th 2010
1 decade ago

Can't comment anything on this particular packet but the log message is pretty well known here from our Catalyst 4500 machines for some years.

The posting gave me a hint to analyse the "MAC-adresses" seen here.

Some obviously ascii highlights:

21:21:21:21:23:3C: !!!!#<
21:23:46:75:33:21: !#Fu3!
2D:61:6C:69:76:65: -alive
3D:30:2E:31:0D:0A: =0.1\r\n
41:25:37:43:70:6F: A%7Cpo
47:3D:31:35:6D:76: G=15mv
57:25:33:44:61:74: W%3Dat
61:67:65:3A:20:64: age: d
63:6D:64:2F:65:76: cmd/ev
65:0D:0A:43:6F:6F: e\r\nCoo
65:3A:20:31:31:35: e: 115
65:63:6B:6F:29:20: ecko)
69:72:65:66:6F:78: irefox
69:76:65:3A:20:31: ive: 1
6D:2F:64:65:2E:68: m/de.h
6F:6E:74:65:6E:74: ontent
73:3D:64:65:3A:35: s=de:5

My assumption: a somehow broken IP-stack on the endhost, not a particular application, maybe a flaw in the NIC driver.
It looks like "fragments" of data with the network header stripped.

Jens

Sep 29th 2010
1 decade ago

is the source and destination MAC addr. the same ?
if yes, i recall our IPS blocked it on a CISCO L3 switch, and noted that this is an impossible packet, cause is a DoS tool called LAND.C, search for it you should have a lead form there.

Myam

Sep 29th 2010
1 decade ago

Thanks for the help, everyone. I've received some pretty good leads. Hopefully, they will help determine a resolution. I'll keep you posted.
I am seeing this packet on a Cat4500. The source and destination MACs are different.
Source - 45:42:55:47:3D:57
Destination - 3d:3d:4b:56:3d:44

Keith

Sep 29th 2010
1 decade ago

The leading 45: makes it a multicast address, suspect this is some sort of discovery protocol.

Jeff

Sep 29th 2010
1 decade ago

<pre>
45:42:55:47:3D:57: EBUG=W
3d:3d:4b:56:3d:44: ==KV=D
</pre>

For shorthand analysis:

<pre>
echo $MAC | sed 's/(//' | sed 's/)//' | awk -F: '{printf "%s: %c%c%c%c%c%c\n", $0, strtonum("0x"$1), strtonum("0x"$2), strtonum("0x"$3), strtonum("0x"$4), strtonum("0x"$5), strtonum("0x"$6)}'
</pre>

Jens

Sep 30th 2010
1 decade ago

We have the same on two switches. We have traced it back to a Tandberg. I am continually looking to identify the mechanics, but I have been told that it is innocuous. Not sure I am buying that just yet because I don't know exactly why it is occurring and it does not appear to happen with any of our other Tandbergs.

TC

Sep 30th 2010
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives