Ask Your Question
0

Unknown broadcast frame

asked 2021-08-25 08:12:07 +0000

ta gravatar image

updated 2021-08-25 09:11:34 +0000

grahamb gravatar image

Hi, I'm developing an application with use of an tcp/ip stack, but encountered that the stack hangs due to a broadcast frame sent on the network (see below) by, I think, a netgear router.

Now I'm planning an update of my stack, but need to understand what the frame actually is - e.g. should I simply reject any frame with protocol 0x0000 (the 2 bytes right after <dest><source>)?

In Wireshark, I've enabled all protocols but still it isn't recognized.

Also, I've read https://www.rfc-editor.org/rfc/rfc704... ch3 but still not come to an understanding.

RFC 5342
   There are two types of protocol identifier parameters that can occur
   in Ethernet frames after the initial MAC-48 destination and source
   identifiers:

      Ethertypes: These are 16-bit identifiers appearing as the initial
         two octets after the MAC destination and source (or after a
         tag) which, when considered as an unsigned integer, are equal
         to or larger than 0x0600.

      LSAPs: These are 8-bit protocol identifiers that occur in pairs
         immediately after an initial 16-bit (two octet) remaining frame
         length, which is in turn after the MAC destination and source
         (or after a tag).  Such a length must, when considered as an
         unsigned integer, be less than 0x5DC or it could be mistaken as
         an Ethertype.  LSAPs (Link-Layer Subnet Access Points) occur in
         pairs where one is intended to indicate the source protocol
         handler and one the destination protocol handler; however, use
         cases where the two are different have been relatively rare.

Broadcast frame causing my issue:

0000   ff ff ff ff ff ff b0 b9 8a 68 1e ea 00 00 00 06
0010   82 59 19 f0 82 59 65 80 74 78 2e 63 00 00 00 00
0020   00 00 00 00 00 00 00 00 00 00 01 98 00 25 18 30
0030   82 2d a1 e0 01 00 03 00 00 00 00 00 00 00 00 00
0040   00 00 00 00 00 00 00 00 1a 00 00 00 01 00 00 00
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070   00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
0080   04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00a0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00b0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00c0   00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 00
00d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00e0   00 00 00 ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-08-25 12:36:21 +0000

Hi,

The two octets field is used to indicate payload size when the value is below 0x0600 (1536). Only when the value is above 0x0600 does it refer to the protocol encapsulation.

In your case, this 0x0000 value would indicate a length of 0 but there are 286 bytes of data so this does not seem normal.

I can't think of a legitimate reason off the top of my head for this frame. You could investigate the origin by making sure (with more packet capture) it is generated from the Netgear device itself and not by another host (physical host or virtual machine) connected to it.

Hope this helps.

Cheers,

JFD

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-08-25 08:12:07 +0000

Seen: 467 times

Last updated: Aug 25 '21