nrf24 / rf24gateway

TCP/IP (RF24Ethernet) and RF24Network Gateway

RF24Gateway

A complimentary library to RF24Ethernet, for RPi/Linux devices.

RF24Ethernet allows small Arduino/AVR devices to communicate using TCP/IP over nrf24l01 radio modules.

RF24Gateway allows a RPi/Linux device to act as a gateway for those nodes, handling IP traffic automatically, while allowing users to utilize standard RF24Network messages as well.

Introducing RF24Network & RF24Mesh & RF24Gateway v2.0 with some significant API changes, adding the use of C++ Templates in order to support a range of ESB enabled radios, most recently NRF52x radios.

Important Notes:

• Any network layer that uses v2 needs to have RF24Network/RF24Mesh dependencies of v2 or newer. RF24 v1.x is an exception here.
• General usage should remain backward compatible, see the included examples of the related libraries for more info
• Any third party libs that extend the network/mesh layer may also need to be updated to incorporate the new templated class prototypes:

template<class radio_t>
class ESBNetwork;
  
template<class network_t, class radio_t>
class ESBMesh;

• Third party libs should also be able to use the backward-compatible typedef in their template:
  • ESBGateway.h:

  template<typename network_t, typename mesh_t>
  class ESBGateway

  and inform the compiler what types they intend to support:
  • ESBGateway.cpp:

  template class ESBGateway<RF24Network, RF24Mesh>;

• The auto installers do not perform a version check like package managers, so having the correct versions of the software is important.
• We will be maintaining the v1.x versions with bugfixes etc for those who cannot or do not wish to migrate to the newer template approach.

Documentation:

http://nRF24.github.io/RF24Gateway

http://nRF24.github.io/RF24Ethernet

All: http://tmrh20.github.io

rf24gateway's Issues

Send/Receive Loop when trying to use MQTT over RF24Ethernet/RF24Gateway

When putting an MQTT client on an Arduino UNO, thanks to the awesome RF24* libraries (which implement the Client.h interface) we can have it communicate over the RF24Ethernet library to a mosquitto server on a Raspberry Pi. The MQTT client is found here https://github.com/knolleary/pubsubclient, the MQTT server is mosquitto.

Everything works great (publishing and subscribing messages, reconnecting etc) but I have found a strange problem. I noticed lots of TX and RX traffic on the RF24Gateway dashboard. Running the mosquitto server with verbose output (mosquitto -v), I could see that the Arduino was constantly firing a SUBSCRIBE request, and the mosquitto server was acknowledging it.

Racking up the RF24Ethernet debugging, I can see that the code repeatedly reaches this line in RF24Client.cpp:

IF_ETH_DEBUG_L2( Serial.print(F("UIPClient stop?????? ")); Serial.println(data->state & UIP_CLIENT_SOCKETS); Serial.println(F("**")); Serial.println(data->state,BIN); Serial.println(F("**")); Serial.println(UIP_CLIENT_SOCKETS,BIN); Serial.println(F("**")); );.

This produces the output UIPClient stop?????? 0 ** 10000 ** 11111111111111111111111100001111 **.

After a while, this back-and-forth ends, but then the same starts happening when there is a ping handshake between client and server. Then the whole RF2Ethernet connection seems to drop, and after reconnect everything starts over again.

I have tried all kinds of configuration changes, tried to trace through all the different libraries (including PubSubClient). I noticed there that the PubSubClient actually only sends the SUBSCRIBE request once, but somehow RF24* repeats sending that same request, every time the SUBACK message from the MQTT server arrives.

I feel that I do not understand the whole stack of libraries enough to make any headway with this problem.

Could somebody else maybe try the sketch and see if they encounter the same problem? Or maybe someone already got MQTT over RF24 running smoothly?

Here is the sketch I am trying:
https://gist.github.com/Krifto/865456a1f9596c0878b3

Simple Gateway with Arduino/ATmega (question)

Is there something like RF24Gateway for ATmega?

I'm prototyping a sensor network that uses ATmega328P MCUs, and I'd like to avoid having to add in a Rasp Pi to bridge sensor data to the internet as (I think) this library requires (for power reasons mostly). My plan was to have the master/gateway node use both an nRF24L01+ and an ESP8266 module. I've got a couple sensors running using your RF24 library now, and I'm planning on moving to your RF24Network library to simplify addressing, routing, reliability, maintenance, and growth.

