Author Topic: Some questions about RFM69 library v1.3.0  (Read 3086 times)

Uncle Buzz

  • Full Member
  • ***
  • Posts: 146
  • Country: fr
Some questions about RFM69 library v1.3.0
« on: November 16, 2019, 08:33:30 PM »
Some questions about RFM69 library :

First,  I use the v1.3.0 (last one from arduino library manager), and RF69_BROADCAST_ADDR is 255, not 0 like argued in the blog

Secondly, When we send a broadcast, all nodes will receive the message, but we don't want to send an ACK from every node, that's what do the code below :

Code: [Select]
// check whether an ACK was requested in the last received packet (non-broadcasted packet)
bool RFM69::ACKRequested() {
  return ACK_REQUESTED && (TARGETID != RF69_BROADCAST_ADDR);
}

But if the radio on a node is in promiscuous mode, it will receive the message even if the target node is another one and the target node is not the broadcast address, but we don't want this "spy" send an ACK answer because it could make collision with the ACK of the target node, even if his ACK will be ignored. To my mind we should check if the TARGETID corresponds to our NODEID, and since our NODEID couldn't be RF69_BROADCAST_ADDR the code below would deal with these case :

Code: [Select]
// check whether an ACK was requested in the last received packet (non-broadcasted packet)
bool RFM69::ACKRequested() {
  return ACK_REQUESTED && (TARGETID == _address);
}

Am I correct ?
« Last Edit: November 17, 2019, 04:06:27 AM by Uncle Buzz »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Some questions about RFM69 library v1.3.0
« Reply #1 on: November 18, 2019, 11:23:15 AM »
I'm not sure what you're really asking.
If you send a broadcast, then you should not request an ACK. And no receiver should send back an ACK regardless of anything, if the target ID == BROADCAST. That's what the check does.

Uncle Buzz

  • Full Member
  • ***
  • Posts: 146
  • Country: fr
Re: Some questions about RFM69 library v1.3.0
« Reply #2 on: November 18, 2019, 12:51:41 PM »
There are 2 ways for a message to be received by more than one node :
  • a message sent on the broadcast address
  • a message sent to a unique node, but with other nodes in promiscuous mode
A node in promiscuous mode can read the message sent for another one and see the Ack requested. Since the targetID is not the broadcast address in this case, ACKRequested() will return true even if the node is not the target, so the node in promiscuous mode will send an ACK back to the sender node.
The ACK from the wrong node will be ignored by the sender node, but it could collision with the ACK from the correct target node.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Some questions about RFM69 library v1.3.0
« Reply #3 on: November 18, 2019, 01:06:49 PM »
A spying node is ... a spy, not supposed to say "hey everyone im here spying here are some ACKs".
So why don't you send 2 packets, instead of a broadcast?
Or ignore the ACK request on the spying node.

Uncle Buzz

  • Full Member
  • ***
  • Posts: 146
  • Country: fr
Re: Some questions about RFM69 library v1.3.0
« Reply #4 on: November 18, 2019, 01:22:51 PM »
To my mind, a spy shouldn't reply to an ACK requested to another one. This could be written in the sketch of the spy, but it should be written for each sketch, and some times a spy can de the target of an ACK so we have to check if we are the target or just spying...
If we check in ACKRequested function if we are the target, it will avoid sending an ACK from a broadcast message since our address should not be equal to the broadcast address and also avoid to send an ACK if the message is sent to someone else without adding some code on each sketch for a spy...
Code: [Select]
// check whether an ACK was requested in the last received packet (non-broadcasted packet)
bool RFM69::ACKRequested() {
  return ACK_REQUESTED && (TARGETID == _address);
}

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Some questions about RFM69 library v1.3.0
« Reply #5 on: November 18, 2019, 01:50:41 PM »
Ok let me try to clarify some things about BROADCAST use and the promiscuous mode (aka "spy" in this thread):

