Spam detection software, running on the system "mail.Millennium.Berkeley.EDU",
has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: I did a CVS update, but I've still some troubles with the
Frame Pending flag: in case the coordinator has 2 data frames pending for
a device, the first one to be requested will have its Pending Flag set (this
is OK) but the second frame will also have it whereas the coordinator doesn't
have another pending frame for the device...Is this normal ? [...]
Content analysis details: (4.6 points, 3.3 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters
3.2 FH_DATE_PAST_20XX The date is grossly in the future.
0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.4873]
0.0 AWL AWL: From: address is in the auto white-list
--- Begin Message ---
I did a CVS update, but I've still some troubles with the Frame Pending
flag: in case the coordinator has 2 data frames pending for a device, the
first one to be requested will have its Pending Flag set (this is OK) but
the second frame will also have it whereas the coordinator doesn't have
another pending frame for the device...Is this normal ?
In IndirectTxP.nc I did the following test (added lines are prefixed by
'>>'):
event message_t* DataRequestRx.received(message_t* frame)
{
uint8_t i, j, srcAddressMode, dstAddressMode, *src;
uint8_t *mhr = MHR(frame);
uint8_t destMode = (mhr[MHR_INDEX_FC2] & FC2_DEST_MODE_MASK);
ieee154_txframe_t *dataResponseFrame = NULL;
// received a data request frame from a device
// have we got some pending data for it ?
srcAddressMode = (mhr[MHR_INDEX_FC2] & FC2_SRC_MODE_MASK);
if (!(srcAddressMode & FC2_SRC_MODE_SHORT))
return frame; // no source address
src = mhr + MHR_INDEX_ADDRESS;
if (destMode == FC2_DEST_MODE_SHORT)
src += 4;
else if (destMode == FC2_DEST_MODE_EXTENDED)
src += 10;
if (!((mhr[MHR_INDEX_FC1] & FC1_PAN_ID_COMPRESSION) &&
(mhr[MHR_INDEX_FC2] & FC2_DEST_MODE_SHORT)))
src += 2;
for (i=0; i<NUM_MAX_PENDING; i++) {
if (m_txFrameTable[i] == NULL)
continue;
else {
dstAddressMode = (m_txFrameTable[i]->header->mhr[MHR_INDEX_FC2] &
FC2_DEST_MODE_MASK);
if ((dstAddressMode << 4) != srcAddressMode)
continue;
else {
// we know: dstAddressMode IN [2,3]
uint8_t *dst &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS]) + 2;
uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8);
for (j=0; j<len; j++)
if (dst[j] != src[j])
break; // no match!
if (j==len) { // match!
if (dataResponseFrame == NULL) {
dataResponseFrame = m_txFrameTable[i];
>> if ( dataResponseFrame->header->mhr[ MHR_INDEX_FC1 ] &
FC1_FRAME_PENDING )
>> Leds.led0Toggle();
}
else // got even more than one frame for this device: set
pending flag
dataResponseFrame->header->mhr[MHR_INDEX_FC1] |FC1_FRAME_PENDING;
}
}
}
}
if (dataResponseFrame != NULL) {
// found a matching frame, mark it for transmission
dbg_serial("IndirectTxP", "We have data for this device, trying to
transmit...\n");
dataResponseFrame->client |= SEND_THIS_FRAME;
post tryCoordCapTxTask();
} else {
dbg_serial("IndirectTxP", "We don't have data for this device, sending
an empty frame...\n");
transmitEmptyDataFrame(frame);
}
return frame;
}
And LED 0 is toggled when the second data request is received from the
device, how can this be possible ?
Thank you very much for your help...
Jonathan
-----Message d'origine-----
De : [email protected] [mailto:[email protected]] De la part de Jan
Hauer
Envoyé : lundi 15 février 2010 17:45
À : Jonathan ROY
Cc : [email protected]
Objet : Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled
mode
The code you posted is from an old version of IndirectTxP.nc, do a CVS
update and take a look at line 232. Anyway, what is still missing is
the device-side. It is on my todo list, but I will definitely not
manage to do this within the next two weeks. Since it is probably not
so complex you might want to take a look whether you can add the
functionality yourself, you would have to edit PollP.nc (there is a
comment in line 202, this is where you'd start). If you succeed, I'd
be happy to integrate your code.
Jan
On Sat, Feb 13, 2010 at 11:12 PM, Jonathan ROY <[email protected]>
wrote:
> Thank you for your answer Jan, but when I look to
> tos/lib/mac/tkn154/IndirectTxP.nc it seems that the coordinator doesn't
set
> the Frame Pending flag in a DATA frame if it has more DATA frames for the
> same device:
>
> event message_t* DataRequestRx.received(message_t* frame)
> {
> uint8_t i, j, srcAddressMode, dstAddressMode, *src;
> uint8_t *mhr = MHR(frame);
> uint8_t destMode = (mhr[1] & FC2_DEST_MODE_MASK);
>
> // received a data request frame from a device
> // have we got some pending data for it ?
> if (!m_numTableEntries)
> return frame;
> srcAddressMode = (mhr[1] & FC2_SRC_MODE_MASK);
> if (!(srcAddressMode & FC2_SRC_MODE_SHORT))
> return frame; // no source address
> src = mhr + MHR_INDEX_ADDRESS;
> if (destMode == FC2_DEST_MODE_SHORT)
> src += 4;
> else if (destMode == FC2_DEST_MODE_EXTENDED)
> src += 10;
> if (!((mhr[0] & FC1_PAN_ID_COMPRESSION) && (mhr[1] &
> FC2_DEST_MODE_SHORT)))
> src += 2;
> for (i=0; i<NUM_MAX_PENDING; i++){
> if (!m_txFrameTable[i])
> continue;
> else {
> dstAddressMode = (m_txFrameTable[i]->header->mhr[1] &
> FC2_DEST_MODE_MASK);
> if ((dstAddressMode << 4) != srcAddressMode)
> continue;
> else {
> // we know: dstAddressMode IN [2,3]
> uint8_t *dst > &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS])
> + 2;
> uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8);
> for (j=0; j<len; j++)
> if (*dst != *src)
> break;
> if (j==len)
> break; // match! break from outer loop
> }
> }
> }
> call Debug.log(LEVEL_INFO, IndirectTxP_REQUESTED,
> NUM_MAX_PENDING-i,i,*src);
> if (i != NUM_MAX_PENDING){
> // found a matching frame, mark it for transmission
> m_txFrameTable[i]->client |= SEND_THIS_FRAME;
> post tryCoordCapTxTask();
> } else {
> // TODO: send an empty data frame to the device
> }
> return frame;
> }
>
> I've tried to fix this issue but it doesn't seem to work better:
>
> event message_t* DataRequestRx.received(message_t* frame)
> {
> uint8_t i, j, srcAddressMode, dstAddressMode, *src;
> uint8_t *mhr = MHR(frame);
> uint8_t destMode = (mhr[1] & FC2_DEST_MODE_MASK);
> ieee154_txframe_t *txFrame = NULL;
>
> // received a data request frame from a device
> // have we got some pending data for it ?
> if (!m_numTableEntries)
> return frame;
> srcAddressMode = (mhr[1] & FC2_SRC_MODE_MASK);
> if (!(srcAddressMode & FC2_SRC_MODE_SHORT))
> return frame; // no source address
> src = mhr + MHR_INDEX_ADDRESS;
> if (destMode == FC2_DEST_MODE_SHORT)
> src += 4;
> else if (destMode == FC2_DEST_MODE_EXTENDED)
> src += 10;
> if (!((mhr[0] & FC1_PAN_ID_COMPRESSION) && (mhr[1] &
> FC2_DEST_MODE_SHORT)))
> src += 2;
> for (i=0; i<NUM_MAX_PENDING; i++){
> if (!m_txFrameTable[i])
> continue;
> else {
> dstAddressMode = (m_txFrameTable[i]->header->mhr[1] &
> FC2_DEST_MODE_MASK);
> if ((dstAddressMode << 4) != srcAddressMode)
> continue;
> else {
> // we know: dstAddressMode IN [2,3]
> uint8_t *dst > &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS])
> + 2;
> uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8);
> for (j=0; j<len; j++)
> if ( dst[ j ] != src[ j ] )
> break;
> if (j==len)
> {
> if ( txFrame == NULL )
> txFrame = m_txFrameTable[ i ];
> else // More than one frame for this device: set Frame Pending
> flag
> {
> txFrame->header->mhr[ 0 ] |= FC1_FRAME_PENDING;
> break; // break from outer loop
> }
> }
> }
> }
> }
> call Debug.log(LEVEL_INFO, IndirectTxP_REQUESTED,
> NUM_MAX_PENDING-i,i,*src);
> if ( txFrame != NULL )
> {
> // found a matching frame, mark it for transmission
> txFrame->client |= SEND_THIS_FRAME;
> post tryCoordCapTxTask();
> }
> else
> {
> // TODO: send an empty data frame to the device
> }
> return frame;
> }
>
>
> Is there something else to do ? I really need this functionality to
work...
> Thanks,
>
> Jonathan
>
>
> -----Message d'origine-----
> De : Jan Hauer [mailto:[email protected]]
> Envoyé : jeudi 11 février 2010 18:16
> À : Jonathan ROY
> Cc : [email protected]
> Objet : Re: [Tinyos-help] 802.15.4: Indirect transmissions in
beacon-enabled
> mode
>
>
>> Content preview: Hi, I would like to do some tests using the 802.15.4
> implementation
>> (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple
> indirect
>> transmissions to the same destination" functionality is missing, can
> someone
>> explain me in details what is the problem and its consequences please ?
> [...]
>
>
> Sect. 7.5.6.3 of IEEE 802.15.4-2006:
> "If the Frame Pending subfield of the Frame Control field of the data
> frame received from the coordinator is set to one, the device still
> has more data pending with the coordinator. In this case it may
> extract the data by sending a new data request command to the
> coordinator."
>
> In the current implementation the coordinator sets the Frame Pending
> flag in a DATA frame if it has more DATA frames for the same device,
> but the device will not immediately poll for the DATA frame - instead,
> it will wait for the next beacon and poll afterwards.
>
> Jan
>
>
> On Thu, Feb 11, 2010 at 5:34 PM, Jonathan ROY <[email protected]>
> wrote:
>> Spam detection software, running on the system
> "mail.Millennium.Berkeley.EDU", has
>> identified this incoming email as possible spam. The original message
>> has been attached to this so you can view it (if it isn't spam) or label
>> similar future email. If you have any questions, see
>> the administrator of that system for details.
>>
>> Content preview: Hi, I would like to do some tests using the 802.15.4
> implementation
>> (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple
> indirect
>> transmissions to the same destination" functionality is missing, can
> someone
>> explain me in details what is the problem and its consequences please ?
> [...]
>>
>>
>> Content analysis details: (4.6 points, 3.3 required)
>>
>> pts rule name description
>> ---- ----------------------
> --------------------------------------------------
>> 1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters
>> 3.2 FH_DATE_PAST_20XX The date is grossly in the future.
>> 0.0 HTML_MESSAGE BODY: HTML included in message
>> 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
>> [score: 0.5000]
>>
>> The original message was not completely plain text, and may be unsafe to
>> open with some email clients; in particular, it may contain a virus,
>> or confirm that your address can receive spam. If you wish to view
>> it, it may be safer to save it to a file and open it with an editor.
>>
>>
>> _______________________________________________
>> Tinyos-help mailing list
>> [email protected]
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>
>
>
>
--- End Message ---
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