I think it won't be too complex to have the RF24Network master node receive messages from the sensors and generate the appropriate HTTP or MQTT message to send over wifi, but wanted to check if you know of code that does this since it seems like a common use case. Note that the sensors will never have to receive data from the TCP/IP network.

Also, thanks a ton not only for these libraries, but also for the awesome documentation of them.

RF24Gateway doesn't seem to work with a recent version of the libraries and Raspbian

I just did a fresh install on an up-to-date Raspberry Pi 2 and the Ethernet examples don't seem to work. The RPi has been installed using the script from http://tmrh20.github.io/RF24Installer/RPi/install.sh . Up to the RF24Mesh layer everything is fine and the mesh examples work as expected.

The setup is a RPi2 with RF24Gateway and a STM32 as Arduino with any of the RF24Ethernet examples.

It doesn't matter if a server or client example is ran and different IPs have also been tried. Using the default 10.10.2.2 on the RPi and 10.10.2.4 on the examples. If a server example is used "curl" times out and "nc" will never show anything. On a client example the client will never succesfully connect.

While trying to connect RF24Gateway_ncurses shows that the RX packet count increases, but TX is not counting.
On a server example when attempting to connect the TX count increases, but RX does nothing.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -j MASQUERADE

have been executed on the Pi. Ping also does not work, though the Pi can ping itself on both interfaces.

Client example log:

Disconnect. Waiting for disconnect timeout
354343 stop(), data: NULL
connecting
359346 stop(), data: NULL
359418 RF24Ethernet Network Write OK
359976 RF24Ethernet Network Write OK
361030 RF24Ethernet Network Write OK
363076 RF24Ethernet Network Write OK
connection failed

traceroute is not giving any hints:

pi@rf24gateway:~/rf24libs/RF24Gateway/examples $ sudo traceroute -I 10.10.2.4
traceroute to 10.10.2.4 (10.10.2.4), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

RF24Gateway_ncurses causes wlan0 if to go down

When I'm starting RF24Gateway_ncurses on my RPI 2, wlan0 interface immediately goes down:

Apr 22 14:09:24 raspberrypi ifplugd(tun_nrf24)[2561]: Link beat detected.
Apr 22 14:09:24 raspberrypi ifplugd(tun_nrf24)[2561]: Executing '/etc/ifplugd/ifplugd.action tun_nrf24 up'.
Apr 22 14:09:24 raspberrypi wpa_supplicant[4257]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=0
Apr 22 14:09:24 raspberrypi ifplugd(tun_nrf24)[2561]: client: OK
Apr 22 14:09:24 raspberrypi ifplugd(tun_nrf24)[2561]: client: Ignoring unknown interface tun_nrf24=tun_nrf24.
Apr 22 14:09:24 raspberrypi wpa_action: WPA_IFACE=wlan0 WPA_ACTION=DISCONNECTED
Apr 22 14:09:24 raspberrypi wpa_action: WPA_ID=0 WPA_ID_STR= WPA_CTRL_DIR=/var/run/wpa_supplicant
Apr 22 14:09:24 raspberrypi wpa_action: ifdown wlan0
Apr 22 14:09:24 raspberrypi dhclient: Internet Systems Consortium DHCP Client 4.2.2
Apr 22 14:09:24 raspberrypi dhclient: Copyright 2004-2011 Internet Systems Consortium.
Apr 22 14:09:24 raspberrypi dhclient: All rights reserved.
Apr 22 14:09:24 raspberrypi dhclient: For info, please visit https://www.isc.org/software/dhcp/
Apr 22 14:09:24 raspberrypi dhclient: 
Apr 22 14:09:24 raspberrypi ifplugd(tun_nrf24)[2561]: Program executed successfully.
Apr 22 14:09:24 raspberrypi ifplugd(wlan0)[4240]: Link beat lost.
Apr 22 14:09:24 raspberrypi dhclient: Listening on LPF/wlan0/24:05:0f:xx:xx:xx
Apr 22 14:09:24 raspberrypi dhclient: Sending on   LPF/wlan0/24:05:0f:xx:xx:xx
Apr 22 14:09:24 raspberrypi dhclient: Sending on   Socket/fallback
Apr 22 14:09:24 raspberrypi dhclient: DHCPRELEASE on wlan0 to 192.168.1.254 port 67
Apr 22 14:09:24 raspberrypi wpa_action: removing sendsigs omission pidfile: /run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid

