God help a man who's lost in the PLC world

[rsdoran]

I agree.

MS sells software and goes to extremes to protect it, EVERYONE pays for this software at some point...ie you can not purchase a new computer without it being part of the cost in most cases. OEM versions are slightly cheaper.

Linux is not free in most cases, the developers/packagers charge. If you have the time and patience etc then you can take the free code and install it...it is not feasible for most

Too expect software, or anything, to be free or not profitable defeats the whole concept of "free enterprise" the US was built on.

This aspect of the internet...ie it should be free, will be our downfall because other countries will produce "free" or "cheaper" versions that may or may not be effective/reliable for the application.

Technically what is purchased is a business decision and an engineer or tech should not decide based on cost.

 

[PhilipW]

There is nothing backdoor about packet sniffing

Oh yes there is. Ask any responsible sysadmin about how he feels about it. Packet sniffing essentially bypasses all the security layers built in to the system. In many cases anyone caught packet sniffing without express permission to do it for network diagnostic purposes faces instant termination... in most other contexts it is considered a major breach of security.

Therefore anyone asking about packet sniffing immediately raises prefectly fair questions about their motives. If they can answer them, as this guy seems to have, then well and good....but if not then they really are a hacker. And hackers into production systems are very dangerous critters indeed.

 

[monkeyhead]

Oh yes there is. Ask any responsible sysadmin about how he feels about it. Packet sniffing essentially bypasses all the security layers built in to the system. In many cases anyone caught packet sniffing without express permission to do it for network diagnostic purposes faces instant termination... in most other contexts it is considered a major breach of security.

And now apply everything you said to the original poster's situation.

A 'responsible' system admin will also ensure that anything sensitive enough that it can't risk being sniffed is encrypted or transmitted through a secure medium.

 

[PhilipW]

And now apply everything you said to the original poster's situation.

And how were we supposed to know what his "situation" was unless politely asked? His reply made sense given his background....but at the end of the day, it was far saner for him to use the standard RSView32 tool at hand than re-invent "hacked" version of the wheel.

A 'responsible' system admin will also ensure that anything sensitive enough that it can't risk being sniffed is encrypted or transmitted through a secure medium.

Precisely. But are the comms between a CLX processor and RSView32 secure and encrypted? With the EthernetIP spec open anyone could crack it given a little time and inclination. So far the automation game has depended on "security by obscurity", but that is about to change. Look to some new upcoming "overpriced" RSI products (RSAssetSecurity) to address this important question.

 

[monkeyhead]

And how were we supposed to know what his "situation" was unless politely asked? His reply made sense given his background....but at the end of the day, it was far saner for him to use the standard RSView32 tool at hand than re-invent "hacked" version of the wheel.

I completely agree, and so did the original poster, but yet he was still getting jumped on for the one uninformed idea he proposed even after he agreed that learning RSView32 would be a better solution. That's when I got annoyed and decided to start running my mouth.

I didn't reply to the software pricing thing because it was just too idealogically charged, but if the original poster only has access to the runtime, then I can't see this minor of a project justifying the purchase of the developer edition of RSView32.

 

[Contr_Conn]

I think all tools you need already mentioned in previous posts.
You will need:

- CIP spec and Ethernet/IP spec from ODVA - they are open, I don't think they are free.
- Logix5000 Data Access Reference Manual 1756-RM005A-EN-E
- DF1 Protocol & Command Set Reference manual 1770-6.5.16
- Ethereal (www.ethereal.com) sniffer will break down packets for you.


I am not an OPC/RSVIEW expert, but this may help:
You already have OPC running on your RSVIEW machine.
Why not to try to access this OPC remotely, so OPC pull necessary data for you.

 

[jarbar1026]

Monkey:

>I was referring to Steve's 'Backdoor' comment... There is
>nothing backdoor about packet sniffing and it was a logical
>idea for a software developer whose never been exposed to PLCs.

>I love how this board is called "LIVE PLC Quesions and Answers",
>but anytime someone new comes around and asks a question,
>certain members decide to **** all over them and talk to them like >their idiots unless they've got a bunch of PLC experience.

Thanks, MH. You know, it's been hard to feel like I'm "backdooring" my own company when all of our IT group is working hard to help me get a solution, *whatever* that solution may be.

I've seen the light on the packet-sniffing. It does seem like it's going to be a significant investment of time and some time down the road before I'll even know how do-able or stable such a system would be. I'm looking now at the COM libraries that the RSView installation places on my PC, but without any guide to how the classes, methods, and parameters found in those COM objects are used, I have little hope for finding anything out on my own.

I have a call in to our local Rockwell rep. I'm hoping he can shed some light.

One comment on this forum: I'll try not to post another question here unless I absolutely have to. I was met from the start with "You're the devil" and "You're an idiot" comments, and I can't say it's a very welcoming place to those who are "on the outside" of the topic.

