Skip to main content

Mini IP Interface

The Mini supports IP via the Iridium Certus 9770 module (WAN) allowing LAN device IP data to be be forwarded via the WAN interface.

The default LAN configuration on the Mini is 192.168.250.0/24 with the Mini having the static IPv4 of 192.168.250.1. The Mini does have a DHCP server on the LAN but disabled by default, therefore all LAN devices need to be configured with a static IPv4 of 192.168.250.2 to 192.168.250.99 and netmask of 255.255.255.0 the gateway should be configured to 192.168.250.1

Do not check signal strength before sending

The Iridium Certus 9704 and 9770 transceivers in RockBLOCK and RockREMOTE products are configured in firmware to transmit only when signal strength is at least 1 bar. Do not duplicate this check in your application. Do not delay, block or skip a transmission based on a signal reading; send the data and the transceiver will transmit it when conditions allow.

Signal readings remain useful for diagnostics, installation checks and monitoring.

LAN​

The RockREMOTE Mini can have a number of Local Devices connected to its Local Area Network (LAN). For example:

  • A single device plugged into the wired ethernet port
  • Multiple devices plugged into a network switch, which is plugged into the wired ethernet port
info

Be careful not to choose a subnet that overlaps with the WAN interfaces. Some subnets will be rejected because they are used internally. For example the Iridium WAN interfaces uses 192.168.2.0/24 internally, which means the LAN IP range of 192.168.2.0/24 can not bet used.

danger

The RockREMOTE Mini has outbound firewall rules open by default. Connecting it to a Laptop with a default gateway will result in IP data use.

Further details and instructions for configuration of the RockREMOTE Mini's IP address and DHCP server (etc) can be found here: User configuration

Confirm the IP connection with ICMP Pings​

  1. Connect the Certus antenna to the Mini.
  2. Power up the Mini.
  3. Configure a LAN device IPv4 configuration to the settings below. Preferable the LAN device should be a test PC so it has access to IP utilities like ping.
    • IPv4 Address: 192.168.250.2 to 192.168.250.99
    • IPv4 Netmask: 255.255.255.0
    • IPv4 Gateway: 192.168.250.1
  4. If possible isolate traffic on the LAN device to prevent unwanted IP forwarding.
  5. To confirm there is a LAN connection, ping Mini address from the LAN device, all pings should get a response. If this does not happen follow the steps above again, verifying the IPv4 configuration. An example command response is below.
root@test:~ $ ping 192.168.250.1
PING 192.168.250.1 (192.168.250.1) 56(84) bytes of data.
64 bytes from 192.168.250.1: icmp_seq=1 ttl=64 time=0.593 ms
64 bytes from 192.168.250.1: icmp_seq=2 ttl=64 time=0.526 ms
64 bytes from 192.168.250.1: icmp_seq=3 ttl=64 time=0.521 ms
64 bytes from 192.168.250.1: icmp_seq=4 ttl=64 time=0.514 ms

--- 192.168.250.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3050ms
rtt min/avg/max/mdev = 0.514/0.538/0.593/0.031 ms
  1. To confirm the Mini's WAN connection you could open an internet browser and connect to http://192.168.250.1. The Mini Home page should load indicating its current state. To confirm the LAN is up by checking the PPP Status. This should report UP if connected. If DOWN is reported confirm a antenna is connected and Mini is provisioned, if this is the case the Signal Quality will not be 0,0 and Provisioning will report Messaging,Packet Data

RockREMOTE Mini Home page

  1. If PPP Status is reported as UP, the Mini is ready for ICMP pings over the internet. Run a ping to a known server which has a static IPv4. Usually a ping to 8.8.8.8 (dns.google.com) is ideal. You may observe a few losses to begin-with as it takes some time Iridium Certus to ramp up the radios for IP transmission, once the pings start getting responses the ping response time will decrease down to about 400 - 600 ms. An example of of this is below.
root@test:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=8630 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=112 time=7699 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=112 time=6855 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=112 time=5921 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=112 time=4987 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=112 time=4053 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=112 time=3119 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=112 time=2185 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=112 time=1251 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=112 time=612 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=112 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=112 time=591 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=112 time=491 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=112 time=480 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=112 time=559 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=112 time=459 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=112 time=448 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=112 time=437 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=112 time=606 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=112 time=595 ms

--- 8.8.8.8 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19194ms
rtt min/avg/max/mdev = 437.244/2529.122/8630.026/2724.318 ms, pipe 9

tip