Address turns up on address list (Pi), doesn't connect from Arduino

Hi, I'm struggling to find a solution for this. This has some crossover with Issue #13. I am trying to get a couple of 1) nrf24l01 with the external antenna connected to an Arduino Pro Mini to talk to 2) another nrf24l01 connected to a Raspberry Pi 4. I've run the basic tests:

1. Works on the basic RF24 example
2. Works on the RF24mesh example (RF24Mesh example on the Arduino, and the example in /rf24libs/RF24Mesh/examples_RPi/ncurses/bin) - pings work. I however, cannot ping from the Pi to the device eg ping 10.1.1.24 but pinging the host (itself) works.... 10.1.1.1

As additional information, the nrf modules are connected to the VCC pin of the Pro Mini which ranges from 3.17 to 3.22V but settles at 3.17 (I don't have a scope atm, so this is just from a multimeter). The modules also have a 106 capacitor across the VCC and G inputs, close to the module (5mm away or so).

Some of the things I've tried to figure out what's going on is/are:

When I try running the stock RF24Network MQTT example (just changing pins and IP address), the code cuts off after 'connecting...' which is the connect() function. The following is displayed in the Serial Console:

12:59:24.351 -> connecting... OK
12:59:26.012 -> arduinoClient25 
12:59:26.012 -> connecting... OK
12:59:27.677 -> arduinoClient25 
12:59:27.677 -> connecting... OK
12:59:29.304 -> arduinoClient25 
...

I heavily commented the example to figure out where it breaks and I can only see "a" being printed to the console

void connect() {
  Serial.print("connecting...");
  uint32_t clTimeout = millis();
                                                                                                 Serial.println(" a");
  while (!client.connect(clientID)) {
    Serial.print(".");
    if (millis() - clTimeout > 5001) {
      Serial.println();
                                                                                                 Serial.println(" b");
      return;
    }
                                                                                                 Serial.println(" c");
    uint32_t timer = millis();
    //Instead of delay, keep the RF24 stack updating
    while (millis() - timer < 1000) {
                                                                                                 Serial.println(" d");
      Ethernet.update();
    }
  }
                                                                                                 Serial.println(" e");
  Serial.println("\nconnected!");
                                                                                                 Serial.println(" f");
  client.publish("outTopic", "hello world");
  client.subscribe("inTopic", 2);
}

I also enabling debug options as in #13 and got the following output, and the last message prior to the script looping is this:

13:26:24.515 -> 
184: NET Sending ⸮⸮�⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮�(⸮��⸮⸮'⸮⸮'⸮��⸮��⸮��⸮��⸮��⸮��%u: MAC FWD multicast frame from 0%o to level %u
13:26:24.515 -> 
13:26:24.515 -> 
198: NET message 00 04 
13:26:24.515 -> 
200: MAC Sending to 00 via 00 on pipe 0
13:26:24.515 -> 
204: NET Pipe 0 on node 04 has address 0cccc
13:26:24.515 -> 
212: MAC Received ⸮⸮�⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮�(⸮��⸮⸮'⸮⸮'⸮��⸮��⸮��⸮��⸮��⸮��%u: MAC FWD multicast frame from 0%o to level %u
13:26:24.515 -> 
13:26:24.515 -> 
225: NET message 0000
13:26:24.515 -> 
227: MAC System payload rcvd 0
13:26:24.515 ->  OK

I have no idea where to go from here, do you have any tips on what I can do to the MQTT working using RF24 Gateway please? Is using RF24mesh and writing a script to push any output to MQTT an option?

Edit: I've also tried setting radio.setPALevel(RF24_PA_LOW); after mesh.begin(); as I wondered if it may have to do with the current requirements but there was no change.

RF24Gateway master node can't route external packets to other nodes

Hi, as discussed in emails, it seems that the Pi running the RF24Gateway master node (0) can't route packets destined to be delivered via other nodes if it has received them from outside the Pi.

A rough workaround to deliver specific packets from master node to a single other node (33) was helpfully provided by @TMRh20, which I tested and works:

//if ( (meshAddr = mesh.getAddress(lastOctet)) > 0 || thisNodeID) {
if ( (meshAddr = mesh.getAddress(33)) > 0 || thisNodeID) {  
  RF24NetworkHeader header(meshAddr, EXTERNAL_DATA_TYPE);
  if(thisNodeID){ //If not the master node, send to master (00)
    header.to_node = 00;
  }
  ok = network.write(header, msgTx->message, msgTx->size);

A patch is requested which filters destination and own IP/mask and sends to specific nodes in response.

Thanks for the libraries!

Not clear how to adjust MAX_PAYLOAD_SIZE to avoid 117 byte MTU problem

Tried directions from #8 but resulted in Linux core on Raspberry Pi Zero. Resolution of 117 byte max MTU RF24Network restriction appears out of date or no longer applies. Please advise.

There is a work around to instead adjust TUN MTU as described below. Do you recommend the workaround or instead modifying MTU RF24Network restriction?

RF24Gateway Ncurses Interface by TMRh20 - 2015
─────────────────────────────────────────────────────────────
tun_nrf24 IP: 10.10.3.1
<snip>
─────────────────────────────────────────────────────────────
 Program received signal SIGSEGV, Segmentation fault.

(gdb) where
#0  0xb6fbc030 in memcpy () from /usr/lib/arm-linux-gnueabihf/libarmmem-v6l.so
#1  0xb6ef9100 in RF24Gateway::handleRadioIn() ()
   from /usr/local/lib/librf24gateway.so.1
#2  0xb6ef8f08 in RF24Gateway::update(bool) ()
   from /usr/local/lib/librf24gateway.so.1
#3  0x00014364 in main ()
(gdb)

RF24Network_config.h
#define MAX_PAYLOAD_SIZE 1490

Default tunnel MTU is left at 1500 when testing PAYLOAD 1490. Value suggested in original problem was also tried without success. Changing the Linux tunnel MTU value, even to 144 when PAYLOAD is 1490, appears to make no difference. Core is produced.

NOTE: Setting linux MTU on the tunnel to 144 allows the tunnel to function as expected when default PAYLOAD is 144.

Test environment is two Rasperry Pi zero modules with usb networking adaptors, RS232 serial console, and rLN24L01+ modules soldered to a Rasperry Pi hat perfboard. BCM and Linux NRF24 drivers both core dump.

Can't send packets longer than 124 bytes between two RF24GatewayNodes (RPi)

I would like to use RF24 for an IP link between two raspberry PIs (3B). I configured MAX_PAYLOAD_SIZE to 1514 in RF24Network_Config.h. I then set one node with its mesh id of 3 and last octet of its IP matching. The other node has mesh id of zero and its last octet of IP is 2. With the examples/RF24GatewayNode running I can ping between those two devices.

However, when I try to ping using more that 116 bytes as payload the remaining bytes are truncated. Same for TCP and UDP. Here is an example tcpdump capture of the tun interface showing missing byte with packets over 124 bytes.

sudo tcpdump -i tun_nrf24
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun_nrf24, link-type RAW (Raw IP), snapshot length 262144 bytes
00:23:41.490684 IP 10.10.2.3 > 10.10.2.2: ICMP echo request, id 33, seq 1, length 124
00:23:41.490785 IP 10.10.2.2 > 10.10.2.3: ICMP echo reply, id 33, seq 1, length 124
00:23:42.489425 IP 10.10.2.3 > 10.10.2.2: ICMP echo request, id 33, seq 2, length 124
00:23:42.489527 IP 10.10.2.2 > 10.10.2.3: ICMP echo reply, id 33, seq 2, length 124
00:23:53.207961 IP truncated-ip - 1 bytes missing! 10.10.2.3 > 10.10.2.2: ICMP echo request, id 34, seq 1, length 125
00:23:54.221755 IP truncated-ip - 1 bytes missing! 10.10.2.3 > 10.10.2.2: ICMP echo request, id 34, seq 2, length 125

Please let me know if there is something else I can do for the MTU of 1500 to work.

Network throughput between two RPi 3B running RF24GatewayNode.

What realistic data rate one should expect when running RF24GatewayNode on two RPis sitting on the same desk? I'm only getting about 15kB/s (I tried 1MBPS and 2MBPS data rates on various channels). This is using the cheap nrf24l01 PA+LNA boards connected to RPi GPIO with 15cm long wires. SPI speed was left as is (10MHz).

Similar speeds were observed with TCP as well as UDP traffic.

Should I be looking at soldering extra filtering caps on my nrf adapters, or are there some additional software tweaks I can do to speed it up. I have to admit I was hoping for close to 100kB/s whe using 2MBPS data rate. Is this achievable?

EDIT: I have also soldered an extra 10uF tantalum cap to both nRF devices as describer elsewhere. Additionally I did try using the interrupt version of the code. This run with peak speed of about 30kB/s. This was the same with 1MBPS as well as 2MBPS settings. I also tried lowering SPI frequency (it only slowed things down) as well as lowering the power. 30kB/s was the best I got (1m distance).

Is it possible to run the RF24 GATEWAY gateway in the background?

Is it possible to run the RF24 GATEWAY gateway in the background?

Hello, again, I am using NRFGATEWAY for a raspberry pi 3, which works very well as a coordinating node, but I would like to know if it is possible to run it in the background, when we say the power goes out and the system restarts, I can start RF24GATEWAY again from the ncurses example, and passing it the ip address and netmask automatically, is this possible?

Thank you

Issue calling setStaticAddress() or setAddress() on non-master node

Calling these functions on a non-master node can cause a segfault. Reminder to fix this behaviour.

Examples: ncursesInt does not accept connections

ncurses with interrupts does not accept connections.

But plain ncurses works fine except for 100% CPU usage. I connect to MQTT and successfully send and receive messages.

Am really not sure how to debug...
I run both with root rights.

I use Arduino Nano with RF24 module as client.
How RPi should get interrupt from RF module any additional wiring required?

---

examples/gwNodeInt/RF24GatewayNodeInt tells
wiringPiISR: Can't find gpio program

maybe this is the reason?

Packets that are 117 bytes or more get corrupted

I have a very particular issue. I compiled the project and installed it on two Raspberry Pis. Then I compiled this example and ran it on the two Raspberry Pis.

I was able to ping each device back and forth.

ping 10.10.2.1 # From 10.10.2.2
ping 10.10.2.2 # From 10.10.2.1

Then, naturally, I tried to curl one of the devices from the other, but nothing happened. I verified that packets were being sent with tcpdump. The one weird thing that I noticed was that even though the packets are being received, my curl 10.10.2.2 did not show a result, which may be because of the repeating warning that 326 bytes missing!.

sudo tcpdump -i tun_nrf24

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun_nrf24, link-type RAW (Raw IP), capture size 262144 bytes
20:51:37.131645 IP 10.10.2.1.48884 > 10.10.2.2.http: Flags [S], seq 131757859, win 29200, options [mss 1460,sackOK,TS val 2462727011 ecr 0,nop,wscale 7], length 0
20:51:37.143502 IP 10.10.2.2.http > 10.10.2.1.48884: Flags [S.], seq 1415731283, ack 131757860, win 28960, options [mss 1460,sackOK,TS val 4243499299 ecr 2462727011,nop,wscale 6], length 0
20:51:37.143724 IP 10.10.2.1.48884 > 10.10.2.2.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 2462727023 ecr 4243499299], length 0
20:51:37.144036 IP 10.10.2.1.48884 > 10.10.2.2.http: Flags [P.], seq 1:74, ack 1, win 229, options [nop,nop,TS val 2462727023 ecr 4243499299], length 73: HTTP: GET / HTTP/1.1
20:51:37.166563 IP 10.10.2.2.http > 10.10.2.1.48884: Flags [.], ack 74, win 453, options [nop,nop,TS val 4243499322 ecr 2462727023], length 0
20:51:37.358333 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243499508 ecr 2462727023], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:37.592104 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243499736 ecr 2462727023], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:37.817547 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243499966 ecr 2462727023], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:38.266302 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243500416 ecr 2462727023], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:39.218605 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243501367 ecr 2462727023], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:41.058371 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243503207 ecr 2462727023], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:43.372121 IP 10.10.2.2.http > 10.10.2.1.48884: Flags [F.], seq 419, ack 74, win 453, options [nop,nop,TS val 4243505529 ecr 2462727023], length 0
20:51:43.372326 IP 10.10.2.1.48884 > 10.10.2.2.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 2462733251 ecr 4243499322,nop,nop,sack 1 {419:420}], length 0
20:51:43.389478 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243505539 ecr 2462733251], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:43.617222 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243505767 ecr 2462733251], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:44.068513 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243506217 ecr 2462733251], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:44.977209 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243507127 ecr 2462733251], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:46.817625 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243508967 ecr 2462733251], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:50.417021 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243512567 ecr 2462733251], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:51:57.617000 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 74, win 453, options [nop,nop,TS val 4243519767 ecr 2462733251], length 418: HTTP: HTTP/1.1 401 Unauthorized
20:52:06.005643 IP 10.10.2.1.48884 > 10.10.2.2.http: Flags [F.], seq 74, ack 1, win 229, options [nop,nop,TS val 2462755885 ecr 4243499322,nop,nop,sack 1 {419:420}], length 0
20:52:06.016410 IP 10.10.2.2.http > 10.10.2.1.48884: Flags [.], ack 75, win 453, options [nop,nop,TS val 4243528173 ecr 2462755885], length 0
20:52:12.342754 IP truncated-ip - 326 bytes missing! 10.10.2.2.http > 10.10.2.1.48884: Flags [P.], seq 1:419, ack 75, win 453, options [nop,nop,TS val 4243534487 ecr 2462755885], length 418: HTTP: HTTP/1.1 401 Unauthorized

