Subnet mask problem

Subnet masking is a Ethernet network Host local/remote identifier when presented to the TCP/IP protocol; it establishes the Host's Local and Network address.

A Subnet mask is a 32-bit number that masks an IP address, and divides the IP address into network address and host address. Subnet Mask is made by setting network bits to all "1"s and setting host bits to all "0"s. It is used mainly for restricting the number of Hosts on any given network segment (subnet).

The most commonly used mask is 255.255.255.0 (11111111 11111111 11111111 00000000) which limits the number of Hosts on the respective subnet to 254.

The OP mask, 255,0,0,0 (11111111 00000000 00000000 00000000) expands the Host limit count to 16,777,216.

thanks!
 
This issue is not resolved. I do have some more information though...

I helped a colleague add a route using the same command that I used, so he could use his WiFi while connecting to his PLC over ethernet. Everything worked fine for a few days, and now he has the same issue with the subnet mask that I have. Even though our PLC is set to IP 10.10.10.10 mask 255.255.255.0...we cannot connect to it when our laptop is set to 10.10.10.250 mask 255.255.255.0. To be able to connect, we have to set our subnet mask on our ethernet adapter to 255.255.254.0 or lower. Can anyone explain this?
 
This is not necessarily a misconfiguration; use of the metric for route entry selection is a secondary factor, the primary factor being the most specific route entry will be selected (i.e. most number of 1 bits in the network mask). Only if there are multiple entries will metric be consulted.

For Microsoft:

https://technet.microsoft.com/en-us/library/cc754012(v=ws.10).aspx
Thanks for the info. I will have to look into exactly what the network settings were. The behavior described would be what I expect it to do. I know changing the metric solved the problem.
 
what happens if you delete the duplicate (albeit lower priority) route to 10.10.10.0?

route delete 10.10.10.0 MASK 255.255.255.0 172.16.25.1

or sometimes i can't get that to work so i delete all the routes

route delete 10.10.10.0

and then

route add 10.10.10.0 mask 255.255.255.0 10.10.10.115
 
what happens if you delete the duplicate (albeit lower priority) route to 10.10.10.0?

route delete 10.10.10.0 MASK 255.255.255.0 172.16.25.1

or sometimes i can't get that to work so i delete all the routes

route delete 10.10.10.0

and then

route add 10.10.10.0 mask 255.255.255.0 10.10.10.115

Hard to say at this point. I did a "route -f" command to clear my route table and things went back to normal. I wouldn't think having the same route twice would be a problem as long as they are coming from a different interface. I believe the metric would determine which route is used? I can say that I've had two 10.10.10.0 routes in there before with no problems...

One question I do have is why is there a route for 10.10.10.0 over WiFi?
 
Last edited:
It probably is Win10 after all; at least it's the last Windows; forever...:D

I have personally acquired a preference when it comes to my laptop's Ethernet connectivity and it served me well for the past fifteen years or so.

Since the on-board NIC was always bound to each site's connectivity settings all the way up to WAN and Domain levels, I have been using a USB-to-Ethernet adapter to connect to automation networks.

The adapter's Network Connection exists only when plugged in and the settings could be quickly matched to the subnet I am trying to connect to; my RSLinx EtherNet/IP drivers carry the "names" of the sites/customers and are all pointing to said adapter.

I could use it from inside VMs as a peripheral disconnected from the Host and it never let me down; it could even connect to DHCP servers in SCADA environments.

My laptop's typical network topology consists of three live and functionally independent connections:
-USB-to-Ethernet patched to an automation subnet;
-on-board NIC patched to the local LAN;
-WiFi connected to a WAN wireless access point.

Every now and then I even Bluetooth my cell phone in; ya know , for 'personal communications'...:D

Tried using my ethernet/USB dongle and I still can not be connected to WiFi if I want to connect to PLC. Windows 10 is routing the traffic over my WiFi adapter instead of the dongle. I am also still having the issue with my subnet mask needing to be 255.255.254.0 or lower to connect to 10.10.10.10 from 10.10.10.250. I don't understand it. Clearing my route table seems to fix it, but then I have the problem with my WiFi again. Can ANYONE please tell me how to fix this? Getting really tired of this....
 
