SM units poked - need help

We bought ten P9 (7.2.9) 5.7 SMs. They appeared OK until we tried to connect beyond a few 100 feet. I checked the event log and they all had something similar to the following:

-------------------There is a lot more, this is an excerpt-------------------

00:00:00 UT : 01/01/01 : File root.c : Line 940 System Startup
00:00:00 UT : 01/01/01 : File root.c : Line 945 Software Version : CANOPY 7.2.9 Jul 23 2005 01:49:03 SM-DES
00:00:00 UT : 01/01/01 : File root.c : Line 949 Software Boot Version : CANOPYBOOT 3.0
00:00:00 UT : 01/01/01 : File root.c : Line 955 FPGA Version : 020205
00:00:00 UT : 01/01/01 : File root.c : Line 959 FPGA Features : DES
00:00:07 UT : 01/01/01 : File C:/ISIPPC/pssppc.250/bsps/devices/whisp/rf.c : Line 4155 Intentional RF Shutdown.
00:00:07 UT : 01/01/01 : File C:/ISIPPC/pssppc.250/bsps/devices/whisp/rf.c : Line 4157 Reboot in 3600 seconds
00:00:22 UT : 01/01/01 : File root.c : Line 1429 bitset value 00000001 to address 70001004
00:00:22 UT : 01/01/01 : File root.c : Line 1281 Poked the value 80906800 to address 70002600
00:00:22 UT : 01/01/01 : File root.c : Line 1281 Poked the value 80976800 to address 70002604
00:00:22 UT : 01/01/01 : File root.c : Line 1281 Poked the value ffffffff to address 7000102c
00:00:22 UT : 01/01/01 : File root.c : Line 1281 Poked the value 80010000 to address 70000000

-------------------There is a lot more, this is an excerpt-------------------

We have always had good luck buying used units, which we must since we can only use software scheduling. We tried taking one unit up to 7.3.6, then tried taking one back down to 4.2.3 (this has saved us in the past when we had issues) but the units were still weak.

If anyone understands what this poking is all about, why it was done, and if it can be undone please help. Perhaps it has caused irreparable damage.

Thank you all for your consideration of this problem.

Frank

care to share the vendor name ? could it be ezlinx ? err, wireless units…

The units were purchased on eBay. These units came from Mexico. We have had good luck buying on eBay for the last 2 years, but looks like we got burned this time. The seller had 100% positive feedback, but repeated requests for information on these units have come to nothing.

Carol

Disclaimer: POKEing around in an SM can be detrimental to its health.

That said, have you tried using peek and comparing the contents of those memory locations between these SMs and known-good SMs on the network?

Try telnetting to the SM, login as root with admin password, then try ‘peek 70002600’ for example to see what value is in that memory location. Compare between known-good and non-working units. If you see a particular value that is always the same on all known-good units but differs on the non-working ones, you can attempt ‘poke {value} {address}’, like ‘poke 807ae800 70002600’ - once you’ve poked all the values you want to try changing, reboot the SM (via web UI) and see what you see.

j

Thank you J. for the information. We will attempt what you suggest, although we have only ever done basic telnet and ftp commands (bringing up old software revs to newer revs). The units are of now value as they are so we will give it a try.

We will post when we find out how it goes. Thanks again.

Carol and Frank

Hello. I tried to poke one of the units with a value from known good units that were common to all. The event log shows that this was done, but when I telnet back into the unit and peek at the address location it is something different,

from Telnet screen:
Telnet+> poke 70002600 808fe800
poke 70002600 808FE800 – written
Telnet+> peek 70002600
peek adr:70002600 == 80902800[/color] [this is not the value that was poked]

Event log:
00:02:28 UT : 01/01/01 : File root.c : Line 1282 Poked the value 808fe800 to address 70002600

Am I missing a step in Telnet?

Thanks, Carol

p.s. I know POKEing is dangerous, but these units are worthless right now…

We also purchased some units from Mexico (off Ebay) a couple months back and almost all of them have RF issues (very weak RF). They promised to make it right with a refund and that never came through.

I still have a box of 20+ worthless units sitting in a box in the corner.

I question whether the poke/peek thing is significant in this case. Some of the old firmware used to show that in the Event Log when certain changes were made.

For what that info is worth.

Paul, PDMNet

Hi, the group in Mexico we purchased from is http://vdys.net/, looking at their website they appear legitimate, but I do not read Spanish. As to the peek / poke issue, it is true that there is a big difference in the blocks in the known good units and these units. There are entire blocks that have no values in the weak units, where the good units are populated. But I do not seem able to do anything about it.

I guess we may have to chalk this up as a bad experience and move on,

Carol

Yep, same people that sold us ours !

They played games with our return, letting it sit in customs, then having customs bounce it back to the shipper (us). Thus, we have the box in the corner.

We should have made a Paypal claim but too much time had passed I fear. Maybe if we both make a claim something could come from it.

My email address is paulm@pdmnet.net if you want to dialog direct on it.

Paul, PDMNet

You will even see that new canopy units in the box show this in the event log sometimes and always show that they have been poked in the engineering event log. I believe the factory does this to change some internal settings that can not be done via telnet or through the web interface. I tried messing with the peek/poke peekblock and pokeblock commands some years ago but when you poke a value in it does not seem to make it permanent and just replaces it back with the original value when rebooted.

It sounds like these units have some other problem then? We would certainly appreciate any help the forum can offer.

Thanks
Carol and Frank