I think it's great for those immersed in PLCs, but those not so immersed should probably limp back to Google and continue the hunt.

 

[MarkTTU]

One comment on this forum: I'll try not to post another question here unless I absolutely have to. I was met from the start with "You're the devil" and "You're an idiot" comments, and I can't say it's a very welcoming place to those who are "on the outside" of the topic.

Jarbar, I'm sorry to see you say this, but I have to agree with you at least in part; you essentially got jumped when you were just trying to solve a problem using the knowledge and skills you have without having to learn a whole new field.

I've been following this thread since your first post, but as I do not know much about AB's stuff I decided my comments were probably best left out, but I'll go ahead and offer them now (even the redundant ones).

1) Packet sniffing is probably way more work than its worth, but its not "evil" by any means. Having come from IT into controls I still know lots of guys that are in IT and every single one have them has used a packet sniffer at some point for very legitimate reasons.

2) A separate PC running software that interfaces with the PLCs and the SQL server (RSView?) is probably the best approach. If I hear you right this isn't something that has to be ultra fast (like 10ms) and the extra bandwidth from another polling device should be negligible on even a 10mbps network. This way you get a PC that can go up and down or even crash without hurting production. When working with this I'd just be damn sure I was only reading from the PLCs and not writing anything.

3) Network collisions should be virtually non-existent if the network is built using switches instead of hubs... I would hope that by now your network is using switches and there isn't a hub anywhere; let the switches do their job.


I've got to defend these guys a little bit. Typically the stuff that gets played with by people posting on this forum has the potential to seriously harm or kill people if you don't dot every i and cross every t along the way. Without a good understanding of the problem or situation or if someone shows that they don't know much/anything about control systems the pat response around here is "don't touch it". There is a simple reason for this harsh treatment; none of us want to have someone's death in some far away place on our conscience. In your first post you stated that you knew nothing about PLCs, but then started asking about ways to interface with them that are way outside of the norm; I think this is why you got jumped on so harshly. If you'd stated what you had in place, what your goal was, and then that you'd had an idea about packet sniffing and if there's not some reason packet sniffing is a big no no if anyone knew how the packets were constructed I think you probably would have seen a very different response from these guys.

 

[jarbar1026]

Mark, thanks for your response.

>Typically the stuff that gets played with by people posting
>on this forum has the potential to seriously harm or kill
>people if you don't dot every i and cross every t along the way

Understood. Completely understood. And my whole motive in creating a passive packet-monitoring process is so that I could keep me and my code out of the way as much as possible. Like I said, bringing down a production line because of something done in-process scared (scares) the **** out of me. The causing-injury fear goes without saying.

I'm a Microsoft homer, I'll admit, but I don't trust some of what they do, and VBA is just one of them. I was dismayed to hear that VBA code is produced behind-the-scenes, at least partly, by what our RSView guy(s) do here. My distaste for and distrust of VBA apps is unfounded, probably, to a great extent. But I just wanted, and want, to stay out of the way of the "real" work that goes on around here.

Like the Hippocratic oath, I really want first and foremost to "do no harm". If we were about getting this done the fastest, we'd have been modifying these guys' RSView code last week.

 

[MarkTTU]

MS isn't really all that bad and can be made to be stable, though it does take some serious work to get it there. I've got a good friend who's a VBA wiz; he's done several projects via contract work for the company I work for and to date we've all been impressed with what he can accomplish using VBA.

Let us know how all this works out when you get something going. We all like hearing the end result of topics like this one.

 

[castlerock]

Thanks, MH. You know, it's been hard to feel like I'm "backdooring" my own company when all of our IT group is working hard to help me get a solution, *whatever* that solution may be.

I've seen the light on the packet-sniffing. It does seem like it's going to be a significant investment of time and some time down the road before I'll even know how do-able or stable such a system would be. I'm looking now at the COM libraries that the RSView installation places on my PC, but without any guide to how the classes, methods, and parameters found in those COM objects are used, I have little hope for finding anything out on my own.

Don't give up so easily jarbar. It sounds like an interesting project if you have the right tools and if your company is backing you up on this then go for it. Peter mentioned the ABEL library for Allen Bradley ethernet communications. It was reverse engineered and guess what was used to decypher the protocol ? You guessed it. A packet sniffer. Its open source so even if you can't use the c code, you can see the code for the protocol and take from it what you need.

(warning: it was developed for linux)

You can download it here

One comment on this forum: I'll try not to post another question here unless I absolutely have to. I was met from the start with "You're the devil" and "You're an idiot" comments, and I can't say it's a very welcoming place to those who are "on the outside" of the topic.

I think it's great for those immersed in PLCs, but those not so immersed should probably limp back to Google and continue the hunt.

Don't worry about it. Old people get grouchy when young people want to do somthing different, =]

Take what you can use and ignore the rest.

Good luck,
Mike

 

[rsdoran]

Personally I dont care.

