I'm sorry if my question is too easy or obvious. I'm Comp. Science Student (it's my 6.th term).
I'm trying to combine the knowledges that I'm learning from 'Computer Networks and Security', 'Computer Organization' and 'Operating Systems' lectures in this term.
So, I cannot figure out that;
Does a computer or a phone has physical components for each 65535 ports/sockets?
Or
The machine has just one physical component. So that means port numbers are logical representations that can be shown as text-fields (like header entities or json attributes) of a request or something, to say to computer how to handle the request?
I used ports for connections of back-end and android and front-end. I know that a socket is a physical component, I worked 4 months as phone-repairer, I know these. But this makes me confused.
Thanks in advance..
Think of it this way: "the network interface is the phone system, IP-addresses are phone numbers, and socket/port numbers are like telephone extensions. (The network interface is the only physical device.)
Network traffic is carried by so-called "packets" which have various fields which tell the network how they should be routed. The IP-address will get the packet to the proper destination, then the port/socket-number will specify exactly what software process at that destination should actually handle this packet.
Related
I am trying to detect intrusions on a CAN bus configuration. To do this I want to try protocol conversion from CAN to IP (UDP) in order to use snort. I really don't know where to begin as I have not seen anything on protocol translation for a CAN bus at all. Is it even possible? Has anyone tried it?
I basically used a raspberry pi and several Arduinos to take temperature readings (from thermostats) and control hot/cold fans in order to regulate temperature. I know this is not a lot to go on, but as I said, I am just in the beginning phase of planning this protocol translation.
You can use cannelloni on your RPi. There are also stand-alone CAN-to-TCP/UDP converters like for example this one.
While unit testing a Modbus driver I'm writing I experienced the following:
I can read holding registers 0 to 1022.
I can't read holding registers 1022 to 13000. I get an illegal data address error code.
I can read holding registers 13000 to 25000.
I would have expected devices supporting Modbus to behave in one of the following two ways:
Every device supports the full range of addresses from 0x0000 to 0xFFFF.
Every device supports a range of addresses from 0x0000 to N, where N < 0xFFFF.
Do any of you more experienced people know:
Is Assumption 1 or 2 about the expected behavior of Modbus devices correct?
Are there other reasons beside being out of bounds for an address to be an illegal data address?
Both assumptions are false. It's completely up to the device to decide which registers to support. Some devices are nice and support a wide range of registers, even if they're unused. Most that I've used don't, though. They'll use groups of registers, like your device.
Also, not all Modbus devices support all the Modbus function codes. Just because it's defined by the Modbus protocol standard doesn't necessarily mean the device will support it.
The key thing is to stick to the addresses defined in the device's manual. The manual is usually required reading, otherwise you'll just be guessing at the ranges, units, and scaling.
I've been working on a distributed system project, my system is partially p2p. My issue is super simple, I don't know how people usually solve it, because I have no experience in this domain, I am very new to this all.
I want to communicate over the internet between two clients, which both have ZMQ sockets.
On my local network, or my machine, they seem to work fine, but when communicating over the internet, I never get my message. I have shortlisted this to 2 reasons :
1 ) The NAT - it is not letting my message reach the client host, does anyone know how to solve the issue of NAT within ZMQ, I have heard of TCP hole punching and such, how do web developers and other people who deal with this thing often manage this ?
2 ) ZMQ sockets can not communicate over the internet, even if the communication is strictly between the two ZMQ sockets and not BSD sockets etc. I am not sure about this one though.
If anyone has expertise in this area I would be grateful and it would help me move forward thanks !
2 ) ZMQ sockets can not communicate over the internet, even if the communication is strictly between the two ZMQ sockets
Well, 2 ) is easy, ZeroMQ sockets obviously work over the Internet .
There is not much to add to this.
1 ) The NAT - it is not letting my message reach the client host,
The 1 ) will deserve a bit more attention :
Right, NAT could be in place, when local LAN(s) routers are connected to a single public ( registered, coordinated IPv4 / IPv6 address ).
Next, there could be another show-stopper in the game, the FireWall, put in one or more places (!) -- be it a local one ( O/S operated, which one can check, if having administrator-grade login to the localhost ), or a one, integrated into any of the Gateway/Proxy/Policy enforcement.
In any case, thorough design-review ought take place with your local administrator(s), responsible for the localhost-O/S and network-infrastructure elements and a network-wide responsible security-manager / engineer(s).
The "HOW ?" part :
This ( principal ) complexity is exactly why Game Studios try to avoid user's headaches on solving these complexities and try to provide some escape strategy.
For a trivial case 1-to-1 :
One may indeed use a set of rules for a port-forwarding setup ( if FireWall + Gateway engineering permits ) and your ZeroMQ connectivity may get directed onto a
tcp://<public-IP>:<_a_port#_known_to_be_FWDed_to_a_target_HOST_> address.
For more, but still units :
This scenario may seem easy for a single connection setup, yet if in a need to have units or tens of target hosts, there would be a rather limited will from the gateway ( router ) / firewall admins to open more and more ports on the wild side of the security perimeter. Here another trick may help - using a standard ssh-tools, where connections could harness so called local-port-forwarding and remote-port-forwarding, and the interconnects enjoy a single-port to pass firewall + gateway, plus the content is encryption-protected. Sure, more administrative efforts are needed on both sides, yet, a known and smart way to go, if these efforts and a bit increased latency ( encryption + decryption processing added ) do not spoil your in-game UX latency plans.
For more, above a few units :
There is an option of re-using an ad-hoc, yet a security threating dual-sided sword - a multi-player shared (!) VPN, which solves the global "visibility" issues ( most often with some central ( be it published or not ) service-provisioning mapping and authentication serving coordinator ). The localhost side applications simply start to see another "local"-interface, uncoordinated with respect to its IPv4 / IPv6 address(es), yet this private-shared-VPN seems to be joining all the players so as to look as if all of these share one common IP-network, having effectively bypassed all the security/firewalling efforts of the common network practices --- which is at the same time its strongest risk for putting in place ( not mentioning the risk of the principal SPOF in the remote, central, authorisation/mapping service-provider, be theirs set of motivations published or hidden ).
Gaming industry panicked on all these issues since Multi-Player games started to be sold ( which for 2018/Q2 Gamers may look as since ever ) and the industry was trying to avoid exactly all these complexity-related pains, as a dominant fraction of game-buying teenagers was not expected to also have acquired both the patient persistence ( to systematically craft the proper setup ) and the deep-enough knowledge ( so as to know all the system-wide details of where and what to setup or re-configure, so as to unlock a secure end-to-end online in-game visibility ).
For indeed many-to-many cases :
A nice example was started in late 1990-ies / early 2000-ies when IL-2 Sturmovik's Community of Pilots and Virtual Squadrons went operational 24/7/365 "since ever". They used a Community sponsored HyperLobby a Mediating Node to have all these complexities solved once and forever for all interested Members. HyperLobby lightweight client/server service-infrastructure was doing all the port-forwarding mapping setups and other server-side mediations dirty hacks all invisible to Pilot(s) and provided added means for administering indeed many connected Multi-Player Game Theatres for IL-2, F/A-18, Su-27 Flanker, CFS, Medal Of Honor and many more, than I try to remember today ( topping above small tens of thousands of connected Pilots IIRC in peak hours ). A great piece of sound design and distinguished efforts for decades for the truly Global online Community ( having an honor to serve in pseudohistorical VFSQ, with members spanning 13 TimeZones - from Hawaii, Brasil, U.S., U.K., France, Germany, Italy, Greece to Turkey - flying with similarly minded friends from Japan, Australia, New Zealand and many other places, round the globe -- be it East/West Front + Pacific Theater globally coordinated weekend-events - missions reconstructed till the very historical details or enjoyed the Memorial Parade Flyovers on V-Day-s' anniversaries ) -- ~Salute~ Jiri Fojtasek, well done indeed! -- idea of which helps to illustrate the way to go / follow ( as many younger game-portals indeed did follow this path ).
I need to be able to repeatably, non-randomly, uniquely identify a server host, which may be arbitrarily virtualized and over which I have no control.
A MAC address doesn't work because in some virtualized environments, network interfaces don't have hardware addresses.
Generating a state file and saving it to disk doesn't work because the virtual machine may be cloned, thus duplicating the file.
The server's SSH host keys may be a candidate. They can be cloned like a state file, but in practice they generally aren't because it's such a security problem that it's a mistake not often made.
There's also /var/lib/dbus/machine-id, but that's dependent on dbus. (Thanks Preetam).
There's a cpuid but that's apparently deprecated. (Thanks Bruno Aguirre on Twitter).
Hostname is worth considering. Many systems like Chef already require unique hostnames. (Thanks Alfie John)
I'd like the solution to persist a long time, and certainly across server reboots and software restarts. Ultimately, I also know that users of my software will deprecate a host and want to replace it with another, but keep continuity of the data associated with it, so there are reasons a UUID might be considered mutable over the long term, but I don't particularly want a host to start considering itself to be unknown and re-register itself for no reason.
Are there any alternative persistent, unique identifiers for a host?
It really depends on what is meant by "persistent". For example, two VMs can't each open the same network socket to you, so even if they are bit-level clones of each other it is possible to tell them apart.
So, all that is required is sufficient information to tell the machines apart for whatever the duration of the persistence is.
If the duration of the persistence is the length of a network connection, then you don't need any identifiers at all -- the sockets themselves are unique.
If the persistence needs to be longer -- say, for the length of a boot -- then you can regenerate UUIDs whenever the system boots. (Note that a VM that is cloned would still have to reboot, unless you're hot-copying it.)
If it needs to be longer than that -- say, indefinitely -- then you can generate a UUID identifier on boot and save it to disk, but only use this as part of the identifying information of the machine. If the virtual machine is subsequently cloned, you will know this since you will have two machines reporting the same ID from different sources -- for instance, two different network sockets, different boot times, etc. Since you can tell them apart, you have enough information to differentiate the two cloned machines, which means you can take a subsequent action that forces further differentiation, like instructing each machine to regenerate its state file.
Ultimately, if a machine is perfectly cloned, then by definition you cannot tell which one was the "real one" to begin with, only that there are now two distinguishable machines.
Implying that you can tell the difference between the "real one" and the "cloned one" means that there is some state you can use to record the difference between the two, like the timestamp of when the virtual machine itself was created, in which case you can incorporate that into the state record.
It looks like simple solutions have been ruled out.
So that could lead to complex solutions, like this protocol:
- Client sends tuple [ MAC addr, SSH public host key, sequence number ]
- If server receives this tuple as expected, server and client both increment sequence number.
- Otherwise server must determine what happened (was client cloned? did client move?), perhaps reaching a tentative conclusion and alerting a human to verify it.
I don't think there is a straight forward "use X solution" based on the info available but here are some general suggestions that might get you to a better spot.
If cloning from a "gold image" consider using some "first boot" logic to generate a unique ID. Config management systems like Chef, Puppet or Cf-engine provide some scaffolding to achieve this.
Consider a global state manager like zookeeper. Specifically its atomic counter functionality. Same system could get new ID over time, but it would be unique.
Also this stack overflow might give you some other direction. It references Twitter's approach to a similar problem.
If I understand correctly, you want a durable, globally unique identifier under these conditions:
An OS installation that can be cloned while running, so any state inside the VM won't work, and
Could be running in an arbitrary virtualization environment, so any state outside the VM won't work.
I realize this doesn't directly answer your question, but it really seems like either the design or the constraints need some substantial adjustment to accomodate a solution.
Consider the following Ladder Program that checks if a connection is enabled (A202.00) then send a message from the PLC to the PC.
The documentation (Omron CX-Programmer) has a severe lack of explanation of the program convention. What I do not understand is:
To send a message from a node to a node. I should need to specify the receiver ID. It seems the function block does not have an option where I can insert an IP address. Am I supposed to MOV an IP address to a DM address (D300) then use it? If that's the case how (IP address has dots in between 4 bytes..)?
Can someone please explain what is S (First source word), D (First destination word) and C (First control word). Aren't they just memory address? E.g. sending content of a memory adress to another memory address?
[EDIT]
What am I trying to do?
I am trying to interface a measuring gauge (controlled through Ethernet by PC/C# application) to a robotic system (no RS232 or serial, no TCP/IP, only has the simplest I/O points) with an Omron PLC. When gauge completes a measurement, the C# app sends a command to the Omron PLC which, according to the command received, switch ON or OFF an output which triggers a voltage flow to the robot's I/O port.
Should I use FINS? What functions/protocol from the PLC I need to know to do this? I do not know so I am testing every function from the documentation. So far, zero progress.
1) All addressing information is encapsulated in the five control words (C -> C+4). C- "First Control Word" is the pointer to the first word in this table of five words you must have stored somewhere in your PLC to set up the communication.
2) First source word points to the first word in your PLC you wish to send. First destination word points to the first address in the PLC/device you wish to send to. In the example , the first control word specifies that 10 words should be sent. You point to the first one and it will send that one plus the next nine addresses as well.
To do this you have to use FINS communication - the PC stores a memory structure similar to the PLCs (CIO, DM, etc) called Event Memory and these are the addresses in the PC you are pointing to. The PC gets a FINS node number and address just like a PLC would - no IP addresses are involved. (see : FINS Manual) FINS is old, however, and has been superceded by things like Sysmac Gateway.
There are much better ways of communicating between PLC/PC, however, depending on what you are trying to do. Are you trying to write an HMI? If so, what language are you using?
Edit :
If you're using C#, I highly recommend you look into Sysmac Gateway and CX-Compolet. This is probably the most flexible, simple, and extensible way to get .NET working with Omron PLCs. If it is at all possible, however, a better way might even be to have the measurement unit communicate directly with the PLC via hardware I/O (relays, DIO, etc).
CX-Compolet, Sysmac Gateway link:
http://www.ia.omron.com/product/family/63/index_l_u.html