LLC TEST packets?

Question

So I noticed in my packet captures that something on the lan is broadcasting LLC TEST packets. I read the 802.2 standard and it sounds like it is essentially a layer 2 PING function and it is required. I thought this is great! I can broadcast an L2 ping and get a reply from every node on the lan, whether it is running IP or not. Alas, after using scapy to craft and send one, I get no replies.

So my question is, why am I not getting a reply? Am I misunderstanding the standard or does nobody bother to comply with it? Bonus points if you have any idea why something on the lan is broadcasting these packets that don't seem to work.

The LLC header decode is:

DSAP: NULL SSAP: LLC Sub-Layer Management (0x02)
CR Bit: Command
Control Field: U, func=TEST (0xE3)

Full packet capture here

Accepted Answer

0

So my question is, why am I not getting a reply?

Because that feature is (apparently) not widely implemented.

Bonus points if you have any idea why something on the lan is broadcasting these packets

According to the MAC address in the frame, it comes from a device of "Senao International Co., Ltd.", which builds all kinds of networking devices. Maybe they use LLC TEST for internal purposes (finding other Senao devices or similar).

You should be able to find the port of that devices by looking at the CAM table of your switch. It will show you the port that device is connected to and then you can 'follow the cables', unless your switch documentation already contains some information about that device ;-)

Regards
Kurt

answered 09 Dec '13, 07:42

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 09 Dec '13, 07:46

Am I misinterpreting the standard though, which seems to say that support for this packet is REQUIRED. I find it hard to believe that nobody bothers to follow a mandatory part of the standard, and what's more, even this Senao device that is sending them doesn't reply to them, which is really weird.

(09 Dec '13, 08:02) psusi

Am I misinterpreting the standard though, which seems to say that support for this packet is REQUIRED.

well, I guess it's as always. Some people read the docs differently than others.

Here is the text from the standard

http://standards.ieee.org/getieee802/download/802.2-1998.pdf

Cite:

6.7 Uses of the TEST command PDU and response PDU ....

Implementation of the TEST command PDU is optional but every LLC must be able to respond to a received TEST command PDU with a TEST response PDU.

To be able to respond does not mean it is mandatory to actually respond ;-)) Some devices might be able to respond but that feature is disabled by default. Another possibilty: (most) developers stopped reading after the word optional.

I find it hard to believe that nobody bothers to follow a mandatory part of the standard,

well, if you look at the history of standards and the rate of fulfillment in the field, you will believe it ;-))

and what’s more, even this Senao device that is sending them doesn’t reply to them, which is really weird.

There you have it. Even those who use that feature don’t implement it fully ;-)) But that’s something only the vendor of that device can answer.

Another possibility would be, that your hand crafted frame (scapy) was bogus. Can you post that as a capture file?

(09 Dec ‘13, 08:18) Kurt Knochner ♦

@Kurt Knochner, it was identical to the one sent by the Senao device, save for the source MAC address, which I switched to my own.

(10 Dec ‘13, 06:42) psusi

So, do you get a TEST answer now?

EDIT: I misunderstood your answer. Never mind…

(10 Dec ‘13, 06:44) Kurt Knochner ♦