I am not as well versed as many are here but personally did not see a reason, in this situation, to use anything but the tools already provided.

As mentioned you can easily collect the data that is in RSView and transfer it to an SQL database, an example;
Share data with Microsoft products. RSView32 tag configuration, alarm configuration, and logged data are all ODBC compliant. Log data directly to an ODBC data source such as Microsoft SQL Server, Oracle, or SyBase, and graphically view the data in a trend.
http://www.software.rockwell.com/rsview32/benefits.cfm

What is strange is that there appears to be a large IT department but no Engineering department that could probably simplify what is needed.

The original statement;

We would like to be able, outside Rockwell's RSView32 software, to monitor and intercept network traffic to and from our PLC controllers. When certain signals come from certain controllers, we would like to take specific action

This is wide open to interpretation, it is not stated in a manner that implies data collection.

Technically if you are IT then you SHOULD BE a HACKER or you are not good at your job.

The real issue, besides being legit or not, is whether it makes more sense to take some time and learn (or get trained) on RSView so when a more in-depth need arises it can be done easily OR use the backdoor and "sniff" to develop something that may not provide what could be needed in the future and may take an indeterminate time to develop.

As was mentioned there can be many "nefarious" reasons for doing this BUT how many "END USERS" would actually need to develop something like this?

Of course this could be one of those IT versus Engineering things where they want control on their terms.

 

[Peter Nachtwey]

Hmmm. A product possibility.

Why not to try to access this OPC remotely, so OPC pull necessary data for you.

But OPC must ask for all the data that isn't produced. This increases traffic. That is the whole point of the packet sniffer. I wonder if there is a market for a passive packet sniffer that can also act like a bridge between the plant floor and the office networks. This new device would have two or more ethernet ports. One for the IT side and the other for the machine centers. This sniffer would passively build a data base from all the sniffed packets from the machines and allow the IT guys to read only the data. The device is passive so it can't or shouldn't write. This way the IT guys and even the plant floor will not slow down the machine ethernet when they access report data.

Now if I just stripped the motion control code out of the .... and added .... we could ....... we could even ....... Hmmm....

You guys gave Jabar a lot of grief for just thinking/asking about sniffing whereas I have admitted that we can sniff packets and a lot more and no one said a thing. Not everyone that wears ski masks robs banks.

Jabar, I take it link on www.control.com wasn't of any use.

 

[rsdoran]

You guys gave Jabar a lot of grief for just thinking/asking about sniffing whereas I have admitted that we can sniff packets and a lot more and no one said a thing. Not everyone that wears ski masks robs banks.

Peter you also stated ,and it is known, you are in business so development is continuous...at least I would assume that.

The real issue is why "create" when it is not necessary...I presume you do it from a need for product development.

I am fairly certain you would have no problem developing a position control system BUT if later you learned it was for launching rockets for "others" you would "have more than second thoughts".

It is all perception. I percieved that what was being asked did not make sense "GIVEN THE TOOLS AVAILABLE".

But wear a ski mask downtown Honolulu...what does that imply?

Personally I do not care but the original 2 statements were not stated in a manner conducive to thinking anything other than what most did.

 

[Peter Nachtwey]

Peter you also stated ,and it is known, you are in business so development is continuous...at least I would assume that.

It wasn't known that I developed products 5 or 6 years ago when we developed our Ethernet/IP. Would I have go the same response then? I reveal information slowly.
I remember the forum being paranoid aobut someone asking about nuclear instrumentation. I am an ex navy nuke, a reactor controls division officer. I knew there was nothing classified in the request in the thread, but the forum was paranoid anyway.

I am fairly certain you would have no problem developing a position control system BUT if later you learned it was for launching rockets for "others" you would "have more than second thoughts".

Yes, in past we had to fill out export control forms where we had to explain that we were using 16 microcontrollers and what the 16 bit controllers where going to be used for. 16 bit microcontrollers were OK but 32 bit DSPs were not. I don't think we have fill out export forms now for 10 years. I know we are shipping 32 bit DSPs over seas and I don't think we are filling out forms any more, but I can ask the people that do our shipping. I don't do shipping anymore.

It is all perception. I percieved that what was being asked did not make sense "GIVEN THE TOOLS AVAILABLE".

I don't think there are good tools available that can update a data base passively. Jabar got a link on www.control.com but it is just a monitor. It doesn't update a database.

Personally I do not care but the original 2 statements were not stated in a manner conducive to thinking anything other than what most did

I wasn't too worried. It took our 'Q' toook 6 months to develope our Ethernet/IP product. Our 'Q' is very very very good. I know that developing a product takes much more effort than just getting something to work but I think Jabar would give up long before that unless he had a lot of funding and expected payback.

Note, we did not use ABEL to develope our product. We bought the source from Rockwell before it was released to ODVA. We paid $500 then but we got the information 1 year ahead of the rest. I think we were the first or second company to have an Ethernet/IP certified prodoct.