It sounds like the network that you connect to over WiFi isn't physically connected to the network that your PLC is on. If that's the case and your WiFi network is 10.10.10.X and your PLC (hardwire) network is 10.10.10.X, that's a problem. Your PC thinks it can connect to the PLC over either the WiFi or the hardwire. You would want to change one of the networks to be a different network since they are different networks.

Why has changing your subnet mask worked and sometimes not worked? Because ethernet communication isn't done with IP addresses, it's done with MAC addresses.

This is a simplified explanation as to what happens when your PC tries to communication with your PLC -
1. Your PC wants to send a message to your PLC, first it checks the destination address, its own address, and the subnet mask to determine if the PLC is on the same network, in this case we'll say they are on the same network.
2. Your PC then checks its Address Resolution Protocal (ARP) Table to see if it has the MAC address for the destination IP address. In this case we'll say your PC has never talked to the PLC so it doesn't have the MAC Address of the PLC.
3. Your PC sends out an ARP Request. The ARP request is sent to all devices on the network using the network's Broadcast Address. The Broadcast Address is determined by the network, to give you an idea, if the network is 192.168.1.X its broadcast address is 192.168.1.255, if the network is 192.168.X.X then its broadcast address is 192.168.255.255.
4. Your PLC will receive the ARP Request and send and ARP response back to your PC, the ARP response says IP Address has this MAC Address.
5. Your PC receives the ARP response, adds the IP and MAC Address to its ARP Table and then sends its message to the PLC using the PLC's MAC Address.

In number 1 above, if the PLC was on a seperate network, then your PC would send the message to the device configured as the Default Gateway. Again using the Default Gateway device's MAC Address. If the PC didn't know the Default Gateway's MAC Address, it would go through the same steps to determine the Default Gateway's MAC Address. Point being, communication is occurring using MAC Addresses, not IP Addresses.

So why has the two physically separate but the same networks sometimes worked, sometimes not worked, sometimes changing the subnet mask worked sometimes not worked? I would have to guess what's been happening is that the ARP Table has been getting updated, sometimes with the MAC Address of your PLC and sometimes with the MAC Address of some other device on the WiFi network that has the same IP address as your PLC. If you hardwire to your PLC at address 10.10.10.32, the PCs ARP Table will be updated with the MAC Address of the PLC. If you connect over WiFi and there's say a printer at 10.10.10.32 then the PC will update the ARP Table with that printer's MAC Address. If you go back and hardwire to the PLC, the PC will be trying to use the MAC Address of the printer to try to communicate with the PLC. Thing to remember, ARP Tables aren't static, they get updated periodically.

If your PLC and WiFi are physically separate networks then they should also be logically separate networks as well.
 
It sounds like the network that you connect to over WiFi isn't physically connected to the network that your PLC is on. If that's the case and your WiFi network is 10.10.10.X and your PLC (hardwire) network is 10.10.10.X, that's a problem. Your PC thinks it can connect to the PLC over either the WiFi or the hardwire. You would want to change one of the networks to be a different network since they are different networks.

Why has changing your subnet mask worked and sometimes not worked? Because ethernet communication isn't done with IP addresses, it's done with MAC addresses.

This is a simplified explanation as to what happens when your PC tries to communication with your PLC -
1. Your PC wants to send a message to your PLC, first it checks the destination address, its own address, and the subnet mask to determine if the PLC is on the same network, in this case we'll say they are on the same network.
2. Your PC then checks its Address Resolution Protocal (ARP) Table to see if it has the MAC address for the destination IP address. In this case we'll say your PC has never talked to the PLC so it doesn't have the MAC Address of the PLC.
3. Your PC sends out an ARP Request. The ARP request is sent to all devices on the network using the network's Broadcast Address. The Broadcast Address is determined by the network, to give you an idea, if the network is 192.168.1.X its broadcast address is 192.168.1.255, if the network is 192.168.X.X then its broadcast address is 192.168.255.255.
4. Your PLC will receive the ARP Request and send and ARP response back to your PC, the ARP response says IP Address has this MAC Address.
5. Your PC receives the ARP response, adds the IP and MAC Address to its ARP Table and then sends its message to the PLC using the PLC's MAC Address.