- The condition (TARGETID == _address) is verified in the interrupt handler. A node cannot receive anything unless (TARGETID == _address) or if it's a spy, here's the full condition:
if(!(_promiscuousMode || TARGETID == _address || TARGETID == RF69_BROADCAST_ADDR) // match this node's address, or broadcast address or anything in promiscuous mode
You never get to check that ACKReqested() if that node didnt even pass the condition above.

- A spy doesn't technically "exist". It is simply only listening, for debugging purposes at most. You're not supposed to have spies that are active nodes that do something, it makes no sense. Maybe I should gut that out of the library, it makes people think that this mode is an actual valid use case, when it might only encourage a nonconventional way of using it. It's only there because some folks thought it might be useful to inject a node that listens and spits out serial of intercepted messages. Let me add a little note here: I never used promiscuous mode, in any application I built, it was not necessary.

- If TARGET == BROADCAST is TRUE then we don't do anything, ever, on any node. We don't call ACKRequested(), we dont respond to ACKs, no matter what. Regardless if we're a spy or not. In addition, a spy will never take any action regardless of any condition. It just listens, that's it.


Uncle Buzz

  • Full Member
  • ***
  • Posts: 146
  • Country: fr
Re: Some questions about RFM69 library v1.3.0
« Reply #6 on: November 18, 2019, 04:22:53 PM »
- A spy doesn't technically "exist". It is simply only listening, for debugging purposes at most. You're not supposed to have spies that are active nodes that do something, it makes no sense.
I'm not agree with this statement, promiscuous mode could be used for other things than spying. I'm agree a node in promiscuous mode should not reply to an ACK request to another node, but I think it's better to deal with this in ACKRequested function which will do the same as now, and not argue that's not how it should be used.

In my case, I'm trying to reproduce a DHCP like system, where new nodes doesn't know who are the gateways... I could send a request with broadcast, but every nodes on same network will receive it, and have to check what they received to decide to ignore it, but with promiscuous mode, servers are the only nodes to see the request (servers don't have a known address) and to have to deal with.

Maybe there are better ways to achieve what I want, but you can't imagine all the ways people could use your moteino.

Since "TARGETID  != RF69_BROADCAST_ADDR" is included in "TARGETID == _address" it doesn't change how it works right now, but rejects any reply from a "spy" even if you don't imagine why it could happen.

Maybe I misunderstand your reply, but it's like you are trying to defend you, sorry if I seem offensive, that's not my intend, it would just be because I'm far to be fluent with english and can't translate exactly what I mean.

For the first question, you wrote the RF69_BROADCAST_ADDR will be 0 in your library, but it's 255, where's the wrong statement ? will it change in next update, or the blog is wrong ?
« Last Edit: November 18, 2019, 04:24:25 PM by Uncle Buzz »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Some questions about RFM69 library v1.3.0
« Reply #7 on: November 19, 2019, 09:54:31 PM »
Uncle Buzz,
Your english is really great, no worries. I was perhaps a little too defensive yes.
Your proposal is actually not a bad one at all. It would ensure that only a target would ever respond to an ACK. But I would still hold my position on using the "spy" mode. In fact after this thread (and me never really using it) I think "spy" is a better name instead of promiscuous - which if the word you'd use if you're cheating on your wife  :o

So ... I will consider it. Do you use Github? Do you want to submit a PR?
If not, it's OK, I will change it locally and try to double check and submit it myself sometime later. Let me know..

Thanks

Uncle Buzz

  • Full Member
  • ***
  • Posts: 146
  • Country: fr
Re: Some questions about RFM69 library v1.3.0
« Reply #8 on: November 20, 2019, 03:35:26 AM »
I don't have an account on Github, I'm a "hobbyist", not a programmer (not the talent) so I use a local SVN repository but my code is probably not something to show, even when it works  ;D

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Some questions about RFM69 library v1.3.0
« Reply #9 on: November 20, 2019, 09:48:12 AM »
How about this:

Code: [Select]
bool RFM69::ACKRequested() {
  return ACK_REQUESTED && (TARGETID != RF69_BROADCAST_ADDR) && (TARGETID == _address);
}

Uncle Buzz

  • Full Member
  • ***
  • Posts: 146
  • Country: fr
Re: Some questions about RFM69 library v1.3.0
« Reply #10 on: November 20, 2019, 10:25:57 AM »
_address should never be equal to RF69_BROADCAST_ADDR, so TARGETID == _address is enough, it's not needed to test the RF69_BROADCAST_ADDR anymore since if TARGETID == _address is true, so is TARGETID != RF69_BROADCAST_ADDR

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Some questions about RFM69 library v1.3.0
« Reply #11 on: November 20, 2019, 03:26:03 PM »
_address should never be equal to RF69_BROADCAST_ADDR
Yes, should never, you'd be surprised what people do sometimes. That was exactly my initial point that we don't need any changes if people did use this properly (or not use it!) in the first place.
The extra check won't hurt, ensures only IDs 0-254 would ever respond with an ACK.

Uncle Buzz

  • Full Member
  • ***
  • Posts: 146
  • Country: fr
Re: Some questions about RFM69 library v1.3.0
« Reply #12 on: November 20, 2019, 04:43:49 PM »
That was exactly my initial point that we don't need any changes if people did use this properly (or not use it!) in the first place.
You scored 1 point !
You could lock this possibility by forbidden  the RF69_BROADCAST_ADDR in RFM69 consctrutor and setAddress function... But as I said, you can't imagine how people could use your work, how a genius brain could hack your moteino or library to build something you would never imagine...
so keeping your proposal seems the better solution and keeps some freedom for stupid and genius hacker.