I opened up port 6969 with netcat:

while true; do
    nc -l 6969
done

on one of the Pis and on the other I started sending characters to see where the cutoff was:

for i in `seq 20 120`; do
    python -c "print 'A' * $i" | nc -q0 10.10.2.2 6969;
    sleep 1;
done

When I used UDP to send data back and forth I noticed that all data was sent up to 116 bytes. Thereafter the packets were dropped. With TCP the cutoff was 92 bytes (it makes sense why it would be less than UDP). I couldn't see anything that's preventing the packets from being sent, especially since I see the tcpdump log on the receiving end, but I'm pretty sure the warning that 326 bytes missing! is what's to blame.

Is there a way to patch this issue?

Attempting MQTT connection...failed, rc=-2 try again in 5 seconds

Hi, I realise I'm clutching at straws here but I'm starting to run out of options. Before the recent releases in July and August I set up a link from an Arduino Nano to mqtt2zigbee running on a Pi 4 with Raspbian desktop. I recently tried to port this over to an Arduino Nano and a Pi 3 A+ on Raspbian light. I used the most recent mqtt2zigbee, mosquitto and couldn't get things working with the ncurses, gatewayNode or ncursesInt to start with. After updating the pubsubclient and RF24 etc libraries for the Arduino, I can get intermittent connections but I get long periods of Attempting MQTT connection...failed, rc=-2 try again in 5 seconds.