In number 1 above, if the PLC was on a seperate network, then your PC would send the message to the device configured as the Default Gateway. Again using the Default Gateway device's MAC Address. If the PC didn't know the Default Gateway's MAC Address, it would go through the same steps to determine the Default Gateway's MAC Address. Point being, communication is occurring using MAC Addresses, not IP Addresses.

So why has the two physically separate but the same networks sometimes worked, sometimes not worked, sometimes changing the subnet mask worked sometimes not worked? I would have to guess what's been happening is that the ARP Table has been getting updated, sometimes with the MAC Address of your PLC and sometimes with the MAC Address of some other device on the WiFi network that has the same IP address as your PLC. If you hardwire to your PLC at address 10.10.10.32, the PCs ARP Table will be updated with the MAC Address of the PLC. If you connect over WiFi and there's say a printer at 10.10.10.32 then the PC will update the ARP Table with that printer's MAC Address. If you go back and hardwire to the PLC, the PC will be trying to use the MAC Address of the printer to try to communicate with the PLC. Thing to remember, ARP Tables aren't static, they get updated periodically.

If your PLC and WiFi are physically separate networks then they should also be logically separate networks as well.

I understand the problems with conflicting networks. However, this is not the case in this situation. You are correct, however, that the PLC is not on the WiFi network or even a network at all, it is a stand-alone device on a packaging machine(s). The WiFi network is on 172.16.24.X. There is no 10.10.10.X network on the WiFi side.
 
what happens if you delete the duplicate (albeit lower priority) route to 10.10.10.0?

route delete 10.10.10.0 MASK 255.255.255.0 172.16.25.1

or sometimes i can't get that to work so i delete all the routes

route delete 10.10.10.0

and then

route add 10.10.10.0 mask 255.255.255.0 10.10.10.115

I did delete the 10.10.10.0 routes and this allowed me to connect to PLC even when WiFi is enabled. However, after reboot of the PC, the 10.10.10.0 route was back in the table for WiFi. I'm not sure why...
 
I did delete the 10.10.10.0 routes and this allowed me to connect to PLC even when WiFi is enabled. However, after reboot of the PC, the 10.10.10.0 route was back in the table for WiFi. I'm not sure why...
The 3rd route in the active routes in your posted image (10.10.10.0, 255.255.255.0, 172.16.25.1, 172.16.25.147) is there because a connection was attempted to the 10.10.10.0 network (your PLC) when your hardwire ethernet was not available, so your PC tried to use your WiFi network and added that route. Now the metric of that route (3rd in the list) is higher than the correct route (2nd in the list), so if your hardwire ethernet is available it should be the preferred route. The thing I find interesting is in the 2nd route, it shows the gateway as being the same IP as the interface. Is the Default Gateway address of your hardwired ethernet card the same as the card's IP address? If it is try changing the Default Gateway to 10.10.10.1.
 

Similar Topics

Hi all, We have to change the subnet mask on ~400 E/IP devices to make the network bigger. Is there a quick way to do that? I can do them one at...
Replies
9
Views
2,746
Hi. Rockwell learning curve 132-1b. I was having trouble to change IP address on a EN2TR. Finally found out that I need to change the IP...
Replies
1
Views
725
I am working with a 1768-ENBT and I was able to connect to it through my laptop. My laptop IP is 192.168.1.10 subnet 255.255.255.0 and the PLC...
Replies
12
Views
1,417
I could not connect to or PLC over or network so I checked and the IP address is correct, but the subnet and gateway are incorrect. It has a...
Replies
2
Views
1,954
Hello guys, How can I change subnet mask on ET200. It is grayed out. I am using TIA 14
Replies
9
Views
2,273
Back
Top Bottom