If your LAN device has more than one network interfaces, on Windows you can use ping -S 192.168.250.2 8.8.8.8 and on Linux you can use ping -I eth1 8.8.8.8. Where 192.168.250.2 and eth1 are the IP or interface configured on the RockREMOTE Mini's network subnet, and 8.8.8.8 is the Destination IP.

Testing TCP and UDP Connections with Netcat​

Prerequisites​

  • Perform the ICMP ping test as explained above to verify the Iridium Certus connection is up.
  • Ensure netcat (or nc) is installed on both the client (test PC) and the server.
    • For Linux/Mac, install via package manager if not already installed.
      • Ubuntu/Debian: sudo apt-get install netcat
      • CentOS/RHEL: sudo yum install nc
      • Mac: brew install netcat
    • For Windows, download netcat nmap and add it to the system PATH.

Testing TCP Connection​

On the Server

  • Open a terminal on the server.
  • Start a netcat listener on the desired port (e.g., port 12345):
nc -vl -p 12345

On the Client (Test PC)

  • Open a terminal or command prompt.
  • Connect to the server’s IP address on the specified port:
nc -v <server-ip> 12345
  • Type a message and press Enter. If the connection is successful, you should see the message appear on the server’s terminal.

Testing UDP Connection​

On the Server

  • Open a terminal on the server.
  • Start a netcat listener on the desired port (e.g., port 12345):
nc -vul -p 12345

On the Client (Test PC)

  • Open a terminal or command prompt.
  • Connect to the server’s IP address on the specified port:
nc -vu <server-ip> 12345
  • Type a message and press Enter. If the connection is successful, you should see the message appear on the server’s terminal.

Troubleshooting​

  • Ensure Provisioning is Messaging, Packet Data.
  • Ensure PPP Status is UP.
  • Ensure the server’s firewall is configured to allow traffic on the specified port.
  • Ensure the client's firewall is configured to allow outbound traffic.
note

The RockREMOTE Mini can act both as a client and as a server.

Please look at the User Configuration file

  • Verify the server’s IP address and port number.
  • Ensure there are no network issues by performing the ICMP ping test first.

Latency and cold starts​

Latency is defined as the time taken for a transmission to be sent from the Iridium transceiver to the end destination.

  • IMT messages: on Ground Control airtime, the end destination is Cloudloop. From there, messages can be API pulled or pushed/forwarded to your own systems.
  • IP data: Latency for IP data is measured per packet between the transceiver and the IP destination.

End-to-end latency of an Iridium transmission, whether an IMT message or IP data, consists of three stages:

  1. Session ramp-up: approximately 5 seconds to establish a session with the satellite network.
  2. Transmission: the time taken to send the data, which increases with the amount of data.
  3. Gateway to cloud: the time taken for the data to travel from the Iridium gateway to its destination.
Session ramp-up in practice

Approximately 5 seconds is the average session ramp-up time quoted by Iridium. In practice it depends heavily on signal strength and the antenna's view of the sky. Ground Control regularly observes ramp-up times of 5 to 12 seconds, and occasionally longer.

Session ramp-up applies only to the first transmission in a session. Further transmissions while the session is active are sent without this delay.

If no data is transmitted for approximately 15 seconds or longer, the satellite link closes. The next transmission then requires a new session (a cold start) and incurs the full session ramp-up time.

On Iridium Certus 9770 products, an active IP data session also reduces IMT delivery time. Where ring alerts are used, MT delivery takes approximately 2 seconds longer.

Latency in an active session and after a cold startThree bars of equal length, each divided into stages. Single transmission: a short session ramp-up, a long transmission, then a short gateway-to-cloud stage. Consecutive transmissions in an active session: one session ramp-up, then transmissions 1, 2 and 3 in sequence, then gateway to cloud; transmissions 2 and 3 are sent without session ramp-up. Cold start: session ramp-up, transmission 1 and gateway to cloud, then a period of approximately 15 seconds or more without transmission during which the link closes, followed by a new session ramp-up, transmission 2 and gateway to cloud.Session ramp-up (typically 5–12 s)TransmissionGateway to cloudLink closedSingle transmissionRamp-upTransmissionConsecutive transmissions in an active sessionRamp-upTransmission 1Transmission 2Transmission 3Transmissions 2 and 3 are sent without session ramp-upCold start after approximately 15 seconds without transmissionRamp-upTransmission 1Link closedRamp-upTransmission 2Transmission 2 requires a new session ramp-up
Source: Iridium partner proprietary document, from which valid information has been taken to be shared with the public.

SMTP​

Resource moved under Operation, click here to get redirected

Last updated on