"probably sent some commands to the master it didn't understand when initializing and caused it to become unresponsive".........sounds like something we would say when we are guessing. No, this is not what happened. There are no new commands from the device to the master in the 1.20.xx firmware. I am guessing something else went wrong perhaps unrelated to the firmware upgrade. More like just dumb, blind luck. Hopefully the unit will find its way to me and we can investigate. If I do get the unit I will post here what we found. Sorry for your troubles but thanks for jumping through some hoops in an attempt to fully understand what was going on.
I still liked the Chinese hacker theory from a few pages back the best. This was an exciting thread then, now anything engineering comes up with will be much appreciated but boring by comparison.
I get someone from London (at least according to http://www.ip-adress.com/ip_tracer) always trying to connect to my office NI via SSH. Pretty sure it's a bot, I'm thinking about leaving the port wide open one night and log what it sends over.... or for fun I can attack back!
I know this tread as shift a bit (it is more about SSH now), but just to let you know that my NI-3000 as not drop the ethernet link once since I put a longer cable (50') between the controller and the router
Do not do this. The fines and prison sentences for even using someone's unsecured wireless access point, never mind attacking a machine over the internet using your ISP have increased to the point of ridiculousness. Unauthorized Access Laws are used to prosecute even the silliest things these days. Should the server you happen to be hacking belong to a terrorist organization, well then good luck to you!
Paul
Do not do this. The fines and prison sentences for even using someone's unsecured wireless access point, never mind attacking a machine over the internet using your ISP have increased to the point of ridiculousness. Unauthorized Access Laws are used to prosecute even the silliest things these days. Should the server you happen to be hacking belong to a terrorist organization, well then good luck to you!
Paul
I had a 3100 that I had to return because an I/O port went bad. When it was returned, I had the same problem that you had/have.
I made my sales rep and "sales engineer" (I use quotes because I have never met an engineer that didn't know how to use a multi-meter) come out to my house to see many problems first hand.
They insisted that it was something with me or my network. I was able to prove the 3100 was bad by having another 3100 processor with all the same firmwares to try. It was like pulling teeth, but I finally was able to get a replacement.
Coincidentally, I was also able to prove problems with an R-4, and (2) 8400's.
I have tried to bring many product problems and short-falls to the attention of my sales rep to help AMX improve their products, but after making AMX return an Autopatch Optima switch because there was popping in the audio volume control, my rep no longer contacts us (yet he was the sales manager of the year, nice).
My opinion, by 2 of everything since the product is so inexpensive! (yea right)
Inexplicably, this box is working fine, and has been, on my desk for several weeks now. When I first removed it from the job site, it locked up just as frequently here. After about a week, it just stopped locking up. There was only one change ... we converted our office broadband from DSL to cable. AMX doesn't think that's relevant, but I can't help but wonder. The job site has cable, but it's in a remote area and is known to have performance issues: slowdowns, dropouts, etc.
Inexplicably, this box is working fine, and has been, on my desk for several weeks now. When I first removed it from the job site, it locked up just as frequently here. After about a week, it just stopped locking up. There was only one change ... we converted our office broadband from DSL to cable. AMX doesn't think that's relevant, but I can't help but wonder. The job site has cable, but it's in a remote area and is known to have performance issues: slowdowns, dropouts, etc.
One thing we've run iinto that speaks to what you say is that whenever we find ourselves in a situation where the WAN IP of the cleint's house changes the netlinx master can exhibit problems. The main thing I've been able to determine is when that WAN IP subnet changes to the point that they DNS server also changes.
So, for example: Comcast in our area typically uses several subnets.
If the WAN IP is forced to change on the Modem from say 64.... to one of the others, the DNS server for the router also changes. When this happens without rebooting the router and netlinx master if find trouble.
In our area, DSL has until recently stayed in the same subnet. In fact, most clients got one IP address and it stuck with it. However, recently the DSL clients are now changing. Obviously, it's the ad hoc nature of the network.
When this happens, and it seems to be a problem, I just reboot the master each night and the problems go away.
I know this makes no sense, but I too have seen some odd behaviour that I can only link to ISP issues. I don't have your level of patience and usually grab the biggest tool at hand to fix the problem. Rebooting it daily seems to fix it.
You can always use a third party dns such as OpenDNS - I've found this to be much preferable & more solid that some ISP's default dns.
While this is true, we've also found that there seems to be some skullduggery from some ISPs when you try to use some of the freebie dns services. We tend to just use some of the big public dns servers like directnic or at&t or savvis. Those seem to be pretty fast and always there.
Not to mention 4.2.2.4 is pretty easy to remember. (AT&T)
I make it a point to use the router IP for my DNS entry just for that reason. Let the router deal with ISP changes, as it should. I've been burnt by that once or twice ... but I might add, it only knocks out IP communications, it doesn't generally lock up the master.
My problem master just stopped being a problem all on it's own. Nothing changed, it just stopped acting up. I hate not having answers, but I have closed the book on it. I still suspect an ISP problem interacting with a module that was going out into the Cloud, but I can't nail down anything definitive (especially now that it's fine, and has been so for a few months).
My problem master just stopped being a problem all on it's own. Nothing changed, it just stopped acting up. I hate not having answers, but I have closed the book on it. I still suspect an ISP problem interacting with a module that was going out into the Cloud, but I can't nail down anything definitive (especially now that it's fine, and has been so for a few months).
That is really bad when a problem goes away, you cannot troubleshoot what's not there.
If you redeploy it; the problem will probably aunt you back (and probably at the worst moment you could imagine).
Dave do you recall if you left the SSH port disabled or not? I'm having a similar problem on an NI3100 that I need to reboot to bring it back to life and checking the log I also had the SSH connection from china in the last hour's entry before the lock up. The log does show that the connection closed and it then showed a successful ping of yahoo which makes it appear all was still well at that point but it's eerily similar to your problem.
I haven't ruled out code either but just to be sure I disable SSH too. Does anything need it?
I also have Cisco switches so I'll play with those port settings too.
If you watch long enough on an exposed NetLinx, you'll see "connections accepted" from all over the planet on telnet. They aren't usually really logged in, just connected and offered the "login" prompt.
This is just as likely on regular TELNET as SSH as FTP as web....
There are thousands of computers endlessly "war dialing" the internet looking for open ports. Usually the first wave that finds you home just passes your IP to another bank of computers that then categorize and determine if it looks interesting enough to start hammering with a password break in attempt. You'll know when you are in that phase, you'll see connections every second.
Of course, if you are like a surprising number of integrators, you might have security off, so the war dialers drop right into a valid command prompt. These addresses usually get quickly tested for "valuable" information... which won't be there... which sometimes results in vandalism; deletion of files, or at least rebooting for fun. This has happened to one of our dealers... and is suspected by a couple others who "can't imagine how else that file got deleted [or in the wrong place]". Well, maybe.
I periodically review the logs and only really ever noticed these odd connections on SSH and everyone I've ever looked up was from china but that's not my concern. I do run security on my masters so I don't suspect vandals but possibly the problem that Dave seemed to suggest and I only thought of reviewing this old thread when I realized this connection occurred just prior to the master locking up. It's quite probabable it's just a coincidence but maybe there is an issue with how the masters handle these connections. It could also be a problem with my cisco switch that was been discussed by others.
I see, you are suggesting the SSH connection itself could be leading to the problem. I have only evidence of the negative, which isn't proof - In every training, we usually have a few dealers who forget to click TELNET instead of SSH in PUTTY, our favored telnet client, so we see lots of SSH connections come and go in error, probably a few hundred I've seen. I've never seen it followed by any unexplained issues.
This just came in from one of our dealers, here's a few minute capture of TELNET at a customer site. This is evidence of an organized effort to break into this system. Most of the IP addresses are from NORTH KOREA, but some are from all over including Alaska, Spain, and more. So yes, it can happen to you. Note that "Accepted" does NOT mean they got past the login... only that the connection request was replied to. Security is ON, so these are apparently attempts to guess the login. This customer needs immediate inbound IP filtering.
I recently have come accross this problem and am starting to think its related to using IP communcations (IP_CLIENT_OPEN). Are you guys using any IP control in your instances ?
I recently have come accross this problem and am starting to think its related to using IP communcations (IP_CLIENT_OPEN). Are you guys using any IP control in your instances ?
Of course. But this will not cause IP addresses from all around the world to try to get in. What are you really asking?
I'm referring to the original post about master's that keep losing their network connection.
I'm the original poster, and this problem just went away without me doing a thing. I am strongly suspicious there was something on his Internet connection going nuts and bogging down my IP devices, but it hasn't acted up in 2 1/2 years.
Comments
--John
Ooooh! that would absolutely rock!
I know this tread as shift a bit (it is more about SSH now), but just to let you know that my NI-3000 as not drop the ethernet link once since I put a longer cable (50') between the controller and the router
Do not do this. The fines and prison sentences for even using someone's unsecured wireless access point, never mind attacking a machine over the internet using your ISP have increased to the point of ridiculousness. Unauthorized Access Laws are used to prosecute even the silliest things these days. Should the server you happen to be hacking belong to a terrorist organization, well then good luck to you!
Paul
I had a 3100 that I had to return because an I/O port went bad. When it was returned, I had the same problem that you had/have.
I made my sales rep and "sales engineer" (I use quotes because I have never met an engineer that didn't know how to use a multi-meter) come out to my house to see many problems first hand.
They insisted that it was something with me or my network. I was able to prove the 3100 was bad by having another 3100 processor with all the same firmwares to try. It was like pulling teeth, but I finally was able to get a replacement.
Coincidentally, I was also able to prove problems with an R-4, and (2) 8400's.
I have tried to bring many product problems and short-falls to the attention of my sales rep to help AMX improve their products, but after making AMX return an Autopatch Optima switch because there was popping in the audio volume control, my rep no longer contacts us (yet he was the sales manager of the year, nice).
My opinion, by 2 of everything since the product is so inexpensive! (yea right)
One thing we've run iinto that speaks to what you say is that whenever we find ourselves in a situation where the WAN IP of the cleint's house changes the netlinx master can exhibit problems. The main thing I've been able to determine is when that WAN IP subnet changes to the point that they DNS server also changes.
So, for example: Comcast in our area typically uses several subnets.
64.xxx.yyy.zzz
68.xxx.yyy.zzz
78.xxx.yyy.zzz
24.xxx.yyy.zzz
etc.
If the WAN IP is forced to change on the Modem from say 64.... to one of the others, the DNS server for the router also changes. When this happens without rebooting the router and netlinx master if find trouble.
In our area, DSL has until recently stayed in the same subnet. In fact, most clients got one IP address and it stuck with it. However, recently the DSL clients are now changing. Obviously, it's the ad hoc nature of the network.
When this happens, and it seems to be a problem, I just reboot the master each night and the problems go away.
I know this makes no sense, but I too have seen some odd behaviour that I can only link to ISP issues. I don't have your level of patience and usually grab the biggest tool at hand to fix the problem. Rebooting it daily seems to fix it.
Not to mention 4.2.2.4 is pretty easy to remember. (AT&T)
I know this tread has been silent for a while, but I'd like to put an update.
My NI-3000 has been up and running since jan 12, 2010
I did not even resetted it once!
So for me the solution was to put a 50' lenght of network cable between the NI-3000 and the router or switch.
That is really bad when a problem goes away, you cannot troubleshoot what's not there.
If you redeploy it; the problem will probably aunt you back (and probably at the worst moment you could imagine).
I haven't ruled out code either but just to be sure I disable SSH too. Does anything need it?
I also have Cisco switches so I'll play with those port settings too.
This is just as likely on regular TELNET as SSH as FTP as web....
There are thousands of computers endlessly "war dialing" the internet looking for open ports. Usually the first wave that finds you home just passes your IP to another bank of computers that then categorize and determine if it looks interesting enough to start hammering with a password break in attempt. You'll know when you are in that phase, you'll see connections every second.
Of course, if you are like a surprising number of integrators, you might have security off, so the war dialers drop right into a valid command prompt. These addresses usually get quickly tested for "valuable" information... which won't be there... which sometimes results in vandalism; deletion of files, or at least rebooting for fun. This has happened to one of our dealers... and is suspected by a couple others who "can't imagine how else that file got deleted [or in the wrong place]". Well, maybe.
(0013063499) Accepted Telnet connection:socket=42 addr=121.179.226.46 port=2370
(0013063805) Accepted Telnet connection:socket=42 addr=121.180.195.180 port=2138
(0013064733) Accepted Telnet connection:socket=42 addr=118.43.70.45 port=4944
(0013068120) Accepted Telnet connection:socket=42 addr=121.154.53.237 port=3781
(0013069502) Accepted Telnet connection:socket=42 addr=121.179.226.46 port=2515
(0013069807) Accepted Telnet connection:socket=44 addr=121.180.195.180 port=2283
(0013070737) Accepted Telnet connection:socket=45 addr=118.43.70.45 port=1114
(0013074717) Accepted Telnet connection:socket=42 addr=221.165.68.216 port=4793
(0013075128) Accepted Telnet connection:socket=22 addr=121.153.227.75 port=4323
(0013077810) Accepted Telnet connection:socket=22 addr=220.88.220.75 port=4236
(0013080718) Accepted Telnet connection:socket=22 addr=221.165.68.216 port=4938
(0013081102) Accepted Telnet connection:socket=42 addr=121.153.227.75 port=4468
(0013082990) Accepted Telnet connection:socket=22 addr=14.48.100.62 port=1259
(0013083365) Accepted Telnet connection:socket=22 addr=221.156.27.78 port=4897
(0013083367) Accepted Telnet connection:socket=42 addr=121.154.53.237 port=4181
(0013083814) Accepted Telnet connection:socket=22 addr=220.88.220.75 port=4381
(0013088997) Accepted Telnet connection:socket=22 addr=14.48.100.62 port=1404
(0013089340) Accepted Telnet connection:socket=42 addr=221.156.27.78 port=1066
(0013090049) Accepted Telnet connection:socket=44 addr=221.157.2.179 port=2739
(0013092523) Accepted Telnet connection:socket=22 addr=221.160.59.2 port=2916
(0013098077) Accepted Telnet connection:socket=22 addr=220.87.102.89 port=4835
(0013098500) Accepted Telnet connection:socket=22 addr=221.160.59.2 port=3061
(0013101730) Accepted Telnet connection:socket=22 addr=112.165.117.119 port=2632
(0013104082) Accepted Telnet connection:socket=22 addr=220.87.102.89 port=4980
(0013106232) Accepted Telnet connection:socket=22 addr=121.139.71.84 port=2946
(0013106832) Accepted Telnet connection:socket=22 addr=221.157.2.179 port=3138
(0013107735) Accepted Telnet connection:socket=44 addr=112.165.117.119 port=2777
(0013109975) Accepted Telnet connection:socket=22 addr=115.69.124.118 port=2351
(0013112235) Accepted Telnet connection:socket=22 addr=121.139.71.84 port=3091
(0013115269) Accepted Telnet connection:socket=22 addr=121.174.42.107 port=3606
(0013115989) Accepted Telnet connection:socket=22 addr=115.69.124.118 port=2496
(0013117568) Accepted Telnet connection:socket=44 addr=201.240.204.17 port=3944
(0013118701) Accepted Telnet connection:socket=22 addr=118.46.196.120 port=1811
(0013121272) Accepted Telnet connection:socket=22 addr=121.174.42.107 port=3751
(0013123604) Accepted Telnet connection:socket=22 addr=201.240.204.17 port=4089
(0013124705) Accepted Telnet connection:socket=44 addr=118.46.196.120 port=1956
(0013163970) Accepted Telnet connection:socket=22 addr=85.61.15.63 port=3079
(0013170055) Accepted Telnet connection:socket=42 addr=85.61.15.63 port=3224
(0014032369) Accepted Telnet connection:socket=42 addr=66.230.108.77 port=2591
(0014038432) Accepted Telnet connection:socket=22 addr=66.230.108.77 port=2738
(0014050421) Accepted Telnet connection:socket=22 addr=121.74.175.48 port=3728
(0014056479) Accepted Telnet connection:socket=22 addr=121.74.175.48 port=3873
(0014351910) Accepted Telnet connection:socket=22 addr=88.8.217.7 port=2573
(0014358019) Accepted Telnet connection:socket=22 addr=88.8.217.7 port=2718
(0014666945) Accepted Telnet connection:socket=42 addr=95.32.183.41 port=4847
(0014673030) Accepted Telnet connection:socket=42 addr=95.32.183.41 port=4992
I recently have come accross this problem and am starting to think its related to using IP communcations (IP_CLIENT_OPEN). Are you guys using any IP control in your instances ?
Of course. But this will not cause IP addresses from all around the world to try to get in. What are you really asking?
I'm the original poster, and this problem just went away without me doing a thing. I am strongly suspicious there was something on his Internet connection going nuts and bogging down my IP devices, but it hasn't acted up in 2 1/2 years.