I'm working with a MK60DN512 project which uses RTCS Ethernet. Everything works great when using DHCP, and works great when using a static IP address with a netmask of 255.255.255.0. As soon as I change the 4th byte of the netmask to anything other than zero, I get a network bind error when it attempts to bind (error 4 is returned). Has anyone else experienced this, and if so, what can be done to overcome it?
Forgot to mention I am using MQX version 3.8 on this particular project.
Thanks in advance!
Solved! Go to Solution.
To continue, if your base IP address was 192.168.1.xxx and the netmask was 255.255.255.252, the allowed IP addresses would be 192.168.1.0, 192.168.1.1, 192.168.1.2, and 192.168.1.3 .
To continue, if your base IP address was 192.168.1.xxx and the netmask was 255.255.255.252, the allowed IP addresses would be 192.168.1.0, 192.168.1.1, 192.168.1.2, and 192.168.1.3 .
I was a little backwards in my thinking, I was just stating the netmask that our customer has requested. So apparently that would be an illegal netmask... I'll have to point this out to them. Thanks a bunch for your help!
To limit the address range to four devices, the netmask would be 255.255.255.252 (0xFFFFFFFC). Two devices would be 255.255.255.254 (0xFFFFFFFE).
I have never tried reducing the scope below the default 255.255.255.0 . We have increased the allowed address range, such 255.255.252.0 to allow up to 0x3FF devices. I suggest you do not try to narrow the netmask below 255.255.255.0 . Remember how a netmask works. It is the dotted decimal representation of a hex IP address. To have an IP address range of 64 units, the netmask would be 255.255.255.192, where 192 is 0xC0.
Well the issue is our customers are using Ethernet/IP and Modbus/TCP to talk to PLC's and they really want to cut down on the network traffic to the device, hence their desired netmask of 255.255.255.2 to filter out just about everything but the PLC and our device in order to minimize traffic. Unfortunately, RTCS doesn't seem to like this. If this were anything other than a critical process control situation, I'd be okay with leaving the netmask as 255.255.255.0, but our customer is concerned that this may affect timing of the commands sent from the PLC to the device, and responses from the device to the PLC. I think they may be okay using a managed switch to filter this traffic upstream, but I would still like to know why RTCS doesn't like the 4th byte of the netmask to be something other than zero.
I can give static ip: 192.168.0.1 mask 255.255.255.192
By the way, RFC 1519 states the mask must be left contiguous.
There is the test on address and netmask values in the IPIF_bind() function, so the values you input should pass this test:
/*
** Make sure the netmask is valid. We use the fact that
** (x & x+1) == 0 <=> x = 2^n-1.
*/
if (~netmask & (~netmask + 1)) {
RTCSCMD_complete(parms, RTCSERR_IP_BIND_MASK);
return;
} /* Endif */
/*
** Make sure the address is valid.
*/
if (((address & ~netmask) == 0)
|| ((address & ~netmask) == ~netmask)) {
RTCSCMD_complete(parms, RTCSERR_IP_BIND_ADDR);
return;
} /* Endif */