Xavier Vilajosana writes:
> what is the difference between what you propose in the new version
>
> "I think the current proposal will
> be more like what implementations actually do, i.e. they have special
> flag which says they are doing a scan, and they will then accept all
> beacons, but no other frames or something like that (this change will
> be in the next revision of the draft, so I have not yet read the final
> text)."
>
> and using macImplicitBroadcast?
macImplicitBroadcast does not have any meaning for the scanning. It is
used during the normal operations, i.e. if that is true and you
receive frame without destination address or PAN ID you assume it was
meant to be broadcast message, not message to coordinator.
> According to 15.4e (2012) macImplicitBroadcast (default=false)
> "Indicates whether frames without a destination
> PAN ID or destination address are to treated as
> though they are addressed to the broadcast
> PANID (0xffff) and broadcast short address
> (0xfffff)"
>
> Does this mean that if Dst Address and Dst PANID are elided we need
> macImplicitBroadcast set to TRUE in order to be able to identify the
> frame?
Normal case if you do not have destination address, or destination PAN
id you only pass the filtering rules in then "6.7.2 Reception and
rejection" section if the source PAN ID matches the macPanId and you
are coordinator.
If macImplicitBroadcast is true then you ignore the destination
address filters and assume that message was sent to broadcast
addresses if destination addresses are missing
Of course to be able to use macImplicitBroadcast broadcast you need to
be sure that all devices in the network are using same value for this
settings, as otherwise you do not know whether no destination address
means coordinator or whether it mean broadcast.
All this do not have anything to do with scanning.
In the "6.3.1.2 Active and passive channel scan" there is text which
says:
Before commencing an active or passive scan, the MAC sublayer
shall store the value of macPanId and then set it to 0xffff
for the duration of the scan. This enables the receive filter
to accept all beacons rather than just the beacons from its
current PAN, as described in 6.7.2. On completion of the scan,
the MAC sublayer shall restore the value of macPanId to the
value stored before the scan began.
This was trying to modify the filtering rules in in the 6.7.2 so that
the check like:
If a destination PAN ID is included in the frame, it shall
match macPanId or shall be the broadcast PAN ID.
would always match, and that would not filter frames based on the
destination PAN ID. Unfortunately this is completely wrong, as if you
read that test it will match if the detination PAN ID matches macPanId
(0xffff in this case as it was set so in 6.3.1.2), or whether
destination PAN ID is broadcast PAN ID (== 0xffff). I.e. this
statement does not have the same text that is in the Source PAN ID
test, where it actually tests if macPanId is 0xffff, and if frame is
beacon it will pass it through. So the text in the 6.3.1.2 is wrong
when it claims "This enables the receive filter to accept all
beacons". It only allows beacons with any source pan id, but
destination pan id still needs to be broadcast pan id (which I think
it mostly likely always is).
> I assume (for minimal) we want to stay in most of the default values.
> Therefore, macImplicitBroadcast set to FALSE, and dst address (short) and dst
> PANID to be explicit (0xffff).
Yes.
> As a second point: Would the use of macImplicitBroadcast change in
> the new version?
No, there is no change for that. It is still going to be broken in a
sense that it needs to be same for everybody in the network, and there
is no mechanism to ensure that, but it will still work as before. And
it still does not have anything to do with active or passive scans.
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
