Enabling IP Pass-Through on a Cradle Point modem

This article refers to Cradle Point series 3 routers and modems running firmware version 3.6.0. You can download the latest firmware here.

In the factory default mode, Cradle Point modems are configured to issue DHCP on a private LAN of 192.168.0 /24 with a gateway of 192.168.0.1. The WAN access is configured to use an Ethernet port or an active modem connection and all traffic initiated from the LAN is allowed. If inbound access to a device with multiple clients on the LAN is desired, setup of port forwarding rules is required. In cases when there is only one client device on the LAN or the Cradle Point is used only as a gateway, IP Pass-Through mode can be used.

IP Pass-Through mode, simply stated, disables the Routing and LAN functions and provides the WAN address directly to one attached network client.

By default, the modem will display the First Time Setup Wizard the first time you connect to the modem. Complete the wizard before proceeding.

Upon completion of the First Time Setup Wizard, return to the Status / Dashboard by selecting the "cradlepoint" logo on the upper left side of the page. Note that the Primary LAN router mode displays "NAT (Network Address Translation)"

To configure IP Pass-Through mode select "IP Passthrough Setup" under "Getting Started".

The "IP Passthrough Setup Wizard" will display select "Next"

Select "Enable IP Passthrough".

A notification will appear, select "OK", reset your LAN network connection client as instructed.

To confirm the configuration changes, log back into the modem and navigate to the "Status / Dashboard" page. The Primary LAN router mode should display "IP Passthrough". The WAN IP address will now be passed directly to one attached network client.

Configuring RTS/CTS on Moxa AWK Series Radios to solve Hidden Node Problem

When setting up wireless networks, there are many factors that can contribute to connection issues such as line of sight, radio interference, network range, firmware upgrades, etc.  Although the ones listed here are fairly generic, there are other wireless issues not as apparent which require much more in-depth planning and configuration.  In order to troubleshoot IEEE 802.11 wireless networks, it helps to have a general understanding of the rules and standards of 802.11 wireless communication. First reminder, wireless networks operate using half-duplex communication. This simply means that a device cannot transmit data to an Access Point (AP) and receive data at the same time. While this was the standard for a long time in wired ethernet networks, the industry has since supplanted this technology with full duplex capabilities which allows simultaneous transmission and reception of data.  Whenever half duplex is in use with wireless networks, a technology known as Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) is always in play. This technology is in use today with wireless networks as a means to prevent data transmission collisions which can degrade wireless performance.

With that basic principle in mind, let's get into a fairly complex issue we came across recently with one of our applications and discuss the solution. The issue involved the use of a wireless network using Moxa AWK-4131 (802.11n) Access Points (APs) and AWK-3131 client radios for an IP video system. This surveillance application was used on a bus system for the purposes of monitoring activity on various buses throughout the city. Moxa client radios were installed on each bus and connected to an IP camera/DVR system. Once the buses returned within a certain range of the access points located throughout the bus yard, data was instantaneously transmitted to the access points and uploaded to a video server. With the appropriate wireless surveys, planning, and device configurations this seems like a straightforward application. However, as with many wireless implementations, new challenges and obstacles can arise.

With this particular implementation, the customer discovered from the Moxa logs that the bus radios were connnecting and disconnecting from one AP to the next continuously.  What Moxa engineers diagnosed was a behavior known as the "hidden node problem."  A hidden node problem occurs when a node is visible from a wireless AP, but not from other nodes communicating with the same AP (see graphic below).  The node at the far edge of the access point's range can see the access point, but it is unlikely that the same node can see a node on the opposite end of the access point's range. These nodes are known as hidden. The problem occurs when nodes start to send packets simultaneously to the access point. Since nodes cannot properly sense the carrier, the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) does not work and as a result, collisions occur scrambling the data.

In order to resolve the issue, IEEE 802.11 uses a function called RTS/CTS acknowledgment and handshake packets to partly overcome the hidden node problem.  A node wishing to send data initiates the process by sending a Request to Send frame (RTS). The destination node replies with a Clear To Send frame (CTS). Any other node receiving the RTS or CTS frame should refrain from sending data for a given time (solving the hidden node problem). On the Moxa radios, we effectively enable the RTS/CTS function (reference screenshot below) by lowering the RTS/CTS threshold to 256 (smallest packet size). After RTS/CTS was enabled, we saw both connections stay stable and share the resource reliably. 

Links of Interest

• Moxa Ethernet Radios

Remote Access Simplified with eWON and Talk2M

So you're an OEM, System Integrator, or End-User and you'd like to remotely access your PLC for troubleshooting? You purchase a typical industrial VPN router, throw it into your control cabinet, connect the WAN port into the business network for internet access, but then what? Turns out your incoming VPN request and session is dropped by the facility's IT firewall and IT must modify the configuration to allow the VPN. This well-known hurdle has stunted remote access objectives for many years. The hurdle is quite simply most remote access solutions involve traffic that goes the "wrong way" when you consider that IT firewalls appropriately DROP inbound traffic initiated from the "untrusted" outside.

So what if we change the picture? Below, the industrial VPN router initiates an outbound connection (utilizing TCP Port 443 typically used for HTTPS) to the hosted service called Talk2M. Next, the remote user establishes a connection to the same Talk2M service, selects a router to connect to and thereby establishes a bi-directional tunnel to the PLC. The key? While IT firewalls drop inbound traffic initiated from the "untrusted" outside, they typically ALLOW outbound HTTPS and other traffic initiated from the "trusted" inside. Fortunately, the eWON + Talk2M solution requires nothing more!

