- Pass inbound caller ID to SIP phone
- SBD Relay Updates for 9523 Firmware version TM12003
- Iridium 9523MW updates
- Resolve SMS port sharing lockup
- Resolve SMS queue bug
- Gold Release of SBD services interface
SBD Service and Processor Release Note
- Startup - After initial boot up, the SBD processor will wait for 60 seconds before commencing the first registration attempt
- SBD Mailbox Check Timer - Every X minutes after no successful SBD transactions, the unit will initiate a mailbox check. Regular mailbox checks are important to catch missed SBD ring alerts, or loss of signal, to pull pending messages from the gateway. If there is successfully transmitted or received SBD packets, the next mailbox check will be reset to X minutes.
- Processor Logic, SBD tunnel disabled: Incoming SBD packets will be duplicated/transmitted simultaneously via 1) UDP packet and user defined port number to the local network broadcast interface 2) TCP packet to any clients connected to the MCG-101 on the user defined TCP port number and 3) optional RS232 port if the RS232 service is enabled
- Processor Logic, SBD tunnel enabled: Incoming SBD packets will not be transmitted via UDP, TCP, or RS232, even if enabled, and will only be written to the tunnel interface at Ethernet Layer 3 detailed below:
IPv4 Protocol Tunnel To SBD Service
This service will digest any IP packets that reach the MCG-101, whether they are set to the destination IP address of the MCG-101, or whether they were routed to the MCG-101 as a gateway, that match your selected protocol number. A generic list of protocols is here https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers. The typical use case is to use the MCG-101 as a transparent IP layer service to route IP packets between two remote networks transparently. In this use case, you would set the MCG-101 as the gateway to your local network, and then send a packet to a non-local network address, which triggers your local system to forward the packet to the gateway, IE MCG-101, for delivery. The packet is consumed by the MCG-101 at network layer 3, and transparently transmitted via SBD including IP source, destination, protocol number, and payload, IE layer 3.
SBD To IPv4 Protocol Tunnel Service
This service will generate IP packets that reach the MCG-101 that contain a valid packet starting at Layer 3. Typically these packets are generated by another MCG-101 utilizing the IPv4 Protocol Tunnel to SBD Service. The incoming SBD packet will be routed to a tunnel interface that provide the Layer 2 MAC address lookups via arp to complete the packet, and then transmit it via the LAN bridge, which includes WiFi and Ethernet interfaces by default.
UDP To SBD Service
The UDP to SBD service will consume any payload data that is received on the defined UDP port, and transmit the data payload via SBD
SBD To UDP Service
The SBD to UDP service will broadcast on the defined UDP port any received SBD payload
TCP To SBD Service
The TCP to SBD service will consume any payload data that is received on the defined TCP port, and transmit the data payload via SBD
SBD To TCP Service
The SBD to TCP service will write SBD payload data to any host connected to the MCG-101 on the defined TCP port
RS232 To SBD Service
The RS232 to SBD service will packetize data based on the user defined End Of Packet delimiter, and escaped using the optional user defined Escape delimiter. For binary applications, you must use the Escape delimiter.
SBD To RS232 Service
The SBD to RS232 service will write SBD payload data to the RS232 port at the user defined baud rate, using the optional user defined Escape delimiter, and the user defined End Of Packet delimiter. For binary applications, you must use the Escape delimiter.
SNMP Service, configurable to run on UDP or TCP. The SNMP service listens to a variety of GPS and Iridium broadcast messages, and some events that require polling. The behavior, source, and possible delay of each is noted below:
|Real Time Clock||18.104.22.168.4.1.38040.11.6.0||GPS||Instantaneous||Report time acquired from GPS chipset after GPS signal has been acquired. Does require a GPS antenna to be connected|
|Link Quality||22.214.171.124.4.1.38040.11.15.0||Iridium DPL Port||Instantaneous||Report last known signal level broadcasted from the Iridium DPL port. Does not force a query, but instead reports the signal level based on what would be displayed on an Iridium handset.|
|Lock/Unlock Status||126.96.36.199.4.1.38040.11.13.0||Iridium Data Port||Delayed, must query Iridium Data port||Query the CULK status using an AT command that shares the single port between dial up data, SMS, and SBD. The Iridium Data port is first come first serve and this command can be denied if already busy|
|Error Status||188.8.131.52.4.1.38040.11.16.0||Iridium Data Port||Delayed, must query Iridium Data port||Query the CMEE status using an AT command that shares the single port between dial up data, SMS, and SBD. The Iridium Data port is first come first serve and this command can be denied if already busy|
|Enable EMCON||184.108.40.206.4.1.38040.11.7.0||Iridium Data Port||Delayed, must query Iridium Data port||Query and set the EMCON status using an AT command that shares the single port between dial up data, SMS, and SBD. The Iridium Data port is first come first serve and this command can be denied if already busy|
- Update SBD tunnel writer to retry read after synchronized file write holds lock
- Update SBD processor to back off mailbox checks based on success/failure of normal MT/MO messages
- Added SBD queue clean on boot option: Remove queued SBD messages from in/outbox on startup
- Added syslog for SBD tunnel logging
- Aurora/MCG-101 CD now terminates pppd on loss of satellite signal
- Firewall now forces the default policy for PPP and WAN interfaces to be REJECT regardless of what the user sets in the firewall user interface. Users must explicitly enable traffic for these interfaces.
- Correct checksum calculation for large SBD packets
- New SBD Tunnel option to route any protocol at layer 3 over SBD, which includes the origin/destination IP, protocol, and packet data
- New core system for MCG108 data port
- Update to monitor Iridium link via LCP
- Linux tty driver buffering monitoring
- Updated firmware on MCG108 to resolve hardware flow control
- VSP updates to set high and low water marks
- Add hardware flow control timer on IP serial port for MCG108
- Updated firmware on MCG108
- Set smaller txqueuelen on PPP startup
- Add Firewall defaults for SNMP Server
- Add TCP support for SNMP server
- Implement SBD Repeater Settings
- Implement SNMP Iridium Status
- Resolve SMS transmission confirmation
- Resolve AT passthru functionality
- Resolve SMS queue display
Loading new firmware
Connect via WiFi or Ethernet and browse to http://192.168.10.1 and enter username superadmin, password webxaccess.
Go to System > Firmware > uncheck the “keep settings” field.
Select firmware saved on your computer and click “Update”
Configure PPP to auto start with any Ethernet traffic
If you want PPPD to startup on boot then you need to enable “Enable on router startup”. Otherwise the system will wait for either an XGate connection or for someone to push the connect button (ppp->status) before it will start up.
If you want PPPD to monitor traffic and connect on demand then enable the “on demand” feature. PPP will connect as soon as the unit boots, and then it will disconnect if there is no traffic for 60 seconds (configurable). It will reconnect when it sees traffic.
The firewall on the aurora is setup to block all traffic to the internet except for Xgate and Xweb, so it must be disabled if you want unrestricted access to the internet. To do this go to network->firewall->traffic rules and put check marks next to the first 6 rules (they are unchecked by default). This will enable all traffic, DNS, HTTP, HTTPS, and FTP traffic.
Reboot or power cycle the MCG-101.
Under services->ppp>status click the “connect” button to bring up PPP. This will bring up the PPP connection immediately. Note that the connection will be brought down in the idle time specified under services->ppp->settings->ppp