Pascal Quantin
changed
bug 11653
| What |
Removed |
Added |
| Status |
UNCONFIRMED
|
INCOMPLETE
|
| CC |
|
ankith13@gmail.com, pascal.quantin@gmail.com
|
| Ever confirmed |
|
1
|
Comment # 1
on bug 11653
from Pascal Quantin
According to 8.2.21 standard chapter F.3.11, MIHF ID is an octet string defined
as follows:
"The MIHF Identifier: MIHF_ID is a network access identifier (NAI).
NAI shall be unique as per IETF RFC 4282. If L3 communication is
used and MIHF entity resides in the network node, then MIHF_ID is
the fully qualified domain name or NAI-encoded IP address
(IP4_ADDR or IP6_ADDR) of the entity that hosts the MIH Services.
If L2 communication is used then MIHF_ID is the NAI-encoded link-
layer address (LINK_ADDR) of the entity that hosts the MIH ser-
vices. In an NAI-encoded IP address or link-layer address, each octet
of binary-encoded IP4_ADDR, IP6_ADDR and LINK_ADDR data is
encoded in the username part of the NAI as “\” followed by the octet
value. A multicast MIHF identifier is defined as an MIHF ID of zero
length. When an MIH protocol message with multicast MIHF ID is
transmitted over the L2 data plane, a group MAC address (01-80-C2-
00-00-0E) shall be used (see IEEE P802.1aj/D2.2). The maximum
length is 253 octets."
The code currently assumes that the payload (the 12 bytes you are referring to)
starts with the string length in the first byte, followed by the string itself.
This is how the packets found in bug 5881 are formatted. But in your case there
is no extra byte giving the length. So one of them is buggy.
Does this pcap file come from a product you are currently developing? Or is it
a commercial one? At first glance I tend to agree with your packet dump but it
would mean that the ones provided in bug 5881 were buggy.
Ankit, can you comment?
You are receiving this mail because:
- You are watching all bug changes.