Below is a more complete picture of the overall solution provided with eWON industrial VPN routers and the hosted Talk2M service. The remote user can communicate through the eWON to serial or Ethernet PLCs, HMIs, etc.

 

In the following video, watch a remote user connecting to an Allen Bradley PLC with RSLogix over the Talk2M VPN connection.

Finally, a remote access solution leveraging the existing high-speed internet connection at the facility without requiring modifications by the IT department! Also, for cases where no hardwired Internet connection is available, there are eWON models with built-in GSM cellular modems. eWON has changed the game with this very unique solution. 

In future posts I will demonstrate how easy it is to get this solution up and running in minutes. Having setup many of the other solutions dozens of times over the last several years, I can easily attest eWON's configuration for remote access is simple, quick, and can be completed with limited networking expertise. Nevertheless if you prefer assistance setting up your first unit, we can certainly walk you through it.

I'd be remiss not to at least mention eWON can also perform some advanced SCADA functions including data logging (drivers for Rockwell/Allen-Bradley, Schneider/Modicon, Omron, Hitachi, Mitsubishi, SNMP), Web HMI, and data push via SMS, E-mail, FTP, web services etc. but I'll save further detail on these options for additional future posts.

Related Posts

• eWON Config Post 1: Update eBuddy, Set eWON IP Address, and Upgrade eWON Firmware 
• eWON Config Post 2a: Configure eWON Internet Access (Hardwired)
• eWON Config Post 2b: Configure eWON Internet Access (Cellular) 
• eWON Config Post 3: Configure eWON Connection to Talk2M
• eWON Config Post 4: Connect to eWON and Remote Devices using eCatcher

Links of Interest

• eWON Industrial VPN Routers

Power over Ethernet (PoE) Mode A/Endspan vs. Mode B/Midspan

Ever found yourself in the situation where you have a Power over Ethernet (PoE) Powered Device (PD) device and Power Sourcing Equipment (PSE) but the two don't seem to be working together? Well you may have fallen down the not-so-well-documented rabbit hole of Mode A vs. Mode B.

Taking a closer look 802.3af PoE, you'll find two different sub-standards of 802.3af associated with 10/100 TX Ethernet, namely Mode A and Mode B. The main difference is best illustrated with the following diagrams.

The diagram above shows a PSE supplying power on top of the 10/100 TX data on pins 1,2,3,and 6. PSE providing "phantom" power on the data pairs is known as Mode A, or Endspan.

This diagram above shows a PSE supplying power on pins 4,5, 7, and 8, the "spare" pairs in an Ethernet cable running 10/100 TX. PSE providing power on the spare pairs is known as Mode B, or Midspan. Most "injector" devices (as opposed to full switches) are Mode B.

And here come the "Gotchas." While PDs must support BOTH Mode A and Mode B to be compliant with the 802.3af standard, there is no such requirement for PSEs. There are a few different ways this can lead to mistakes.

1) You might assume your device is 802.3af compliant because it is listed as PoE-capable, but this is not always the case. A recent customer had a PoE-capable Ethernet/IP Rotary Shaft Encoder, but closer datasheet inspection revealed it was not 802.3af compliant. As it turned out, this was only a 4-wire device and therefore incompatible with the customer's existing Mode B PSE. We supplied a Mode A PSE and resolved the issue.

2) In addition to no requirement for PSEs to perform BOTH Mode A and Mode B, many vendors' documentation doesn't state which mode their device utilizes.This makes it challenging to locate the proper equipment for scenarios like the one above.

3) You must confirm specific model numbers and operation. We came across one vendor's PoE switch whose generic datasheet listed Mode A and Mode B and offered two part numbers ending in A and B with PoE Mode as the only difference between the two. Only upon close inspection did we notice the A part number utilized Mode B and the B part number utilized Mode A. Crazy enough?

As we receive confirmation from our vendors, we will be maintaining this list of PSE equipment we offer and the associated operational mode.

Mode A/Endspan
Moxa Switches

Mode B/Midspan
Esteem Injectors
Mobotix Injectors
Moxa Injectors

Links of Interest

• PoE Industrial Switches
• Esteem AA175 Power Supply 
• MOBOTIX MX-NPA-PoE-SET-INT Power Supply

How to provision a Verizon Sierra Wireless Airlink Raven X, XT and XE modem

Sierra Wireless Airlink modems and gateways have a permanent

identification sticker affixed to the device. In addition to serial number and other information, the Sierra Wireless model name and number is listed. The last character in the model number denotes the carrier the device will work with. In the case below "V" is Verizon.

The factory default settings of Verizon Sierra Wireless Airlink Raven X, XT and XE modem are set to automatically register and provision themselves on the Verizon network. When the modem is powered on with an antenna connected, the modem will send the ESN (Electronic Serial Number) of the device to the Verizon Network. If the modem is located in a Verizon primary coverage area and the correct ESN of the device was used to create an account with Verizon, the modem will register and connect to the network.

If the modem has previously been active on a Verizon account and that account is now inactive or changed, the unit may need to be re-initialized to register on the network. This requires returning the modem to factory default settings. It is recommend to save any custom changes you have made to the unit to a template file prior to manual initialization.


Manual Initialization
To factory default and re-initialize the modem on the Verizon network, hold in the reset button on the front of the unit and hold until the lights chase back and forth. Reset the modem power connection. If the modem ESN is associated with an active Verizon account, it will connect to the network.

  

Software Initialization
To software re-initialize the modem on the Verizon network, connect to the modem using Ace Manger Web. Navigate to the WAN/Cellular tab and open the Re-Activation section. Select the Re-Activation button to start the process.

The modem will reset and if the modem ESN is associated with an active Verizon account, it will connect to the network.