I have tried going back to the original setup with the Pi 4 and the Nano but the Nano is now working from the latest RF24 etc version so it isn't exactly the same (same intermittent connection dropping and failure to reconnect). I have interrupt errors on the ncursesInt example for every attempted packet and this is using the same hardware connections that were working when testing my last issue (ie no changes). I did go through the example and explicitly made sure interrupts were turned back on with gw.interrupts(1) rather than gw.interrupts() - like I said, running out of things to check/tweak.

I notice that the installer now gives options for Pi SPI drivers which weren't there before. I selected SPIdev for compatibility on the A+ but I don't know if that's what would have been installed by default on the pre-Jul update version on the Pi 4.

I acknowledge that this could be a problem with mosquitto or pubsubclient but given the raft of recent changes to RF24, I thought it would at least be worth asking if there are any thoughts on this. Even confirming that the process followed in the guide (https://tmrh20.blogspot.com/2019/05/automationiot-with-nrf24l01-and-mqtt.html) still results in reliable performance would be really helpful. I set up mosquitto local service following https://randomnerdtutorials.com/how-to-install-mosquitto-broker-on-raspberry-pi/ .

Not sure what else to include/mention at this stage because it is such a tricky issue to localise. Please shout for more detail that might be helpful.

Two Raspberry Pis as a bridge

Hi,

Firstly, thank you very much for your amazing libraries!

I was wondering how I would go about using two gateways together for the purposes of creating a long distance internet link between two raspberry pi's?

So far, I have installed every library and managed to compile the ncurses example, however I am unsure what I need to change in order for the two gateways to have different addresses and connect to one another. The ncurses example works on each Pi, but no connection is shown, and I cannot ping the other Pi through the tun adapter.

Thanks!

'rfNoInterrupts' was not declared in this scope

Can not compile.

RF24Gateway$ make
g++ -Wall -fPIC -std=c++0x -Ofast -mfpu=vfp -mfloat-abi=hard -march=armv7-a -mtune=arm1176jzf-s  -c RF24Gateway.cpp
RF24Gateway.cpp: In member function 'void RF24Gateway::poll(uint32_t)':
RF24Gateway.cpp:262:20: error: 'rfNoInterrupts' was not declared in this scope
     rfNoInterrupts();
                    ^
RF24Gateway.cpp:264:18: error: 'rfInterrupts' was not declared in this scope
     rfInterrupts();
                  ^
RF24Gateway.cpp: In member function 'void RF24Gateway::handleRX(uint32_t)':
RF24Gateway.cpp:441:28: error: 'rfNoInterrupts' was not declared in this scope
             rfNoInterrupts();
                            ^
RF24Gateway.cpp:450:26: error: 'rfInterrupts' was not declared in this scope
             rfInterrupts();
                          ^
RF24Gateway.cpp: In member function 'void RF24Gateway::handleTX()':
RF24Gateway.cpp:466:24: error: 'rfInterrupts' was not declared in this scope
           rfInterrupts();
                        ^
RF24Gateway.cpp:472:26: error: 'rfInterrupts' was not declared in this scope
             rfInterrupts();
                          ^
Makefile:49: recipe for target 'RF24Gateway.o' failed
make: *** [RF24Gateway.o] Error 1

Maybe a file is missing?

Clarification about fragmentation?

Thanks for the tremendous work on these libraries -- it's been a lot of fun and very informative getting things plugged together by working my way through the OSI stack and seeing how the libraries correspond. I've hit an odd(?) block at the Gateway level --and holding open the possibility that it could be something to do with radio interference / or my hardware/serial/raspian config-- I hope you (or anyone else) can clear something up that I think might have to do with the setting on RPi in RF24Network/RF24Network_Config.h for #define MAIN_BUFFER_SIZE.

Following the YouTube walkthrough I've set this to 1514 + 10, but the comment above says the result of MAIN_BUFFER_SIZE - 10 must be divisible by 24. I've been trying to figure out where the exception is, or what's going on to transform the result, and am coming up short.

On the Arduino side, in RF24Ethernet/uip_conf.h I've set #define UIP_CONF_LLH_LEN 0.

The result is this:
/examples/ncurses/RF24Gateway_ncurses is fully functional using SimpleClient_Mesh, and mostly functional with InteractiveServer_Mesh -- InteractiveServer is routable and responds to pings, but bashClient and curl calls return binary. Using RF24Gateway_ncursesInt, neither SimpleClient nor InteractiveServer are able to join the mesh, and the RF24Network Info Interrupt Errors counter increments steadily.

Anyway, thanks again for your time -- obviously I'm happy to post any other settings or output, if the issue doesn't jump out right away, but I'm just not sure where else to look or what would be relevant.

deploy documentation using Github Pages

This issue is part of an effort to start hosting nRF24 org repos' docs on github per individual repo instead of uploading all RF24* lib's docs to tmrh20.github.io.

I've created a github workflow that builds the docs on every commit. This same workflow will upload the generated HTML files to the "gh-pages" branch upon publishing a new release. Notice I've already taken the liberty to create the "gh-pages" branch for this repo.

1. For this workflow to work properly, this repo's settings needs to have the "gh-pages" branch set to the Github Pages Source option:
   
   After enabling this option, I expect the first deployment to Github Pages to render an error message.

2. Additionally, it would less visually noisy if the "packages" & "environments" sections are hidden in the repo's sidebar settings:
   

When these stipulations have been met in the repo settings I will submit a PR